Consultant Peter Herbener has compiled a series of disaster recovery worst practices based on his experience. One way to really mess up is not testing your backup method adequately. If you're struggling with the basics, here are some tips to get back on track.
It's not surprising that small businesses neglect to test their backups. It is surprising that even some large shops are guilty of this. They'll set up their policies and procedures, schedule automated backup scripts, start running backups, and assume everything will be fine.
If you never actually try to restore a file, an application, or a server, you don't really know if you can. Also, it's tempting to water down tests so that they're virtually guaranteed, but these kind of tests don't tell you what can happen in reality.
DR worst practices
Don't miss the rest of the series:
- Disaster recovery worst practices: Don't perform backups on a regular schedule
- Disaster recovery worst practices: Save money on backup media
- Disaster recovery worst practices: Don't look at your logs
Download the complete disaster recovery worst practices series in PDF format.
Nightmare: Restoring from the backup didn't work
One thing that you may find while testing is that your backups will work just fine, but only if you restore them to the exact computer from which you backed them up. It's easy to just assume that you can buy a new computer and restore, but you can run into some surprises:
- Some people forget that you need to reinstall the backup software to be able to read and restore from the tape drive. Make sure you have the install disks for your backup software handy. Store these with your backups.
- The most annoying surprise was a tape drive and its software that would not restore to a hard drive that was not exactly the same size as the one originally backed up. If your hard drive failed, you had to make sure your replacement was the exact same size as the original, or else you couldn't restore your data.
- It seems obvious that you need the same kind of tape drive and the same backup software.
- You might find out too late that two versions of backup software that were supposed to be compatible actually weren't.
- You realize you don't have the right configuration settings, plug-ins, or drivers. It's common to find that a new application doesn't install correctly, but after a couple of days of exchanging e-mails with the vendor's tech support, you finally get the correct settings. It's probably something simple -- once you know it. If you don't have this information documented and stored with your backups, you'll waste time repeating the investigation when you have to restore.
Don't just write down those procedures and install tips and stick them in a filing cabinet somewhere. You'll never find them when you need them. Put them in a text file where they'll be backed up and restored along with the application or its data.
How people fool themselves into thinking they're testing their backups
Mistake: Test with a "special backup."
Some people won't use a regular backup tape. They'll run a special backup in preparation for a disaster recovery test. This way, they make sure that a backup runs "cleanly" by getting all the users out of the system, running the backup manually, and watching for problems.
This is asking for trouble.
First, if your regular backups have so many problems that you can't count on them for a test, how will you be able to count on them during an actual disaster? You won't.
Second, we're human. We might know what files and directories we want on the regular backups. There's a chance we can set that up wrong, so important files don't get saved. Then, if you do a special backup, you might really get all of the files and directories that you meant to get all along. That test might seem to succeed, but that didn't test how well your regular backups work. It tested how well you do special backups.
Do you already have a "test" server or some kind of "model office" environment for testing new releases of software? This can be a great resource for testing your backups. Instead of building a test environment from scratch, grab a backup tape and build your test environment from a restore. This lets you practice restoring, helps try out your backups, and should be a more accurate test environment.
Mistake: Only try a few sample files.
It's good to do this when you're first setting up your backups: Create a couple of spreadsheets or word processing files, run a backup, delete the files, then try to restore them. For a real test, you should go further. Can you restore entire directory trees? Can you restore the entire computer or server? Will you need to reinstall any programs?
Mistake: Only test performing a restore to the original computer or server.
If you restore back to the same computer, you eliminate a couple of important things from your test. You might have forgotten about compatibility or configuration problems that you took care of when you set the system up.
Best practices for testing backups
- Test with tapes (or whatever media you use) from your regular backups.
- Don't just spot test a couple of files. Make sure you can restore entire directories, servers, or applications.
- Do a test restore to a different computer or server.
- If you can afford it, have the same model of tape drive at another location. Test it to make sure it's really compatible! If you can't afford that, at least make sure you know the exact model of your tape drive and know where to get one in a hurry.
- Make sure to keep a copy of the install disks for your backup software with your backups.
- Make sure to document the procedure for restoring or reinstalling applications, especially any special tips or tricks. Put this into a text file in the application so that it gets backed up with everything else.
TechRepublic's free Server NetNote newsletter provides valuable insight into deploying, planning, and purchasing hardware for your data centers and server room. Automatically sign up today!