SQL Server 2000 Administration in 15 Minutes a Week: Creating a Disaster Recovery Plan (Part 1)

Welcome to the eighth
article in my series SQL Server Administration in 15
Minutes a Week. A few weeks back we took our first look at
Database backups. This week we will quickly review the
recovery models before discussing how to prepare a
disaster recovery plan. The topics for this
week include:

–
Recovery Models Review
– Creating a Disaster Recovery Plan

Recovery
Models Review

Something you will start to
notice as we get further into SQL Server is that most
settings and options tend to be more of a balancing act than they
are right or wrong. In other words, you will need to weigh
the benefits and drawbacks of using one option over
another. A good example of this would be the recovery
models that we looked at in the last article. Some models
allow for fast backup and use less disk space, but they
don’t provide the recovery options of other recovery
models. Because this is an important part of your backup
strategy, I would like to do a quick review of the three
recovery models available with SQL Server 2000.

Simple

• Uses full and differential backups
• Recommended for development only, not for production
  databases
• Bulk copy operations are fast and do not require large
  amounts of log space
• Once log entries are no longer needed for recovery
  (after a checkpoint), log file space can be reused to
  keep log files small
• If a failure occurs you can recover up to the point of
  the last full or differential backup, all data after the
  last full or differential backup will have to be redone

Full

• Uses full, differential, and log backups
• Recommended for production databases
• Bulk copy operations must be logged row by row
  resulting in slower bulk operations and the requirement
  of more log file space
• Log file space can’t be reclaimed until the log file is
  backed up
• Transaction log backups 
• If a failure occurs you can recover to any point in
  time
• If a data file is lost or damaged, no work is lost

Bulk_Logged

• Uses full, differential, and log backups
• Recommended for production databases when you need to
  perform many bulk operations
• Bulk copy operations are not logged row by row
  resulting in faster bulk operations and lower log file
  space requirements
• Log file space can’t be reclaimed until the log file is
  backed up
• If a failure occurs and no bulk operations have
  occurred since the last full/differential backup, you can
  recover to any point in time of a log backup. If bulk
  operations have occurred, you can recover to the end of
  any backup.