Библиотека сайта rus-linux.net
The simple backup method outlined in the previous section is often quite adequate for personal use or small sites. For more heavy duty use, multilevel backups are more appropriate.
The simple method has two backup levels: full and incremental backups. This can be generalised to any number of levels. A full backup would be level 0, and the different levels of incremental backups levels 1, 2, 3, etc. At each incremental backup level you back up everything that has changed since the previous backup at the same or a previous level.
The purpose for doing this is that it allows a longer backup history cheaply. In the example in the previous section, the backup history went back to the previous full backup. This could be extended by having more tapes, but only a week per new tape, which might be too expensive. A longer backup history is useful, since deleted or corrupted files are often not noticed for a long time. Even a version of a file that is not very up to date is better than no file at all.
With multiple levels the backup history can be extended more cheaply. For example, if we buy ten tapes, we could use tapes 1 and 2 for monthly backups (first Friday each month), tapes 3 to 6 for weekly backups (other Fridays; note that there can be five Fridays in one month, so we need four more tapes), and tapes 7 to 10 for daily backups (Monday to Thursday). With only four more tapes, we've been able to extend the backup history from two weeks (after all daily tapes have been used) to two months. It is true that we can't restore every version of each file during those two months, but what we can restore is often good enough.
Figure 12-1 shows which backup level is used each day, and which backups can be restored from at the end of the month.
Backup levels can also be used to keep filesystem restoration time to a minimum. If you have many incremental backups with monotonously growing level numbers, you need to restore all of them if you need to rebuild the whole filesystem. Instead you can use level numbers that aren't monotonous, and keep down the number of backups to restore.
To minimise the number of tapes needed to restore, you could use a smaller level for each incremental tape. However, then the time to make the backups increases (each backup copies everything since the previous full backup). A better scheme is suggested by the dump manual page and described by the table XX (efficient-backup-levels). Use the following succession of backup levels: 3, 2, 5, 4, 7, 6, 9, 8, 9, etc. This keeps both the backup and restore times low. The most you have to backup is two day's worth of work. The number of tapes for a restore depends on how long you keep between full backups, but it is less than in the simple schemes.
Table 12-1. Efficient backup scheme using many backup levels
|Tape||Level||Backup (days)||Restore tapes|
|4||5||1||1, 2, 4|
|5||4||2||1, 2, 5|
|6||7||1||1, 2, 5, 6|
|7||6||2||1, 2, 5, 7|
|8||9||1||1, 2, 5, 7, 8|
|9||8||2||1, 2, 5, 7, 9|
|10||9||1||1, 2, 5, 7, 9, 10|
|11||9||1||1, 2, 5, 7, 9, 10, 11|
|...||9||1||1, 2, 5, 7, 9, 10, 11, ...|
A fancy scheme can reduce the amount of labour needed, but it does mean there are more things to keep track of. You must decide if it is worth it.
dump has built-in support for backup levels. For tar and cpio it must be implemented with shell scripts.