Chapter 11: Designing a Data Recovery Solution for a Database MCITP Administrator: Microsoft SQL Server 2005 Database Server Infrastructure Design Study.

Chapter 11: Designing a Data Recovery Solution for a

Database

MCITP Administrator: Microsoft SQL Server 2005 Database Server

Infrastructure Design Study Guide (70-443)

Reasons to Backup

• Protect data against possibility of hardware failure

• Protect data against possibility of external disasters

• Protect data against human malevolence

© Wiley Inc. 2006. All Rights Reserved.

Backup Devices

• A place to put the backup. Can be disk, tape, etc

• Temporary backup device – useful for on the fly one-offs

• Permanent backup device – can be used over and over again


Type of Backup

• Full

• Differential

• Transaction Log backup


Full Backups

• Backup of entire database

• Needs to be done before you can do a differential backup or transaction log backup

• Can be done through Management Studio

• Can be done using T-SQL command BACKUP DATABASE


Differential Backup

• Copy of all changes made to database since last full backup

• Faster than full backup

• Used with full backup to restore database

• Best used with medium to large databases


Transaction Log Backups

• Backup of transaction log since last transaction log backup

• In event of restoration need all transaction log backups since last full backup


Filegroup Backups

• Used for VLDBs

• Typically used when database is too large to backup in reasonable timeframe

• Includes each file in the filegroup as well as all database activity that occurred while the file or filegroup backup was in process


Restoring Databases: Basic Steps in Event of Data Failure• Attempt to backup transaction log

• Find and fix cause of failure

• Drop the affected database(s)

• Restore the database(s)

• Can perform restore with– Management Studio– T-SQL commands


Restoring with T-SQL

• RESTORE DATABSE <database> FROM <device> <options>

• Options include:– RESTRICTED_USER– RECOVERY– NORECOVERY


Restores

• Standard Restore: restores entire backup

• Point in time: Used to reset database back to a previous state. Requires existing transaction log backup

• Piecemeal restores: used to restore primary filegroup and (optionally) some selected secondary filegroups


Backup Strategy: Full Backup Only

• Useful for databases that can be backed up quickly depending on size and hardware available

• One step restores

• Does not clear transaction log unless recovery model is Simple


Backup Strategy: Full & Differential Only

• Useful if databse is too large to backup fully each time

• Two step restore

• Differntial doesn’t clear transaction log, so use TRUNCATE_ONLY clause


Backup Strategy: Full with Transaction Log

• Backups are fast

• Transaction log backup allows for point in time restore capability

• Restores are slower


Backup Strategy:Full, Differential & Transaction Log

• Most common strategy

• Combines all three methods for best of all possible worlds


Desiging a Backup & Restore Strategy

1. Analyze business requirements2. Categorize databases based on recovery

criteria3. Assign a recovery model for each category4. Specify backups to support category5. Specify backup frequency policy per category6. Specify backup security policy for each category7. Document the backup strategy8. Create a backup validation and testing policy


Analyze Business Requirements

• What is volume of data loss that can be tolerated?

• How much downtime can be withstood?• What is the acceptable cost of potential

data loss?• Determine the time and cost of database

recovery.• Determine which databses are critical to

organization.


Categorize Database on Recovery Criteria

• Classify based on value of data

• Classify based on rate of change

• Classify based on size of data


Choose Recovery Model

• Can be specified for each database

• Three types of recovery model– Simple– Full– Bulk-Logged


Recovery Models

Recoverymodel

Benefits Data loss exposure Recover to point in time?

Simple Permits high performance bulk copy operations. Reclaims log space to keep space requirements small.

Changes since the most recent database or differential backup must be redone.

Can recover to the end of any backup. Then changes must be redone.

Full No work is lost due to a lost or damaged data file. Can recover to an arbitrary point in time

Normally none. If the log is damaged, changes since the most recent log backup must be redone.

Can recover to any point in time.

Bulk-Logged Permits high-performance bulk copy operations. Minimal log space is used by bulk operations.

If the log is damaged, or bulk operations occurred since the most recent log backup, changes since that last backup must be redone. Otherwise, no work is lost.

Can recover to the end of any backup. Then changes must be redone.


Guidelines for Assigning Recovery Model

• Use Full Recovery model for most critical databases

• Use Bulk-Logged if database makes extensive use of bulk operations

• Use Simple for databases with less critical recovery and performance requirements.


What Backups Are Need to Support Each Category

• Different categories of backup will need different combinations of backups

• All recoveyr models require a full database backup at regular intervals


Specify Backup Frequency

• Specify a periodically repeating backup schedule for each category

• Specify a rotation strategy


Set Backup Security Policy

• Specify chain of custody

• Ensure offsite storage location is physically secure and available

• Use a secure method of deliviering backups to their storage destination

• Protect backups using strng passwords

• Encrypt backup files and tapes


Document Backup Strategy

• Document backup strategies

• Make documents available to administrators executing the plan

• Specify backup schedule, dtabase recovery model, external storage locations


Create Backup Validation and Testing Policy

• Create one for each category

• Use DBCC CHECKDB command to check for allocation, structural or logical integrity problems


Developing Database Disaster Recovery Plan

• Plan should include:– Contact List– Decision Tree– Recovery Success Criteria– Location of Backups, Software,

Hardware, Keys and Activation Processes

– Infrastructure Documentation


Creating Disaster Recovery Decision Trees

• Provide model and instructions to handle high stress situations

• Classify Database Loss Scenarios into relevant groups with similar recovery paths– Natural or manmade disaster– Loss of single server or location– Loss of a single database– Loss of performance or service– Security failure


Disaster Recovery Decision Trees: Prioritizing Steps

• Identify most critical databses

• Identify critical processes

• List recovery steps in correctorder based on business needs

• Establish recovery success critieria


Document a Recovery Decision Tree

• Include recovery strategy for each disaster scenario

• Use flow chart or matrix• Specify category of disaster• Specify likely symptoms• List commands and operations to be

performed• Practicing and record recovery times for

each step© Wiley Inc. 2006. All Rights Reserved.

Maintaining a Recovery Plan: Best Practices

• Disseminate recovery plan• Periodically rehearse the recovery

plan• Periodically validate the recovery

plan• Revise based on outcome of

rehearsal and validations• Rehearse/revise whenever

infrastructure changes© Wiley Inc. 2006. All Rights Reserved.

Chapter 11: Designing a Data Recovery Solution for a Database MCITP Administrator: Microsoft SQL Server 2005 Database Server Infrastructure Design Study.

Documents

backup strategy

backup onlyuseful

backup transaction logfind

fasttransaction log

simple wiley

slower wiley

process wiley

userrecoverynorecovery