Acommon IT manager's nightmare: A critical production database has become corrupt and must be recovered. You turn to your first line of defense--your business continuance mirrored volumes, but alas, the corruption predates the split times. You swallow hard, and your pulse quickens. You must now turn to your fail-safe solution--your nightly backup. You launch the client recovery GUI for your backup application, and begin searching for the volume to restore. Beads of sweat form on your forehead. Your heart begins to pound. You can't find this volume in last night's backup list. You search through the backup history, only to discover that the most recent backup of this volume is more than two months old. You seriously consider your resignation as you ponder explaining this to executive management tomorrow.
In our backup practice, it isn't uncommon to hear of failed recovery attempts of critical data. The problems can range from low-level technical glitches to serious omissions and operational breakdowns that lead to nightmare scenarios. However, the conversation ultimately concludes with the same plea for help: "How can I have confidence that I can recover my data?"
The first step is to have detailed backup metrics and reporting about the data. Too often, backups lack one of the fundamental elements of any quality control process--feedback. If you have clearly defined policies for data management, how do you know those policies are being carried out? If you have established SLAs with users, how do you or your users know if these SLAs are being met? How do you know that your backup infrastructure can support foreseen (and unforeseen) growth? Where exactly is your data? Is it safe? Can it be recovered? When the CIO asks you to guarantee the recoverability of critical corporate data, can you make that promise--without blinking?
