|
"The first time you use your backups shouldn't be the first time you need them"
- A Wise Systems Administrator
Testing, testing, testing...
If you think your responsibility ends with getting your backup software to report "Backup Job Completed Successfully" then you might want to re-evaluate what your responsibility really is.
The reason you do backups is because you might need to retrieve data in the event of a disaster. If you never actually test your backup data, preferably in the manner you would in a real disaster, how do you know if it will be successful? Do you really want to bet your company and the livelihood of all your colleagues on the "Backup Job Completed Successfully" report? Hopefully not.
Now is the time to take backups and disaster recovery seriously. There are so many risks to your company's data it just can't be ignored:
Fire, earthquake, tornado, flood, hurricane, theft of your computer(s), viruses, malware, hackers, disgruntled employees, user errors and many many more...
So how do you make sure you can actually recover your data, and therefore your company, in the event of a disaster?
Test, document, prepare and repeat.
- Most Admins have retrieved a file from their backups. This is fairly straightforward.
- Some Admins have restored entire folders.
 A few Admins have recovered a complete database.
- Even fewer have recovered an entire system and possibly a mission-critical server.
- Fewer still have recovered an entire system to dissimilar hardware from the original.
- Hardly any Admins have recovered an entire system to dissimilar hardware at a different location, plus get all their key applications running in a timely manner, and keep the C-Level management off their back!
What level of testing have you performed in the last 90 days?
What would your day be like if a critical production server (i.e. Exchange, Online Ordering Web Site, etc.) went down hard and the system needed to be replaced?
There are so many important things to consider when you're planning to restore data.
- Backup Software. Most backup software needs to be loaded before you can restore your data. Do you have a copy of your backup software and software license keys with your off site tapes?
- Identical Hardware. Unless you have an identical system to your production system, off site, with your backup tapes, then you need to test using different hardware. Typically, in the event of a disaster you're trying to get up and running again on whatever you can borrow or buy as fast as possible. This equipment won't match exactly what you're using today. So when you do your testing make sure to test with dissimilar hardware. You'll be surprised how many extra steps and gotchas can make your recovery fail, or at the very least take a lot longer. Try to work out the gotchas and document them so you are prepared when disaster strikes.
- Tape Device. If you are backing up to tape, guess what, you'll to need to restore from tape as well. If your office building (and equipment) are ever destroyed, you need to have the same tape drive technology to perform the recovery. How fast can you buy a tape drive and have it delivered? Most people use a tape library to automate the changing of tapes during the backup. A good idea might be to keep an external standalone (emergency spare) version of the tape backup system at an off-site location, or remote office just in case it's needed. You don't need a big tape library system, since you can easily change tapes by hand. A small tape drive unit is inexpensive and uses very little space. Plus single drives are very portable and can be taken wherever you happen to be traveling to. Keep this tape drive with your backup software, including the backup tapes along with the spare system if you have one, storing it all off-site.
- Your CFO announces... We need some financial data from 2004, can you restore that? From 2004 to 2010 most backup software packages will have been upgraded between 3 and 7 times. If you are running version 12, can you recover tapes from version 8? You'll never know unless you test for it. Perform your backup testing activities as often as your company or industry policy dictates, but make sure to calendar the task and do the testing. Keep in mind, your server operating systems and hardware are changing all the time as well. You may need to keep copies of older operating system software, and even older versions of the hardware that was installed going back 3, 4, 5 or more years ago. All of this should be stored safely at a different location and readily accessible for use in the event any older data needs to be retrieved.
- Virtualization. If you've adopted a virtualized environment it's likely your life is a little easier in regards to hardware compatibility and data recovery. Having said that, you still need to test your restore capability. Like everything else in the IT world, virtualization software versions and server hardware are constantly changing.
- Keep it real. The best way to test your data recovery plan should be based upon your most "Likely Scenario". Begin by taking considering which natural disasters or events have the highest potential to occur that would require you to initiate your disaster recovery plan. If you're in the southern or eastern states, hurricanes are a major threat. In the western states, we have more concerns about earthquakes and wildfires. Maybe you're in a mid-western floodplain, so you have the risk of flooding in your building. If you have frequent "dirty-power" issues or outages, then data corruption can be a serious problem. Whatever your likely scenarios are, plan and test for those first.
Next month we'll talk about the importance of documenting your testing and where to keep your recovery plan once it's created.
|
