Backups Reorganization pt. 1: Introduction

Over the next couple of weeks, I plan to blog with a series of articles describing a project at work to reorganize the backups for a client. The client runs a number of Debian and Fedora Core servers which are backed up remotely. The previous sysadmin. had done a really good job of planning it out and provided some decent documentation. The problem is that the solution doesn't scale and is just complicated enough that another sysadmin. (such as me) has to spend a lot of time getting up to speed.

My goals in reorganizing their backups are as follows:

1. Ensure that the data being backed up is actually restorable. Perform tests to confirm. For example, one cannot simply backup database files and expect the data to be restorable. Usually, with databases, one has to dump the data into a file and then backup the file. This will be true of other applications as well such as souce control management systems.
   
2. Simplify the backup process where possible. For example, dozens of scripts on multiple machines need to be invoked on a daily basis to perform backups. That could all be condensed into one machine and one or two scripts.
   
3. Document both the backup and restore procedure for the client. Plan for disaster recovery of the data.
   
4. Plan for future requirements, including backing up Windows machines.
5. Give the client a real confidence that their data is being adequately safeguarded. Again, this comes from periodically testing restores.
   
6. Centralize the backup job control onto one machine (currently, they are duplicated across four).
7. Provide reliable alerting of both failures and successes of backup jobs via configurable methods including syslog, email, and even rss.