Backup is Nice – Recovery is Nicer
It’s 6:30pm on a Friday night, and your director, VP, or worse the legal department, needs some specific data from three months ago, and they need it now.
How confident are you that you can recover it for them? And how long will it take you?
If this all-important data is not online or near-line, you will have to go into restore/recovery mode for the next 6 to 24 hours, possibly longer, depending on how often you test the recovery/restore mechanisms that are supposed to “just work.”
Herein lays the problem of backup and recovery for most companies. While we all know it’s important, we may not realize how much so until a critical need to recover data occurs.
Backups or the backup process is often touted by IT managers as akin to an insurance policy: Most hope they will never use it. If they do, they expect it will work. And unless it breaks, no-one really is motivated to revisit their initial decision on which backup process to use.
What does drive businesses to re-evaluate their backup process? Here are some scenarios:
1. Poor performance of the backup process compromises backup windows
2. Backup windows are barely or not being met on a given day
3. Current tape technology is a hassle and is causing business flow or data management problems
4. Lack of understanding of the current environment due to downsizing or changes in business direction
5. Change in required features due to policy changes, causing new retention based on resulting business drivers
Any of these reasons and many more, might cause you or someone at your company to revisit or re-examine the current backup infrastructure and policies.
Just remember: Successful data backup does NOT necessarily equal successful data restore.
Another possible and fairly common scenario is the need to validate restores on old or sub-standard hardware in a DR facility. This unfortunately is often the case and can cause increased delay to test restores as well.
This leads me back to the bigger problem in most organizations: they have the backup process wired and working, but unless there is an actual disaster that demands they restore data, testing restores is rarely done, if ever.
This one aspect of Backup and Recovery best practices may seem very simplistic, but is indeed the “Achilles’ Heal” of pretty much every backup process. Like the insurance policy that folks compare the backup to, a policy is completely useless without a payout on the policy.
This means that developing a set of restore and recovery guidelines is almost more important than the backup, especially where Service Level Agreements are involved. Any one set of backups could have their own separate restore procedures as well, and probably should, because no one type of data is identical to another, especially where different business units are involved.
Simply put, restoring data for a finance or legal department user will have a different set of rules, owners, and priority than a customer support department user. Performing recovery for a server that services each of those departments will need similar documented priority and process specifics.ma
Once this kind of information has been determined, it is vital to actually test these restores on similar hardware and software which the services and data is intended to be accessed. We recommend that this is done fairly regularly in conjunction with backups.
Testing restores will prevent unforeseen circumstances from arising one day when retrieving backup is truly required. Working this type of activity into a regular IT/Support activity is highly recommended for best performance and may even yield some required changes the first few times through. But it’s better than getting caught one day with no backed up data in hand.
Because while backup is nice, recovery is way nicer.