burn to the ground?" All your data could be lost. Don't let this happen. Make sure that this storage company is not the only location for your backed-up data. Testing Your Backups I wish there were enough to say about this to make it a separate chapter, because it's that important. I can't tell you how many stories I have heard about people who wait until they need a major restore before they test their backups. That's when they find out that they've been using the wrong device or the wrong blocking factor or that the device had I/O errors. This point cannot be stated strongly enough. If you don't test your backups, then you are guaranteed to get a surprise sooner or later. Test Everything! It is important to test every type of restore. If you are testing filesystem backups, make sure you: · Restore many single files. Can you find the needle in the haystack? · Restore an older version of a file. · Restore an entire filesystem, and compare your results with the original. Are they the same size, and so on? · Pretend that an entire system is down, and try to re-create it. · Pretend that a particular volume is bad, and force yourself to use an alternate backup. · Retrieve a few volumes from your off-site storage vendor. · Pretend that your backup server is destroyed, and try to recover from that. (This one's tough!) This test is extremely important if you are using a commercial backup utility. Some products do not plan for this well, and you can find yourself in a real catch-22 situation. If you are testing database restores, make sure you: · Restore part of your database, pretending that you lost only one data file or disk drive, if this option is available. · Restore the entire database onto another server; this is where you learn about files that you are not including. · Restore the database up to a point in time, earlier than the present time (this is helpful to recover from a DBA or user error). · Pretend that last night's backup failed, and force yourself to use an older backup. Theoretically, if you have saved all your transaction logs to a backup volume, you should be able to use a backup that is weeks old and roll it forward to the present time using those logs. This is another strong argument for using transaction logs. Testing Your Backups | 53