Scribd
Upload
93 views31 pages

Recovery Models and Backup Strategies

Here are the key steps for the exercises: 1. Review the RTO, RPO, and projected characteristics for the databases 2. Determine the appropriate recovery model and backup strategy for each database based on the requirements 3. Implement the backup strategies by configuring the recovery models and backup schedules 4. (Optional) Review the existing recovery models and backup strategies for databases on the CustomerService instance and provide recommendations Let me know if you have any other questions!

Uploaded by

Richie Poo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
93 views31 pages

Recovery Models and Backup Strategies

Here are the key steps for the exercises: 1. Review the RTO, RPO, and projected characteristics for the databases 2. Determine the appropriate recovery model and backup strategy for each database based on the requirements 3. Implement the backup strategies by configuring the recovery models and backup schedules 4. (Optional) Review the existing recovery models and backup strategies for databases on the CustomerService instance and provide recommendations Let me know if you have any other questions!

Uploaded by

Richie Poo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 31

Module 5

Recovery Models and Backup


Strategies
Module Overview

Understanding Backup Strategies


SQL Server Transaction Logs
• Planning Backup Strategies
Lesson 1: Understanding Backup Strategies

Discussion: Previous Experience with Backup


Strategies
Determining an Appropriate Backup Strategy
Choosing Appropriate Backup Media
Determining a Retention Policy for Backups
SQL Server Backup with Azure Blob Storage
• Demonstration: Back Up an On-premises Database
to Microsoft Azure
Discussion: Previous Experience with Backup Strategies

• What types of backup have you used?


• How often do you perform backups?
• Who is responsible for planning and executing a
backup strategy?
• How often are your backups tested?
• Do you use third-party tools for backups?
• What type of backup media do you use?
Determining an Appropriate Backup Strategy

• Different backup types can be combined

• Determine safety levels:


• How long can recovery take? (RTO)
• How much data is it acceptable to lose? (RPO)
• Is it possible to recover the data from other sources?

• Backup strategy should map to requirements:


• Types and frequency of backups
• Backup media to use
• Retention period for backups and for media
• Backup testing policy
Choosing Appropriate Backup Media

• A single backup is called a backup set

• A media set includes one or more backup sets

• Backup sets are written to media sets that


comprise of one or more backup devices

• Backup devices can be:


• Physical—disk files
• Logical—pointer to a disk file
• Microsoft Azure Blob storage
Determining a Retention Policy for Backups

• Planning for backup retention must be part of the


strategy and form part of the test plan to ensure accuracy

• Several considerations:
• Combination of backups needed for a database recovery
• Archival requirements
• Synchronization with database checks
• Available secure storage location
• Hardware required for restoring backups
• Completeness of backups
SQL Server Backup with Azure Blob Storage

• Sometimes called SQL Server Backup to URL


• Benefits:
• Unlimited storage
• Offsite backup solution without the need for tapes and
transport
• No backup hardware to purchase or maintain
• Offsite backups available instantly
Demonstration: Back Up an On-premises Database to
Microsoft Azure

In this demonstration, you will see how to:


• Back up a database with Azure Blob storage
Lesson 2: SQL Server Transaction Logs

Overview of SQL Server Transaction Logs


Transaction Log File Structure
Working with Recovery Models
Capacity Planning for Transaction Logs
Working with Checkpoint Options
• Demonstration: Logs and Full Recovery
Overview of SQL Server Transaction Logs

Transaction logs provide a history of actions executed by a


database management system to guarantee atomicity and
durability of transactions:
1. Data modification is sent by the application
2. Data pages are located in or read into the buffer cache,
and then modified
3. Modification is recorded in the transaction log on disk
4. Later, checkpoint writes dirty pages to data files
Transaction Log File Structure

• Sufficient information is logged to be able to:


• Roll back transactions if requested
• Recover the database in case of failure

• Write-Ahead Logging is used to create log entries:


• Transaction logs are written in chronological order in a
circular way
• Truncation policy for logs is based on the recovery
model
Working with Recovery Models

• Simple
• Does not permit or require log backups
• Automatically truncates the log to keep space requirements small
• Full
• Requires log backups for manageability
• Avoids data loss due to a damaged or missing data file
• Permits recovery to a specified point in time
• Bulk logged
• Requires log backups for manageability
• Can enhance the performance of bulk copy operations
• Reduces log space usage by using minimal logging for many bulk
operations
Capacity Planning for Transaction Logs

• Capacity needs are based on several factors:


• Recovery model used for the database
• Transaction log backup frequency in full and
bulk logged recovery models
• Number and size of transactions in the
database

• Examine log behavior during predeployment


testing
Working with Checkpoint Options

• Types of checkpoint operations:


• Automatic
• Indirect
• Manual
• Internal

