Disaster Recovery 'Databases'

Disaster recovery 'databases' is a very broad subject so in this particular case I will just focus on one and that will be in the world according to Microsoft. This is not meant to be a definitive guide on all possibilities but more of an advice to the layman.

Disaster recovery 'databases' - Disaster Recovery Strategy

This is a list of well-documented steps, which will assist an organization in restoring production operation after a disaster strikes. A disaster can be defined as any incident that may result in production outage, e.g. server hardware failure, site disaster, nuclear holocaust (only kidding).

Disaster recovery 'databases' - Factors to Consider

Some of these factors are:

• How critical is the data to the operability of the organization's core business?
• How much data can the organization afford to lose (which may be recreated or reentered) in case there is a disaster?
• How much downtime can the organization afford if there is a disaster and how much downtime can the organization allocate for regular database maintenance?
• What kind of funding and resources are available for the disaster recovery plan?

Disaster recovery 'databases' – Recovery options for SQL Server

Clustering

Refers to architecture where two or more nodes may be set up to share disk and some other resources. These shared resources are owned by the active node. This architecture provides protection against server failure.

However, it does not protect against failure of the shared resources. This is probably the reason that clustering is more often referred to as a High Availability solution rather than a disaster recovery solution. A High Availability solution refers to hardware architecture that is designed to withstand a partial outage.

SQL Database Backups

SQL Server databases may be backed up in a variety of modes. These backups may eventually be used to recover the production environment in case of a disaster.

Log Shipping

Log shipping is a process of backing up, copying, and restoring transaction log backups to a warm standby server.

Complete Database Backups

A complete database backup backs up all information stored in the respective database. A complete backup provides the easiest means of recovery in a disaster situation. The downside is that this takes the longest to complete.

Differential Database Backups

A differential backup backs up portions of the database that have been modified since the last complete backup. These backups are cumulative, meaning the most recent differential backup contains changes from previous differential backups.

Transaction Log Backups

Transaction log backups back up the changes that have been logged in the transaction log for a database. Transaction log backups could be performed at more frequent intervals than differential backups. The downside would be the management aspect of managing a large number of transaction log backups.