Having a plan for data backup as part of your disaster recovery strategy is the right thing to do, but it’s not the end of the story. Too many organisations have planned their data backups, only to find in situations of emergency that the backups were unavailable or insufficient. The reasons can be varied, but the risk remains: data that are not stored safely, correctly or completely may be no better than data that are not stored at all.
What can go wrong? Here are some examples:
– The data backup process never happened: an automated process was never triggered; a manual intervention was neglected; or a network link to a backup machine failed.
– The backup is lost because it is not labelled and archived in a way that makes it possible to find it (quickly enough) again.
– The information is stored incorrectly, because checksum errors are not detected and reported, and only a corrupted version of the data remains
– It’s stored incompletely: the data and the files stored are not sufficient to be able to restart a more complex system such as a database server or a cluster of servers.
The answer? Validation of your plan by putting it into action and checking it gives you the right results. Of course, you also need to do this in a way that doesn’t negatively impact your organisation, or at least no more than an acceptable minimum. To use the analogy of a fire drill, you have to make sure that in an emergency the procedures will be followed for the safety of all concerned, but you don’t want to have to start a fire just so you can check. For data backup, simulations outside of working hours and/or backup restores on duplicate hardware to see if they run correctly afterwards may be the best way to verify that your Disaster Recovery Plan truly corresponds to reality, without unduly impacting daily operations.