• CHECKPOINT statement configures the target


recovery duration
Demonstration: Logs and Full Recovery

In this demonstration, you will see how to:


• Observe log file behavior in the full recovery
model
Lesson 3: Planning Backup Strategies

Overview of Microsoft SQL Server Backup Types


Full Database Backup Strategies
Transaction Log Backup Strategies
Differential Backup Strategies
• Partial and Filegroup Backup Strategies
Overview of Microsoft SQL Server Backup Types

Backup type Description


Full All data files and the active part
of the transaction log
Differential The parts of the database that
have changed since the last full
database backup
Partial The primary filegroup, every
read/write filegroup, and any
specified read-only filegroups
Transaction Log Any database changes recorded
in the log files
Tail-log Log backup taken of the tail of
the log just before a restore
operation
File/File Group Specified files or filegroups
Copy Only The database or log (without
affecting the backup sequence)
Full Database Backup Strategies

A full database backup strategy:


• Involves taking a full backup of the primary
data file
• In simple mode, the database can only be
recovered to the point that the last backup was
taken
• Can be an optimal solution where data is
modified infrequently or is used in a test
environment
Transaction Log Backup Strategies

A database and transaction log backup strategy:


• Involves at least full and transaction log
backups
• Enables point-in-time recovery
• Allows the database to be fully restored in the
case of data file loss
Differential Backup Strategies

A differential backup strategy:


• Involves performing full and differential
database backups
• Includes differential backups with only changed
data
• Is useful if only a subset of a database is
modified more
frequently than the rest of the database
Partial and Filegroup Backup Strategies

Partial and Filegroup backups:


• Faster backup and restore for very large
databases
• Can be complex to set up and manage
Lab: Understanding SQL Server Recovery Models

Exercise 1: Plan a Backup Strategy


Exercise 2: Configure Database Recovery Models
• Exercise 3: Challenge Exercise: Review Recovery
Models and Strategy (if time permits)

Logon Information

Virtual machine: 20764B-MIA-SQL


Username: AdventureWorks\Student
Password: Pa$$w0rd

Estimated Time: 45 minutes


Lab Scenario

You need to implement a database recovery


strategy. The business unit from Proseworks Inc.
has provided the availability needs for the
databases on the new Proseware SQL Server
instance. You need to plan how you will meet the
requirements, and then implement your strategy.
 
If you have time, there is another issue that your
manager would like you to work on. There is
another instance of SQL Server installed for
supporting customer service operations.
Lab Scenario (Continued)

Your manager is concerned that existing databases


on the CustomerService server instance are
configured inappropriately and have invalid backup
strategies, based on their RPO and RTO
requirements. You need to review the database
recovery models and backup strategies for the
databases on the CustomerService instance, and
provide recommended changes.
Lab Scenario (Continued)

Supporting Documentation
Business Database Continuity Requirements for Databases on the
Proseware Server Instance (for Exercises 1 and 2):
• Recovery Time Objectives
o The MarketDev database must never be unavailable for longer
than eight hours.
o The Research database must never be unavailable for longer than
two hours.
• Recovery Point Objectives
o When the MarketDev database is recovered from a failure, no
more than 30 minutes of transactions may be lost.
o When the Research database is recovered from a failure, all
transactions that were completed up to the end of the previous
weekday must be recovered.
Lab Scenario (Continued)

Projected Characteristics
Characteristic Estimated Value
CreditControl database size 20 GB
PotentialIssue database size (at the start of each 200 MB
week after archiving activity is complete)
Total backup throughput 100 MB/minute
Total restore throughput 80 MB/minute
Average rate of change to the CreditControl 500 MB/hour
database during office hours
Average rate of change to the PotentialIssue 10 MB/hour
database (constant throughout the week, 24
hours per day)
Percentage of the CreditControl database 60%
changed each day (average)
Percentage of the PotentialIssue database 50%
changed each day (average)
Office hours (no full database activity permitted 08:00 to 19:00
during these hours)
Lab Scenario (Continued)

Existing Backup Strategy for CreditControl


Database
Recovery Model: Full
Type of Backup Schedule
Full Saturday 06:00
Wednesday 06:00
Differential Sunday 22:00
Monday 22:00
Tuesday 22:00
Thursday 22:00
Friday 22:00
Transaction Log Every 60 minutes on the hour
Lab Scenario (Continued)

Existing Backup Strategy for PotentialIssue


Database
Recovery Model: Full
Type of Backup Schedule
Full Sunday 22:00
Log Every 15 minutes, starting at 10 minutes past the hour
Lab Review

In this lab, you have learned how to plan a backup


strategy, configure database recovery models and
check that a chosen recovery model meets specific
requirements.
Module Review and Takeaways

Review Question(s)
• Best Practice

You might also like