Backup vs. Recovery: Why Planning Ahead Prevents Data Disasters
You've returned after a long weekend off to find that your servers have crashed. Now, no one can get any work done. Nothing is working the way it should, and although the day-to-day process is fine, you can't access any of the files you were working with on Friday.
It's okay, though. You stroll down to your CIO's office and have him get to work on accessing the backup data.
The problem is that backing up data isn't the same as recovering data in the event of a server crash or some other disaster. Hopefully, you followed our three-step plan to prepare for a situation like this.
1. You kept restoration in mind when you created your backup systems.
The best idea is to begin with the end in mind. Data backup is not always the same as data recovery. From a backup perspective, the goal is not to recover from the backup, but to back up data as quickly as possible. If the backup systems aren't designed with the end goal of putting the pieces back together afterwards, you might as well not be backing up at all. Some systems store in such a way that, when it comes time to restore from that data, it's like attempting to put together a million-piece puzzle. Make sure the company you work with to handle your backup data is working with the intent of being able to recover from this data, and not just have the backup without the intent to use it.
2. You put the right people in charge of recovery, with the right tools and processes.
Try to imagine that your entire IT team is off when the servers crash. The Windows guy can't come in, your Oracle guy doesn't want to travel, and half the programs in your backup are outdated or based on older operating systems. You need to ensure not only that you have the right people, but also that they have access to the right tools and processes at the time that you need them.
3. You check the backup system regularly.
Now imagine that you've planned the systems from the ground up with recovery in mind and have all the right people, tools, and processes... but no one has checked that the backup was working correctly in several months. A prime example is a server crash in New Orleans in 2010.
They hadn't verified that everything was backing up accurately, so they didn't know the chaos. The program for backups had recently been updated, and although a correct installation message had been sent, the system had a fatal flaw. When their servers crashed, they found that the program hadn't been sending good data since July and all records dating back to 1980 were being lost in monthly purges. All the data being sent nightly was garbled and utterly unusable in recovering the systems.
As you can see from this example, it is very important to regularly check your backup data and your ability to recover from it.
If you'd like to learn more about backup and disaster recovery, how they differ, and how we can help you, please contact us today.
