Disaster Recovery: How to Test Your Disaster Recovery Plan

Published by Rich Tepper at October 7, 2015

Tags

In our new series, we’re covering everything you need to know to create a disaster recovery plan. Our last post provides tips for testing your plan.

At this point, you hopefully have spent some time determining what needs to be backed up and how often you need to run your backups in order to have an acceptable recovery point. Time to sit back and relax, right?

Not just yet! Sit back up.

There is one more task you should accomplish. In order to feel confident in your backup plan, you need to test it to verify that the backups are consistent. The other main reason to test the backup is to make sure that you have your recovery plan documented.

So start up your favorite word processing program to document, fire up a virtual machine somewhere, and let’s try to restore your server.

I suggest a virtual machine because it will be the most cost-effective way to test. You can even test your restore using your desktop computer. If you have Windows 8 or greater, you can use Hyper-V. Alternately, you can try a third party app like Virtualbox, which also runs on Mac OSX (if that is your preference).

If your server needs far exceed what your desktop virtual environment can provide, then you may need to purchase hardware for your test restores. While this can be expensive, you should consider the fact that if your environment is that robust, it should be worth the additional cost to have hardware for a test restore. This hardware could also be used as a cold spare in case disaster strikes. If you have the correct licensing, you could even use your spare hardware as a warm spare with the built in Hyper-V replication features of server 2008 R2 and 2012. (That is a subject for another blog post though.)

Here is a list of items that should be included in your disaster recovery procedure documentation:

Hardware requirements. Most likely, you know what your minimum spec is. But what happens if you are not around and the environment has been destroyed? This also includes partition sizes (or minimums) for all of your server drives.
All media and installers needed to restore the environment. This includes the location the media is stored in or can be downloaded from. You should also include all necessary license keys (or the location of the keys if they are secured).
Any Operating System or application settings specific to your environment. You should include this if your backup is data only and not a bare metal restore. Server IP addresses for example, or DHCP range settings if the server is a DHCP server.

Now run your recovery. Make sure you note every step in your documentation. Your goal should be to create a document that anyone can follow to restore your server. Plan to spend a good amount of time doing this on your first attempt. It would not be abnormal for it to take 8-10 hours to get your first restore completed and documented, not including the time spent pulling the data back from the recovery media. There is a very good chance you will have to start from scratch at least once during the procedure.

Remember: Google is your best friend. If you get a strange error, look it up. Chances are, someone else has experienced the same problem and can help you out with their documentation.

Try to pay attention to the time it takes to do the steps while you are restoring. Make a note of the recovery time from the media. Then think about how long the steps would take if you did not have to write the documentation at the same time. If you keep good track, you will have a time estimate you can include with your recovery document that will give future readers an expectation about how quickly the data can be restored.

Once your restore is completed, make sure you test it. A server booting up does not mean it is working correctly. Review the event logs. If you see anything out of the ordinary, research it to make sure it is not a sign of an issue. Test all of your applications. If there are databases, make sure they are functional. If your server hosted mail, try connecting a user to verify that the mail is accessible.

When your testing is complete, find a safe place to store your documentation. I would recommend storing a copy with your recovery media and in at least one other location.

Now you can relax with the peace of mind that your backups are viable and well documented.

Are you running into issues with testing your disaster recovery plan? Share your thoughts in the comments!

Series NavigationDisaster Recovery: 4 Tips for Creating Your Disaster Recovery Plan