Linux Unleashed, Third Edition:Backups





-->















Previous
Table of Contents
Next




How often should you backup? The usual rule is backup whenever you can’t afford to lose information. For many people, this is on a daily basis. Imagine that you have been writing a document or program, and you lose all the work since the last backup: how long will it take to rewrite (if at all possible)? If the rewriting of the loss is more trouble than the time required to perform a backup, then make a backup! For the rest of this section, we’ll use tapes as the backup medium, but you can substitute any other device that you want.

So how can you effectively schedule backups for your system, assuming you want to save your contents regularly? If we assume your system has several users (friends calling in by modem or family members who use it) and a reasonable volume of changes (email, newsgroups, word processing files, databases, or applications you are writing, for example), then you may want to consider daily backups. The most common backup schedule for a small, medium-volume system requires between 10 and 14 tapes, depending on whether backups are performed on weekends.
All backup tapes should be labeled with names that reflect their use. For example, label your tapes “Daily 1,” “Daily 2,” and so on, up to the total number of daily use tapes, such as “Daily 10.” These daily use tapes are cycled through, one after another, with the cycle restarted after all the tapes have been used (so that “Daily 1” follows after “Daily 10”). With this many tapes, you have a two week supply of backups (ignoring weekend backups, in this case), enabling you to recover anything going back two weeks. If you have more tapes available, use them to extend the backup cycle. This same method is used by large corporations and organizations because it provides the best balance of speed, backup security, recoverability, and media costs.
The backups can be either full or partial, depending on your needs. A good practice is to make one full backup for every four or five partial, so that you make a full backup of your entire file system on Mondays, for example, but only back up the /usr directories on the other days of the week. You should make an exception to this process if you make changes to the Linux configuration, so that you have the changes captured with a full backup. You can keep track of the backups using a backup log, which we’ll look at in a moment.
An expansion of this daily backup scheme that many administrators (including the author) prefer is the daily and weekly backup cycle. This breaks up the number of tapes into daily and weekly use. For example, if you have fourteen tapes, use ten for a daily cycle as already mentioned. These tapes can still be called “Daily 1” through “Daily 10.” The other four tapes are used in a biweekly cycle and have names like “Week 1,” “Week 2,” and so on to “Week 4.”
Using this backup system, you perform your daily backups as already mentioned, but when you get to the end of the daily cycle, you use the next weekly tape. Then you cycle through the daily tapes again, followed by the next weekly tape. (Your backup cycle is “Daily 1” through “Daily 10,” “Week 1,” “Daily 1” through “Daily 10,” “Week 2,” and so on.)
This backup cycle has one major advantage over a simple daily cycle. When the entire cycle is underway, there will be ten daily backups that cover a two week period. There are also the biweekly tapes, which extend back over four complete daily cycles or eight weeks. Recovery of a file or group of files can then be performed from the file system as it was two months ago, instead of just two weeks. This gives you a lot more flexibility in recovering information that was not noticed as missing or corrupt right away. If even more tapes are available, either the daily or biweekly cycle can be extended or monthly backups can be added.
Backup Logs
Many system administrators begin their careers by making regular backups, as they should. However, when they get to the point where they have to restore a file from a backup tape, they have no idea which tapes include the file or which tapes were used on what days. Some system administrators overcome this problem by placing a piece of paper or sticky note on each tape with the date and contents on it. This means you have to flip through the tapes to find the one you want, though, which can be awkward when there are lots of tapes. For this reason, a backup log should always be kept. (This is a good idea for all backups, Linux, DOS, and other operating systems.)

Whenever a backup is made, the backup log should be updated. A backup log doesn’t have to be anything complex or elaborate. You can use the back of a notebook with a couple of vertical columns drawn in, use a form on the computer itself (which you should print out regularly, of course), or keep a loose-leaf binder with a few printed forms in it. A typical backup log needs the following information:

•  the date of the backup
•  the name of the backup tape (Daily 1, for example)
•  the file system being backed up
•  whether a full or partial backup was performed, and if partial, which directories were backed up

That’s only four easy bits of information to record and can be done in a few seconds. For larger systems, a few other pieces of information can be added to complete a full backup record:


•  who made the backup
•  whether the backup was automatic (cron) or manual
•  storage location of the tape

The dates of the backup help you keep track of when the last backup was performed and also act as an index for file recovery. If one of your system users knows they deleted a file by accident a week ago, the proper backup tape for the file restore can be determined from the backup log dates.

The backup log should be kept near the system for convenience, although some administrators prefer to keep the log in the same location as the backup media storage. Some system administrators keep a duplicate copy of the backup log in another site, just in case of catastrophic problems.



Previous
Table of Contents
Next