Supporting systems
Another critical factor to a backup strategy is the systems — both automated and process based — that you have in place to know when the backup is failing. On the surface, this problem appears simple — have the backup software send you a notice when there is a failure. Certainly this is better than nothing, but what happens if none components of the backup software are running — including the one responsible for sending e-mail? You won't get any e-mail telling you there is a problem because the portion that does that isn't working either. I've seen this happen to more than a few clients.
You need to have systems that generate messages on success as well as failures. While you may not need to read through each line of a backup log if the software indicates the backup was successful, you do want some kind of positive confirmation that the backup did indeed complete. Fifteen years ago, this meant printing the backup log and putting it into a book each day. It became routine for the operations staff to put this into their book — when it was missing it was noticed. Today, we have e-mail notifications which means there isn't a log book, but if directed at a specific person (or group) the notifications can become just as effective. If they have to move the logs to a folder each day it is a repetitive process that gets noticed when it doesn't happen.
On that note, it's good to have someone responsible for verifying that the backups run and a backup person who's responsible when that person is gone.
Of course, even better than notification on success as well as failure is a checklist of daily tasks which includes verifying the backups ran. However, in most mid-sized IT shops these daily task lists never seem to get created or used. Managing multiple backups
In today's environment, having a single backup solution is often wishful thinking. Products like Windows SharePoint Services and the limitations of the backup agents, often mean that you're backing up with multiple different programs, sometimes from the individual backup programs to disk and then from disk to tape.
One of the most frequently overlooked issues is verifying that these ancillary backups are running correctly. They should be subject to the same monitoring requirements that the rest of the backup strategy is. However, often because these are cobbled together from scripts and built in tools they often lack any form of notification. This is one of the greatest potentials for problems since it's often difficult to spot when the backup hasn't run successfully. Remembering to address notification in each one of your backups is a key component to a solid backup strategy.
