|
- Missing data
the second big problem in today's backup systems is the data that backups miss. This isn't data you tried to back up and failed to do; it's the data the backup system never attempted to back up because it simply wasn't told to. Missed backups don't generate error messages, but they can (at some point) cause an RPE--a resume processing event. If this problem isn't addressed, you can be sure that someday someone will ask you to restore something that hasn't been backed up.
Consider the following two real-life stories: One day a backup administrator was asked to restore a set of files on server hpdbsvk. According to the firm's naming convention, this meant HP-UX database server "k." The backup administrator also knew that because servers were named in alphabetical order, there were also database servers hpdbsva through hpdbsvj, and he was only backing up servers hpdbsva through hpdbsvj. Immediately, he knew he had some work to do, but soon afterward someone walked into his office and asked him to restore a database on hpdbsvk. While the data was never restored, the administrator didn't lose his job and didn't even get in trouble. How is that possible?
Real-life story No. 2: One day an administrator was asked to restore some code sitting in /tmp on an HP-UX system. The file system had disappeared upon reboot because it was a RAM file system. The customer requesting the data was furious when he found out that the backup system didn't back up /tmp. Again, the administrator didn't lose their job or get in trouble. Why not?
In both cases, the reason the backup administrator didn't lose their job was the same: documentation. Back in the days before the We...
To continue reading for free, register below or login
To read more you must become a member of SearchStorage.com
b, the backup system in question used a paper-based request form users had to fill out if they wanted a system backed up. The form included a line that read "Do not consider this request accepted until you receive a copy of it in your in-box signed by someone on the backup team."
In the case of the customer who requested a restore from hpdbsvk and started fuming because it wasn't being backed up, the backup administrator asked to see the form with his signature on it. The customer didn't have the form, so the issue became what I like to call a "YP not MP"--Your Problem, not My Problem--as far as the backup administrator was concerned. As for the /tmp situation, it was excluded from backups, and the exclusion had been approved by upper management and well-advertised. (After all, the "T" in tmp stands for temporary, so why would you back up temporary things?)
Applying the paper backup request system to today's Web-based world is simple. Create a backup system request Web page that notifies the user who requested the backup that the backup is being performed. If you're using a data protection management tool, the user who requests the backup can even be notified every time the backup succeeds or fails. How's that for customer service? The Web page should also list standard backup configurations, including things like what gets backed up (or not backed up) by default.
It's also important to mention how important it is to use your backup software's ability to automatically discover and back up all file systems or databases on a given machine. If your backup software has this feature, use it; don't attempt to manually list all file systems. You're just asking for trouble and an RPE when you discover that you forgot to add the F: drive on a particular server. If your backup app doesn't have this feature, get a new one.
|
 |
|
