Professional SQL Server™ 2005 Programming

24.2. Backup and Recovery

No database-driven app should ever be deployed or sold to a customer without a mechanism for dealing with backup and recovery. As I've probably told people at least 1,000 times: You would truly be amazed at the percentage of database operations that I've gone into that do not have any kind of reliable backup. In a word: EEEeeeeeek!

There is one simple rule to follow regarding backups — do it early and often. The follow up to this is to not just back up to a file on the same disk and forget it — you need to make sure that a copy moves to a completely separate place (ideally off-site) to be sure that it's safe. I've personally seen servers catch fire (the stench was terrible, as were all the freaked out staff). You don't want to find out that your backups went up in the same smoke that your original data did.

For apps being done by the relative beginner, then, you're probably going to stick with referring the customer or on-site administrator to SQL Server's own backup and recovery tools, but, even if you do, you should be prepared to support them as they come up to speed in its use. In addition, there is no excuse for not understanding what it is the customer needs to do.

24.2.1. Creating a Backup — a.k.a. "A Dump"

Creating a backup file of a given database is actually pretty easy. Simply navigate in the Object Explorer to the database you're interested in, and right-click.

Now choose Tasks and Back Up, as shown in Figure 24-14.

And you'll get a dialog ...