You’ve come back after a long weekend off to find that your servers have crashed. Now no one is able to 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, right? You just stroll down to your CIO’s office and have him get to work on accessing the backup data.
Here’s the problem, though: backed 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 get yourself prepared for a situation just 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 back up is not always the same as data recovery. From a backup perspective, the goal is not to recover from the backup, but to backup 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 being 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 you have all the right people, tools and processes… but no one has actually checked that the backup was working properly 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, and so they didn’t know the chaos that was occurring. The program for backups had recently been updated, and although a correct installation message had been sent, there was a fatal flaw in the system. 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 that was being sent nightly was garbled and was utterly unusable in recovering the systems.
As you can see from this example, a regular checkup on your backup data and the ability to recover from it is very important.
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.