Module 5

Recovery Models and Backup

Strategies
Module Overview

• Understanding
Backup Strategies
• SQL Server
Transaction Logs
• Planning Backup
Strategies
Lesson 1: Understanding 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
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
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 Notes

• Same Transaction Logs you know and love from

Exchange
• Purpose is to confirm ACID of transactions:
• A - Atomicity: All processes in an operation occur, or nothing
occurs
• C - Consistency: A transaction can only bring a database from one
state to another, and all data written to the db must be valid
• I - Isolation: Ensure that concurrent transactions leaves the db in
the same state that would be reached if the transactions occurred
sequentially
• D - Duraility: Ensures that even a failure will not undo changes
MAILBOX DATABASE EXAMPLE

Updates chkpt
file to show
trans was
successfully
written to db
Transaction Log File Structure

• Sufficient information is logged to be able to:

• Roll back transactions if requested
• Only for partially completed transactions
• 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 perform transaction 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 (checkpoints done based on outstanding writes)
• Indirect (based on user-specified target recovery time)
• Manual (you issue the CHECKPOINT command)
• Internal (part of service operations)

• CHECKPOINT statement configures the target

recovery duration
Demonstration: Logs and Full Recovery

In this demonstration, you will see how log

truncation works 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
• Use modified_extent_page_count to
determine whether to perform a differential or
full database backup
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: 20764C-MIA-SQL
Username: AdventureWorks\Student
Password: Pa55w.rd

Estimated Time: 45 minutes