Data Disaster Recovery PlanningGreg Fibiger

1/7/2016

Backup & Restore

Determining an Appropriate Backup Strategy

Different backup types can be combined

- Data based Backups (Full, Differential, Copy, Filegroup, File)

- Log based Backups (Log , Tail Log)

Safety levels should be determined

- How long can recovering take? (RTO)

- How much data is it acceptable to lose? (RPO)

- Is it possible to recover the data from other sources?

Backup strategy should be mapped 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

Backup sets are written to media sets that are comprised of one or more backup devices

Media sets can contain several backup sets

Backup devices can be physical or logical

- Physical devices are disk files

Not all users can perform backups

Determining a Retention and Testing Policy for Backups

Planning for backup retention must be part of the strategy

- Should form part of the test plan to ensure accuracy

Several considerations:

- Combination of backups needed for a database recovery

- Archival requirements

- Synchronisation with database checks

- Available secure storage location

- Hardware required for restoring backups

- Completeness of backups

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

Overview of SQL Server Transaction Logs

Buffer Cache

Data pages are located in, or read into, the buffer cache and then modified

2

Modification is recorded in transaction log on disk3

Later, checkpoint writes dirty pagesto database

4

Data modification is sent by application1

Transaction logs provide a history of actions executed by a database management system to guarantee Atomicity and Durability properties

Full Database Backup Strategies

Full Database Backups:• Backup all data and part of the log records• Can be used to restore the whole database• Permit recovery to backup times only

Sunday Monday Tuesday

Transaction Log Backup Strategies

Sunday Monday

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

Monday Tuesday

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

Performing a Full Database Backup

BACKUP DATABASE Legend Build 2.0 TO DISK = 'L:\SQLBackups\LB.bak' WITH INIT;

Backup entire database

Backup active portion of log file

Performing Differential Backups

BACKUP DATABASE Legend Build 2.0TO DISK = 'L:\SQLBackups\LB_Diff.bak' WITH DIFFERENTIAL, INIT;

• Backup the extents changed since the last full database backup

• Store active part of the transaction log to be able to recover the database

• Independent of other differential backups

Note: You cannot create a differential database backup if no full backup has ever been created

Performing Transaction Log Backups

BACKUP LOG Legend Build 2.0TO DISK = 'L:\SQLBackups\LB_Log.bak' WITH NOINIT;

• Backup the transaction log only

• Backs up log from the last successfully executed log backup to the current end of the log

• Truncates inactive log records unless options specified Note: Database must be in full

or bulk-logged recovery model

Options for Ensuring Backup Integrity

Mirrored Media Sets

A backup set can be mirrored to up to 4 media sets

Mirrors require the same number of backup devices

Support in Enterprise Edition only

CHECKSUM backup option

Available for all backup types

Generates a checksum over the backup stream

Can be used to verify the backup

Backup verification

RESTORE VERIFYONLY can be used for backup verification

Useful when combined with the CHECKSUM option

Restoring a Database

RESTORE DATABASE Legend Build 2.0FROM DISK = 'D:\SQLBackups\LB.bak'WITH RECOVERY;

• Full and differential backups are restored using the RESTORE DATABASE statement

• Only the last differential backup needs to be restored

• Restore each backup in order and WITH NORECOVERY, if additional transaction log backups need to be restored

Restoring a Transaction Log

RESTORE LOG PayrollFROM DISK = 'D:\SQLBackups\PayrollLogs.bak'WITH NORECOVERY;

• Transaction Log Backups are restored using the RESTORE LOG statement

• An unbroken log chain sequence must be provided

Always On Demo

Always ON Clustering (SQL Server)

Availability Group Architecture

Windows Server Failover Cluster

DatabaseActive Log Synchronization

DatabaseActive Log Synchronization

Availability Group uses Windows Server Failover Cluster (WSFC) for WSFC Common Microsoft Availability Platform

SQL Server AlwaysOn Failover cluster instances

SQL Server AlwaysOn Availability Group

Microsoft Hyper-V

Microsoft Exchange

Built-in WSFC workloads (e.g. file share, NLB, etc) and third party workloads

Inter-node health detection,

Failover coordination,

Primary health detection,

Distributed data store for settings and state,

Distributed change notifications

Application Failover

Availability Groups Listener allow applications to failover seamlessly to any secondary

Application reconnects using a virtual name after a failover to a secondary

ServerA ServerB ServerC

Primary Secondary Secondary

HRDB

HRDB

HRDB

Application retry during failover

server HR_Listener;-catalog HRDBConnect to new primary once failover is complete and the listener is online

HR_VNN

AG_HR

Primary

Active Secondary – Making Secondary Readable

SQLservr.exe

InstanceA

DB2DB1

Reports

Failover

SQLservr.exe

InstanceB

DB2DB1

Reports

Readable secondary allow offloading read queries to secondary

Close to real-time data, latency of log synchronization impact data freshness

Primary PrimarySecondary Secondary

Reports

Active Secondary: Enabling Backup On Secondary

• Backups can be done on any replica of a database

• Backups on primary replica still works

• Log backups done on all replicas form a single log chain

• Database Recovery Advisor makes restores simple

R/W workload

PrimaryBackups

Secondary

Backups

Secondary

Backups

BACKUP AND RESTORE DEMO

© 2016, The Sage Group plc.

Thank you