1. Data Disaster Recovery Planning Greg Fibiger 1/7/2016

2. Backup & Restore

3. 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

4. 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

5. 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

6. 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

7. Overview of SQL Server Transaction Logs Buffer Cache Data pages are located in, or read into, the buffer cache and then modified Data pages are located in, or read into, the buffer cache and then modified 2 2 Modification is recorded in transaction log on disk 3 3 Later, checkpoint writes dirty pages to database Later, checkpoint writes dirty pages to database 4 4 Data modification is sent by application Data modification is sent by application 1 1 Transaction logs provide a history of actions executed by a database management system to guarantee Atomicity and Durability properties

8. 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 SundayMondayTuesday

9. Transaction Log Backup Strategies SundayMonday 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

10. 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

11. Performing a Full Database Backup BACKUP DATABASE Legend Build 2.0 TO DISK = 'L:\SQLBackups\LB.bak' WITH INIT; BACKUP DATABASE Legend Build 2.0 TO DISK = 'L:\SQLBackups\LB.bak' WITH INIT; Backup entire database Backup active portion of log file

12. Performing Differential Backups BACKUP DATABASE Legend Build 2.0 TO DISK = 'L:\SQLBackups\LB_Diff.bak' WITH DIFFERENTIAL, INIT; BACKUP DATABASE Legend Build 2.0 TO 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

13. Performing Transaction Log Backups BACKUP LOG Legend Build 2.0 TO DISK = 'L:\SQLBackups\LB_Log.bak' WITH NOINIT; BACKUP LOG Legend Build 2.0 TO 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

14. 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

15. Restoring a Database RESTORE DATABASE Legend Build 2.0 FROM DISK = 'D:\SQLBackups\LB.bak' WITH RECOVERY; RESTORE DATABASE Legend Build 2.0 FROM 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

16. Restoring a Transaction Log RESTORE LOG Payroll FROM DISK = 'D:\SQLBackups\PayrollLogs.bak' WITH NORECOVERY; RESTORE LOG Payroll FROM 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

17. Always On Demo

18. Always ON Clustering (SQL Server)

19. Availability Group Architecture Windows Server Failover Cluster Database Active Log Synchronization Database Active 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

20. 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 ServerAServerBServerC PrimarySecondary HR DB HR DB HR DB Application retry during failover server HR_Listener;-catalog HRDB Connect to new primary once failover is complete and the listener is online HR_VNN AG_HR Primary

21. 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 Secondary Reports

22. 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 Primary Backups Secondary Backups Secondary Backups

23. BACKUP AND RESTORE DEMO

24. © 2016, The Sage Group plc. Thank you