What you will learn form this tip: This tip highlights an aspect of backup that most are not as experienced and comfortable with -- restoring.
Attempting to make a distinction between backup and restore may seem like pure semantics at first; after all -- don't we always refer to backup and restore as one discipline?
((Content component not found.))
Chances are, your data backup administrators have become experts at making sure backups run successfully each night. Over the years, they have likely fine-tuned numerous performance parameters and adjusted schedules to better utilize available hardware resources and capture data at the best time. This experience was acquired through years of daily backups. However, the same cannot be said about data restores and this is probably why we seldom use the term "restore administrators."
Ironically, we spend years learning how to master backups and then one day we are faced with having restore an entire environment in 24 hours! Shouldn't we learn to master the restore process instead? The problem is that we don't restore often enough, and when we do, it is typically a partial restore.
As we design our backup strategy, we need to start planning for restores. Here are a few items that should be addressed in order to increase the efficiency of the restore process:
Complete restore test: The ability to successfully restore critical applications from backups should be tested regularly. Avoid shortcuts; every step of the process should be executed and reviewed for possible issues. Restored data must also be validated to ensure everything is as it should be.
Documentation: As the above restore test is performed, each step should be documented. This will ensure that a single employee does not possess all the knowledge. The documented procedures can then become part of a master plan.
Restore dependencies: Some components of an environment need to be recovered before others can be restored. It is surprising to see how often authentication and networking is overlooked. This must be understood and documented.
Restore priorities: It is essential that the restore priority of applications be clearly established ahead of time by the various business functional areas. The IT team can only restore so many applications at once and unless properly informed, IT will set priority based on their understanding of criticality.
Know what to restore: If your recovery strategy includes a number of standby systems with a loaded operating system and applications, is it necessary to restore any of those files? This requires some backup planning to avoid having to sort out what to restore after the fact.
Backup data retention: How backups are expired must be closely monitored and managed. For example, the relationship between full database backups and associated logs must be clearly understood. Don't assume that automated deletion always works flawlessly and give it a regular check.
Have a plan: Last but not at all least is to have a plan. The critical applications recovery procedures must include the data restore and validation procedures. These procedures are then included as annexes to the disaster recovery plan and ultimately, become part of the overall business continuity plan.
Do you know…
How to take full advantage of the remote replication process?
How to prepare for next-generation backup?
About the author: Pierre Dorion is a certified business continuity professional for Mainland Information Systems Inc.
