Section 2.7. Testing Your Backups


2.7. 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 waited until they needed a major restore before they tested their backups. That's when they found out that they'd 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, you are guaranteed to get a surprise sooner or later.

2.7.1. 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 drive or 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 recreate 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 an open-source or 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 practice for recovering 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.

2.7.2. Test Often

As I said earlier, sit around one day with some really pessimistic people, and ask them to dream up scenarios for you to test. Test your ability to recover from each of these scenarios on a regular basis. What works this month might not work next month. The only thing that is guaranteed to remain constant is change. One suggestion is to create a list of recovery procedures and randomly test a subset of them every month. Management changes, hardware changes, networks change, and OS and database versions change. Every change you know about should make you want to perform a test of the affected area.




Backup & Recovery
Backup & Recovery: Inexpensive Backup Solutions for Open Systems
ISBN: 0596102461
EAN: 2147483647
Year: 2006
Pages: 237

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net