What you will learn from this tip: Never forget that backups don't mean a thing if you can't restore your data. In a rapid-paced environment, a slow restore might not be an option. Rick Cook outlines how to get faster restores.
Backup is, famously, only half the data protection equation. The other half is restoring the backed up data, and restore speed is even more important than backup speed. A slow backup merely drags down the network. Restoring data brings everything to a screeching halt until the data is available to user again. Consider the following five points to refine your backup and restore process.
Test regularly
Sequentially, testing your backups should be No. 3 on this list. However, in terms of importance it's No. 1. If you can't restore your data, it doesn't matter what your theoretical restore speed is.
The first purpose of regular testing is to make sure you can restore the data you've backed up.
The second purpose of running regular test restores is to spot potential problems in your restore procedures. This can range all the way from sophisticated hardware or software problems to simple and embarrassing, screw ups. ("I thought you had the key to the tape cabinet!") This sounds silly, but glitches like this will add an amazing amount of time to the restoration if you haven't tested your procedures thoroughly.
The third thing test restores will do is give you an idea of how long a real restore will take.
Finally, consider how you'll rapidly restore in the event that one or more servers have failed. Are you going to have to wait for the vendor to deliver new hardware before you can get that information to users again?
Pick the right backup
Ideally, backup and restore today is a mix-and-match proposition. You should have a fast file restore capability based on near-current disk images oriented toward users. (Preferably with a self-service capability so users can restore file
To continue reading for free, register below or login
To read more you must become a member of SearchStorage.com
s and folders they have screwed up without involving the help desk or storage administrators.) Beyond that, intermediate disk-based backup can provide faster recovery in the event of most data loss events. Finally, as ultimate insurance, you should have archival backups on an offline medium, such as tape.
This three-layer approach lets you match the restore needs to the particular situation, ranging from a single file belonging to a fumble-fingered user to a complete bare-metal disaster recovery.
Back up wisely
Data pruning is at least as important in restores as it is in backups. The less stuff you back up, the less you'll have to restore. It's important to keep a critical eye on the data you are backing up to make sure you really need to save it.
Balance backup speed against restore speed
Since we don't do restorations nearly as often as we do backups, there's a natural tendency to organize things for fast backup at the expense of restores. This is a policy that will take a chunk out of your tailbone if you're not careful.
For example, incremental backups, which only back up the changes since the last incremental backup, are faster than full backups. However, you have to restore the last full backup first and then all the incremental backups since that point in sequence. A differential backup, which backs up all changes since the last full backup at each partial backup, is intermediate between the speed of a full backup and an incremental backup, but restores much more quickly than a series of incremental backups.
Faster still are synthetic backups, which merge the full backup and any changes into a single image. In theory, with synthetic backups you only have to make a single full backup and then just make incremental backups that are merged into the backup image.
Restore first things first
Ideally, your backup system should automatically restore the most important elements first. Of course, this assumes you know which services need to be restored in what order.
A prioritized restore won't actually speed up the restoration process, and indeed may cost some extra time, but in the event of a major failure it will make things move faster for the enterprise. (Not to mention taking some of the pressure off the administrators who are working to get things fully restored.)
About the author: Rick Cook specializes in writing about issues related to storage and storage management.
