This article can also be found in the Premium Editorial Download "Storage magazine: Salaries rise, but storage jobs get tougher."
Download it now to read this article plus other related content.
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 Web, 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.
This was first published in November 2008