Planning a Backup Schedule

Let us see what this means in practice. On Solaris 2.x which is System V−like, all tape device files reside in the subdirectory devrmt. ls −C devrmt 0 0bn 0cb 0cn 0hb 0hn 0lb 0ln 0mb 0mn 0u 0ubn 0b 0c 0cbn 0h 0hbn 0l 0lbn 0m 0mbn 0n 0ub 0un This is an example from the SunSparc20 workstation with a single 4mm DDS2 tape drive. Each device file is identified by: devrmt unit number [density][BSD behavior][norewind] where density Is identified by the letters l, m, h, u, and c for low, medium, high, ultra, and compressed, respectively BSD behavior By the letter b norewind By the letter n Tape device files can be identified in a similar way on other systems.

12.3 Backing Up a UNIX Filesystem

Filesystem−related UNIX backuprestore commands enable the handling of large, complex volume data archiving in a relatively simple way. This is especially important if a system crash occurs, when fast filesystem recovery primarily of the root filesystem is extremely significant. Besides the commands themselves, some UNIX platforms provide other backuprestore tools mostly shell script based, which makes it easy to understand what they are doing and how for the same purpose. We will discuss many of them. However, before starting with the commandstools, a few words about planning the process of a successful data archival.

12.3.1 Planning a Backup Schedule

Performing regular backup is essential for system data security. It is a good idea to assume that the next time you use the system, all system disks will have crashed and the only available files to restore are those you had backed up previously. Keeping such a catastrophe in mind will make it obvious what needs to be backed up and how often. Backups are convenient for accidentally deleted files, but they are also essential in the event of serious hardware failures or other disasters; all hardware has a finite lifetime, and failures are always possible. Therefore, planning is an important part of the backup process. In planning a backup schedule, several factors need to be taken into account: What files are critical to the users on this system? • Where are these files located? Are they isolated in a single filesystem, for example? • How often do these files change? • How quickly would they need to be restored in the event of damage or loss? • How often are the relevant filesystems available for backup? Ideally, backups should not be performed on mounted filesystems. • 280 For example, if the system supports a large ongoing development project, it can be assumed that the files change frequently and should be backed up often. On the other hand, if the only volatile file on the system is a large database, its filesystem might need to be backed up more often than the other filesystems on the system. In performing backups, a system administrator invests time in the present to prevent future losses. The time required for any backup schedule must be weighed against the potential losses if the files are needed but are not available. Strictly speaking, a filesystem should be dismounted before a backup is performed except for the root filesystem. This means that the system should be placed in singleuser mode. However, this recommendation is rarely followed; in practice, backups are almost always performed on mounted filesystems. Consequently, any file modified while the backup is in progress may not be backed up correctly. The simplest backup scheme is to copy a whole disk to a tape. This type of full backup is time consuming, and restoring a single filesystem from a large set of tapes is inconvenient; if the files do not change frequently, it can be a waste of time. On the other hand, if the files are changing very rapidly, then even daily full backups might be reasonable. In any case, a periodic full backup is recommended once per month, biweekly, or once per week. Another approach is incremental backup; in an incremental backup, a system copies only those files that have been changed since the previous backup. The concept of a backup level to distinguish different backup types is often used; each backup type has an assigned level number. By definition: Level 0 Full backup Level 1 Backup of all files that have changed since the last full backup Level 2 Backup of all files that have changed since the last level 1 backup Level 3 Backup of all files that have changed since the last level 2 backup Level 4 Backup of all files that have changed since the last level 3 backup and so on. This approach and the concept of numeric backup levels are generally valid for any UNIX system, but they are only fully supported by BSD−style backup commands. A typical backup strategy usually includes a full backup at the beginning of the determined backup period, and then several incremental backups during that period. As examples, two schemes are presented: The Backup Period One Week Monday Level 1 backup incremental backup to the last full backup Tuesday Level 1 backup incremental backup to the last full backup Wednesday Level 1 backup incremental backup to the last full backup Thursday Level 1 backup incremental backup to the last full backup Friday Level 0 backup full backup The Backup Period One Month First Monday of each month Level 0 backup full backup 281 Tuesday Level 2 backup daily incremental to the previous level 1 Wednesday Level 2 backup daily incremental to the previous level 1 Thursday Level 2 backup daily incremental to the previous level 1 Friday Level 2 backup daily incremental to the previous level 1 The main criterion for planning a backup schedule is how the system is used. The most used portions of the filesystem may need to be backed up more often than the other parts; for example, the root filesystem with standard UNIX programs and files that rarely change does not require frequent backup. Some parts of the system, like the tmp directory, need never be backed up. Sometimes, additional filesystems can be created; they might need to be backed up often, or very rarely, or never at all. The full backup should be performed whenever significant changes are made to the system, regardless of the current backup schedule. This might be one of the few times that the root filesystem gets backed up. The worst part of doing backups is sitting around waiting for them to finish; this will often feel like wasted time. Unattended backups solve this problem for some sites. If the backup will fit on a single tape, and new technologies enable it, then the tape can be put in the drive and the backup performed during the night. In the morning the operator simply has to pick up and label the tape. However, unattended backups can be a security risk; nontrusted users with physical access to the tape drive may cause a problem.

12.4 Backup and Dump Commands