Backups are one of those things in IT that most people know are very important, but not everyone treats them that way.

More times than I care to remember I have entered a disaster recovery situation for an email system in which the recovery options are limited because either:

• The backups hadn’t been running and no one realised
• The backups hadn’t been running and people knew but didn’t do anything about it
• The backups had been running but had never been tested

I can tell you that the worst possible time to put your backups to the test is during a real disaster situation.

Take a look at your current email backups and ask yourself these questions.

Are the Backups Running?

Even if you know that the backups have been set up and scheduled you still need to know whether they are actually running.  It is not a nice feeling when you open up the backup history of a server and see that every backup job has actually failed.

Good backup software includes alerting options for the outcome of a job.  Set these options to send email reports to the people responsible for checking the backups.  It is also advisable to have a weekly or monthly summary report sent to other people such as managers so that they can verify that the backups are being done.

Are the Backups Successful?

Not only do you need to know whether the jobs are running, you also need to know what the outcome of the backup job was.  Obviously the goal is a successful backup job, but in the real world backups will fail from time to time.

Have a response and escalation process in place for any failed backup jobs so that they are investigated immediately that day.  If the problem can’t be resolved, or a consecutive day’s backup also fails, escalate the problem to a senior administrator or seek vendor support.  Some environments can tolerate a single failed backup but the risks grow exponentially with every subsequent failure.

Are the Backups Protecting the Data You Think They Are?

It might not occur to everyone to check not only the successful outcome of the backup job, but also verify that the job is backing up everything you intend it to.  No backup software will report that it failed to backup something it isn’t configured to backup in the first place.This sort of problem easily arises in environments with poor change control.  When a new server is introduced, or a significant change is made to a server, it is easy to forget to reconfigure the backups to include the new data locations that have been created.

Have a change control process in place that includes a mandatory step to notify the backup administrators of any environment changes so that they can adjust the relevant backup jobs accordingly.

Can You Restore the Data When You Need To?

One of the toughest situations you can face is an environment where all of the backups have been running successfully and backing up the right data, but you can’t actually restore it.

I’ve spent a lot of hours testing tape after tape in multiple different tape drives for a client to try and find one that can be used for a recovery.  This can happen to any organization due to faulty backup media, poor storage methods, or even lack of speedy access to offsite archives.

Test your recovery plans at regular intervals to verify that you can meet the required timeframes for restoration, and that your backups are still usable.  It pays to take an extra step of testing important, long term archives such as yearly backups before sending them offsite, to be absolutely sure that you aren’t sending a useless backup off to storage.

Give Backups the Priority They Deserve

Ask yourself those four questions above and if you find you cannot answer yes to all of them then it is time to give your backups the attention and priority that they deserve and address the problems now before they become a real disaster.