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.

Page 2: Creating a Disaster Recovery Plan

 »


See All Articles by Columnist
Michael Aubert

Latest Articles