Backing Up Filesystems
10. You are first given another chance to stop:
Last chance before scribbling on /dev/name.
If you wish to continue, press RETURN.
11. The restoration process may take some time. When the restore phase of the operation is complete, you see:
End of backup
The restore of /name has been successful.
The filesystem will be checked to insure integrity.
6-24
12.
Backing Up Filesystems
Next, sysadmin runs a check on the filesystem using fsck(ADM).
You see a series of messages like this:
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Free List
***** FILE SYSTEM WAS MODIFIED *****
When the filesystem check is complete, you see:
You must remount /dev/name when ready to use the filesystem.
13. Now that the restore of your level 0 volumes is complete, you are returned to the Filesystem Maintenance Menu. Repeat steps 6-12 until each of your higher level backups (1,8 and 9) have been restored that were done between the last level 0 and the date when your filesystem was damaged. Be sure and restore them in the order they were done, or you will overwrite recent versions of files with older ones.
Your filesystem is now completely restored. You need to mount the file system before you can use it. To mount it, enter the following com-mand' substituting name for the name of your filesystem:
mount /dev/name /name
6.9 Editing /etc/default/filesys and /etc/default/archive
The files letcldefaultlfilesys and letcldefaultlarchive are used by sysad-min to create the filesystem and archive device menus. Even though each menu provides the option "Other" so that you can use filesystems and devices not described, you should keep these default files up to date as your system changes. These files are also used by other programs, and should be maintained as specified for these programs.
XENIX System Administrator's Guide
/ete/default/arehive
The /ete/ default/ archive file contains a complete set of devices supported by "XENIX. Each device, filesystem or drive, in these files is represented by a one line entry which consists of "name=value" pairs, separated by spaces or tabs. For example, the following is a possible entry in /ete/ default/ archive:
cdev=/dev/rfd048ds9 desc="Floppy Drive 0 (48dsdd)" \ blocking=18 size=360 format="format -f /dev/rfd048ds9"
The value part of "name=value" pairs "desc="Floppy Drive 0 (48dsdd)'", and "format="format -f /dev/rfd048ds9'''' contain spaces, therefore they must be surrounded by quotes in order to be interpreted correctly.
If your system does not use certain drives included in jete/default/archive, or if you add an entry to either file, and then later decide that you don't need it any longer, rather than deleting the entry, you can place a pound sign (#) at the beginning of the first line for that device, and it will be treated as a comment and ignored. Later, if you need the entry again, you can delete the #.
Entries commented out will not appear in the list of media devices displayed in the "Restore backup file(s)" option of the Filesystem Maintenance Menu.
/ete/ default/ filesys
The minimum necessary information about a filesystem is:
• A character device name, (cdev=), or a block device name, (bdev=).
• You may include a description, (desc=), which appears in the Filesystem Maintenance Menu.
• The mount directory, (mountdir=), which is also used by the mnt(C) utility, in addition to sysadmin. The name remount, in the example below is used exclusively by fete/reo
6-26
bdev=/dev/root cdev=/dev/rroot mountdir=/ \ desc="The Root Filesystem" rcmount=no mount=no bdev=/dev/u cdev=/dev/ru mountdir=/u rcrnount=yes fsckflags=-y desc="The User Filesystem"
Backing Up Filesystems
6.10 An Explanation of Backup Levels
The most straightforward and dependable way to ensure the safety of data is to back up everything on a filesystem at one time. However, filesys-terns tend to be quite large (from 10 to 300 MB), and may take hours to backup. The concept of backup levels (or incremental backups) addresses this problem. The general idea of an incremental backup is to back up only those files that have changed since a previous backup. This can significantly reduce the size and duration of the backup. Consider the fol-lowing scheme: full (monthly) backup, the last weekly backup, and any daily backups that happened just prior to the accident. Thus it is always possible to recon-struct a filesystem from a series of backups.
While this is a simple method to understand, the implementation using incremental backup levels is not.
6.10.1 Principles of Incremental Backup Levels
To make the business of backing up files more efficient, XENIX uses a progressive series of levels, each of which is based on the last occurrence of a lower level backup. The XENIX backup facility provides up to ten different levels of backups, giving the system administrator tremendous flexibility in organizing backups.
Level Files Saved
o
all files on the filesystem1 files changed since last level 0 backup 2 files changed since last level 1 backup 3 files changed since last level 2 backup 9 files changed since last level 8 backup
The full ten levels would be used to accommodate computers with mas-sive filesystems; average systems will use only a few levels. The levels
XENIX System Administrator's Guide
serve to subdivide a backup into manageable units. It is important to real-ize that each backup level creates backups based on the previous (next lowest) level backup. This means that the order of the backups is not significant, but the level number is.
For example, let's assume that the following backups were done for a week:
Day Level Files Backed Up Mon 0 All files on filesystem
The 5 All files changed since Monday Wed 2 All files changed since Monday Thu 7 All files changed since Tuesday Fri 5 All files changed since Wednesday
This example is illogical, but serves to demonstrate how the levels work.
Remember that each of the backups saves the files changed since the next lower level backup, and that level 0 is the lowest. Therefore, the level 5 on Friday backs up all files changed since the next lowest number, level 2, on Wednesday. The level 5 on Monday saves only those files that have changed since the day before, since the only previous lower level backup is a O. If all the backup levels except Monday were level 5, each would still backup all files that changed since the level 0 on Monday.
6.10.2 How the Default Schedule Works
The default schedule file provided with your distribution uses only four levels, and is optimized for use on systems under moderate use (7-10 ter-minals, 8-10 users):
# 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10
# Filesystem M T W T F M T W T F M T W T F M T W T F /dev/rroot 0 x 9 x 9 8 x 9 x 9 1 x 9 x 9 8 x 9 x 9 /dev/ru 9 0 9 9 9 9 8 9 9 9 9 1 9 9 9 9 8 9 9 9
Figure 6-6: The Default Schedule
6-28
Backing Up Filesystems
The lu Fileystem
Filesystem /dev/ru is a heavily-used resource. Some level of backup is performed every day. This scheme is designed to minimize resources while maximizing safety; if one or more of the backups for that week is lost or goes bad, there is sufficient redundancy to minimize any loss of data.
According to the default schedule, a full (level 0) backup of /dev/ru occurs at the beginning of the month. (Because a level 0 is done on the root filesystem on Monday, the level 0 for /u is done on Tuesday.) Wednesday, a level 9 backup saves just those files on /dev/ru which have changed since the level 0 backup. By the end of the week far fewer floppies or tapes are used than the number needed for full backups each day. Time is substantially reduced as well. If it is necessary to restore the filesystem to the last recorded state, you would restore the last level 0 backup, followed by each of the lower-level backups that have been done since.
Note that each Tuesday, a lower level backup (0, 1 or 8) occurs that saves everything since the beginning of the month and causes each of the level 9 that follow it to be based on that week. This way the level 9 backups don't become too large and redundant.
The root Filesystem
The root filesystem contains the operating system and other system files.
It changes less frequently, so it is not backed up every day. Each Mon-day, a lower level backup is done, and level 9 backups are done twice per week. Just as with the /u filesystem, the level 9 backups are restricted to cover only those files that have changed during that week.
6.10.3 How Backups are Used to Restore a Filesystem
Now, let's assume you have a hardware failure that ruins the information on the hard disk. Assume it happens on the last Thursday of the month, just before the backup was to be done that evening. You fix the hardware problem and reinstall your system, but how do you restore your backups?
Restore the last occurrence of each backup level, in ascending order:
• level 0 (done on the first Tuesday of the month)
• level 1 (done on the third Tuesday)
XENIX System Administrator's Guide
• level 8 (done on the fourth Tuesday)
• level 9 (done on Wednesday evening)
You wouldn't need to restore the level 8 that was done on the second Tuesday, because the level 1 that followed it covered the same files. The only infonnation that is missing is what was changed during the day on Thursday, just before the crash. This is the primary reason for backups;
recovery should be straightforward and with a minimum of loss.
6-30