Microsoft® SQL Server® 2008 Bible

Chapter 41. Recovery Planning

IN THIS CHAPTER

• Understanding the recovery models

• Backing up user databases

• Understanding and working with the transaction log

• Recovering a lost database, a lost system database, or the entire server

The foundation for this book, the Information Architecture Principle (introduced in Chapter 2), puts into words the reason why there must be a solid recovery plan.

Information is an organizational asset, and, according to its value and scope, must be organized, inventoried, secured, and made readily available in a usable format for daily operations and analysis by individuals, groups, and processes, both today and in the future.

It goes without writing that for information to be "readily available ... both today and in the future," regardless of hardware failure, catastrophes, or accidental deletion, there has to be a plan B.

Obviously, this is an imperfect world and bad things do happen to good people. Since you're bothering to read this chapter, I'll be honest and agree that doing backups isn't very exciting. In some jobs excitement means trouble, and this is one of them. To a good DBA, being prepared for the worst means having a sound recovery plan that has been tested more than once.

Consistent with the flexibility found in other areas of SQL Server, there are multiple ways to perform a backup, each suited to a different purpose. SQL Server offers three recovery models, which help organize the backup options and simplify database administration.

This chapter ...