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

June 21, 2002


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








The Network for Technology Professionals

Search:

About Internet.com

Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers