Preparing for disaster recovery

The following topics discuss preparation for disaster recovery:

Recommendations for disaster recovery preparation

Preparing for disaster ahead of time is key to recovering from it. The first steps to recovery from catastrophic failure of an SQL Server should take place long before the event occurs. Every environment and site is unique, and every company has different requirements that depend on the critical nature of the data stored. Taking these differences into account, consider the following general disaster recovery preparation recommendations:

Locate the archive media, such as a NearStore system, off site or at a remote location.
Establish a policy of redundant knowledge by ensuring that more than one person knows how to restore the system.
Maintain detailed records and change logs and ensure that they are always available.
Perform mock disaster recovery processes on your nonproduction SQL Servers to become acquainted with real-life situations.

Components required to recover your SQL Server

To be able to reconstruct your SQL Server environment after a catastrophic failure, you recover the following three components:

Windows environment

You can either back up or replicate your Windows environment. For more information about backing up your Windows environment, see Backing up your Windows environment.

SQL Server

Back up your SQL Server. For more information about backing up your SQL Server, see Backing up your SQL Server.

SQL Server databases

You use SnapManager to create backups of your SQL Server data, then move that data off site, either by archiving those backups or using SnapMirror to mirror them to another filer at a remote site.

Methods for getting SQL Server data off site

Choose from among the following methods for getting your SQL Server data offsite in preparation for disaster recovery:

Use SnapMirror to mirror your storage system data to a storage system in another location. For more information, see Chapter 12, Replicating Backups to Mirrored Volumes.
Archive the data to physical media, such as tapes, and store that media offsite. For more information, see Chapter 13, Archiving SnapManager Backups.
Automatically archive SnapManager backups using SnapVault. For more information, see Automatically archiving SnapManager backups using SnapVault.

The following table summarizes advantages and disadvantages of each method.

Method to get SQL Server data offsite	Advantages	Disadvantages
Using SnapMirror	Restoring from a SnapMirror destination is significantly faster than restoring from tape. The destination can be updated more frequently than by using tape, resulting in more current data.	Requires another storage system in the remote location. Requires WAN connectivity to the remote location, with sufficient bandwidth. Mirrors only backups sets that are on the source storage system.
Archiving SnapManager backups to tape	The required equipment might already be available and in use.	Restoring from tape is significantly slower than restoring from a storage system. Tapes must be stored and managed.
Archiving SnapManager backups using SnapVault	Restoring from a SnapVault archive is faster than archiving from tape. The destination can be updated more frequently than by using tape. Backup sets that are no longer available on the primary storage can be retained.	Requires another storage system in the remote location. Requires WAN connectivity to the remote location, with sufficient bandwidth. Recovery requires data to be replicated back to the original storage system.