Why You Back Up File Systems

Backing up files means making copies of them, usually on removable media, as a safeguard in case the originals get lost or damaged. Backup tapes are convenient for restoring accidentally deleted files, but they are essential in case of serious hardware failures or other disasters.

Backing up files is one of the most crucial system administration functions. You must plan and carry out a procedure for regularly scheduled backups of your file systems for three major reasons:

• To ensure file system integrity against a possible system crash
• To ensure user files against accidental deletion
• To act as an important safeguard before reinstalling or upgrading a system

When you back up file systems as scheduled, you have the assurance that you can restore files to a reasonably recent state. In addition, you may want to back up file systems to transport them from one system to another or to archive them, saving files on a transportable media, so that you can remove or alter the files that remain on the system.

When you plan a backup schedule, you need to consider:

• Which command to use to back up the file systems
• Which file systems to back up
• What media to use
• What backup schedule to use

Understanding the ufsdump Command

You usually use the ufsdump command to do periodic backups in which you save all the files recently modified on a specified file system. This section and Chapter 7, "Backing Up Files and File Systems," describe the ufsdump command. See Chapter 4, "Copying UFS Files and File Systems," for a description of dd, tar, cpio, and other commands that can be used to copy files.

Networker for Solaris also provides backup and restore capabilities. See the Networker for Solaris User's Guide for information about backing up client machines. See the Networker for Solaris Administrator's Guide for information about configuring Networker for Solaris and backing up servers.

Advantages of ufsdump

The ufsdump command is designed to back up entire file systems. You can also use it to back up individual files.

The ufsdump command has these advantages over other methods for performing backups:

• It provides incremental backups. You can specify different backup (dump) levels, making it possible to back up only those files that were changed since a previous backup at a lower level.
• It works quickly. The command knows the structure of the UFS file system type and works directly through the raw device file.

• It supports multiple volumes. You can back up very large file systems by writing the backup to multiple volumes (usually tapes).
• It supports remote drives. The media drive can be on any system in the network to which the user has access. High-capacity tape drives can be used to back up many systems.

Disadvantages of ufsdump

ufsdump cannot automatically calculate the number of tapes or diskettes needed for a backup. You can, however, use the S option to determine the amount of space that is needed to perform the dump (without actually doing it) and display the estimated number of bytes it will take.

The ufsdump command does not have built-in error-checking to minimize problems if you are backing up an active file system.

How ufsdump Works

Basic Operation

The ufsdump command makes two passes when backing up a file system. On the first pass, it scans the raw device file for the file system and builds a table of directories and files in memory. It then writes the table to the backup media. In the second pass, ufsdump goes through the inodes in numerical order, reading the file contents and writing it to the media.

Determining Device Characteristics

The ufsdump command needs to know only an appropriate block size and how to detect the end-of-media.

Detecting the End of Media

ufsdump writes a sequence of fixed-size records. When ufsdump receives notification that a record was only partially written, it assumes that it has reached the physical end of the media. This method works for most devices. If a device is not able to notify ufsdump that only a partial record has been

written, a media error occurs as ufsdump tries to write. DAT devices and 8mm tape devices detect end-of-media. Cartridge tape devices and 1/2 inch tape devices do not detect end-of-media.

Copying Data

The ufsdump command copies data only from the raw disk slice. If the file system is still active, anything in memory buffers is probably not copied. The backup done by ufsdump does not copy free blocks, nor does it make an image of the disk slice. If symbolic links point to files on other slices, the link itself is copied.

The Role of /etc/dumpdates

The ufsdump command, when used with the u option, maintains and updates a file named /etc/dumpdates. Each line in /etc/dumpdates shows the file system backed up, the level of the last backup, and the day, date, and time of the backup. Here is a typical /etc/dumpdates file from a file server:

/dev/rdsk/c0t1d0s0 0 Fri Nov 6 07:54:38 1993 /dev/rdsk/c0t1d0s5 0 Sat Oct 10 07:53:44 1993 /dev/rdsk/c0t1d0s7 0 Sat Oct 10 07:56:57 1993 /dev/rdsk/c0t1d0s6 0 Sat May 23 08:02:34 1993 /dev/rdsk/c0t1d0s0 5 Fri Nov 6 07:55:20 1993 /dev/rdsk/c0t1d0s7 5 Fri Nov 6 07:58:08 1993 /dev/rdsk/c0t1d0s6 5 Fri May 29 09:03:07 1993 /dev/rdsk/c0t1d0s5 9 Thu Nov 5 07:15:51 1993 /dev/rdsk/c0t1d0s4 9 Thu Nov 5 07:18:04 1993 /dev/rdsk/c0t1d0s6 9 Thu Jun 4 09:21:02 1993

When you do an incremental backup, the ufsdump command consults /etc/dumpdates to find the date of the most recent backup of the next lower level. Then it copies to the media all files that were updated since the date of that lower-level backup. After the backup is complete, a new information line, describing the backup you just completed, replaces the information line for the previous backup at that level. On the date that you do a level 0 backup, /etc/dumpdates contains one information line for each backed up file system at each level.

Use the /etc/dumpdates file to verify that backups are being done. This verification is particularly important if you are having equipment problems. If a backup cannot be completed because of equipment failure, the backup is not recorded in the /etc/dumpdates file.

If you need to restore an entire disk, check the /etc/dumpdates file for a list of the most recent dates and levels of backups so that you can determine which tapes you need to restore the entire file system.

---

Note - /etc/dumpdates is a text file that can be edited, but edit it only at your own risk. If you make changes to the file that do not match your archive tapes, you may not be able to find the tapes (or files) you need.

---

Choosing Which File Systems to Back Up

Consider these factors as an important part of planning your backup strategy:

• What files are critical to users on this system?
• Where are the files located? Are they in a single file system?
• How often do these files change?
• How quickly would you need to restore these files in the event of damage or loss?
• How often can the relevant file systems be unmounted so that they are available for backup?

The next sections describe some additional factors to consider in planning your backup strategy.

You need to back up file systems that change frequently. The file systems that need to be backed up for a given system depend on the type of system.

File Systems to Back Up on a Standalone System

By default, the installation procedure creates at least the file systems shown in Table 6-1.

Table 6-1

Directory	Partition
/	0
/usr	6

The / file system on a standalone system contains /kernel/unix and other important files. It also contains the /var directory, in which frequently modified files, such as mail and accounting, are kept. Therefore, you should back up the / file system at regular intervals.

Back up the /usr file system occasionally, especially if you install new software or add new commands.

/export/home contains the directories and subdirectories of all the users on the standalone system. Back up /export/home more often than / or /usr, perhaps as often as once a day, depending on your site's requirements.

During installation, you may have assigned file systems such as /export or /var to other available slices.

Be aware of the slices where file systems are located. Use the df command or look at the /etc/vfstab file to find out on which slice a file system is located.

File Systems to Back Up on a Server

On a file server, you have to back up not only the file systems that contain the operating system itself, but the file systems for the individual users as well.

The default file systems on a server are as shown in Table 6-2.

Table 6-2

Directory	Slice
/	0
/usr	6
/export/home	7
/export/swap	4
/export	3

Periodically, you need to back up the file systems containing the kernel, major commands, and executables (/, /usr, and /export). Back up these file systems at intervals from once a day to once a month, depending on your site's requirements. For example, if you frequently add and remove clients and equipment on the network, you have to change important files in root, including the kernel configuration file. In this case, you might want to back up root more frequently than if your site seldom changes the network configuration. Furthermore, your site may keep users' mail in the directory /var/mail on a mail server, which client machines then mount. If that is the case, you might want to back up root daily to preserve mail. /usr contents are fairly static and only need to be backed up from once a week to once a month.

The root directory of diskless clients is kept in the /export file system. Because the information it contains is similar to the server's root directory in slice 0, it does not change frequently. If your site sends mail to clients' root directories, you should back up /export more frequently.

You need not back up /export/swap.

The file system you need to back up the most frequently is /export/home. Because /export/home contains the home directories and subdirectories of all the users on the system, its files are very volatile. Depending on your site, you should back up /export/home at least once a week, if not daily.

Choosing Which Media to Use

You typically back up Solaris systems using 1/2-inch reel tape, 1/4-inch streaming cartridge tape, 8-mm cartridge tapes, or 4-mm cartridge tapes (DAT). You can perform backups using diskettes, but this is time-consuming and cumbersome.

The media you choose depends on the availability of the equipment that supports it and of the media (usually tape) that you use to store the files. Although you must do the backup from a local system, you can write the files to a remote device. Table 6-3 shows typical media used for backing up file systems and shows the length (or storage capacity) for each. You can use the storage capacity as input for the -s size option to the ufsdump command.

Table 6-3

Media	Capacity	Tape Length
1/2-inch tape	40-45 Mbytes	2300 feet
60-Mbyte 1/4-inch cartridge	60 Mbytes	425 feet
150-Mbyte 1/4-inch cartridge	150 Mbytes	700 feet
2.3-Gbyte 8-mm	2.3 Gbytes	6000 feet
5.0-Gbyte 8-mm	5.0 Gbytes	13000 feet
3.5-inch diskette	1422 blocks (1.44 Mbytes)

---

Note - Capacity for 4-mm cartridge tapes is dependent on the type of drive and the data being written to the tape.

---

Backup Device Names

You specify a tape or diskette drive to use for backup by supplying a logical device name. This name points to the subdirectory containing the "raw" device file and includes the logical unit number of the drive. Table 6-4 shows this naming scheme.

Table 6-4

Device Type	Name
Tape	/dev/rmt/unit
Diskette	/vol/dev/rdiskette0/unlabeled

The drive writes at its "preferred" density, which usually means the highest density it supports. Most SCSI drives can automatically sense the density or format on the tape and read it accordingly.

Tape drive naming conventions use a logical, not a physical, device name.

Tape drives fall into two categories according to controller type:

• Xylogics 472 for 1/2-inch rack-mounted (top-loaded) reel-to-reel drives (maximum 4 units per controller)
• SCSI for 1/4-inch cartridge, 1/2-inch front-loaded reel-to-reel, and 4-mm or 8-mm helical scan drives (maximum 7 units per controller)

Within the /dev/rmt subdirectory is a single set of tape device files that support different output densities.

In general, you specify a tape drive device as shown in Figure 6-1.

Figure 6-1

· How to Specify the Default Density for a Tape Drive

Normally, you specify a tape drive by its logical unit number, which may run from 0 to n. For example, to specify the first drive, rewinding, use:

/dev/rmt/0

To specify the first drive, nonrewinding, use:

/dev/rmt/0n

To specify the second drive, rewinding, use:

/dev/rmt/1

To specify the second drive, nonrewinding, use:

/dev/rmt/1n

By default, the drive writes at its "preferred" density, which is usually the highest density it supports. If you do not specify a tape device, the command writes to drive number 0 at the default density the device supports.

· How to Specify Different Densities for a Tape Drive

You may want to transport a tape to a system whose tape drive supports only a certain density. In that case, specify a device name that writes at the desired density. Use this convention to specify rewind:

/dev/rmt/XA

and this convention to specify no rewind:

/dev/rmt/XAn

The unit and density characters are shown in Figure 6-1.

For example, to specify a raw magnetic tape device on the first (0) drive with medium density and no rewinding, use:

/dev/rmt/0mn

You can have both SCSI and non-SCSI tape drives on the same system. A SCSI controller can have a maximum of seven SCSI tape drives, and a non-SCSI controller can have a maximum of four tape drives. For each drive number (X), the density character depends on the controller and drive type as described in the following paragraphs.

Table 6-5 shows the device abbreviation for different tape controllers/units and media. Note that the first character in the device abbreviation for drive number does not have to be 0 as shown, but could be 1, 2, or 3, and so on, depending on how many tape drives are attached to the system.

Table 6-5

Controller	Drive Unit	Size	Type	Format	Tracks	Device Abbreviation
Xylogics(R) 472	Fujitsu M2444	1/2-inch	Reel	1600 bpi	9	/dev/rmt/0m
		1/2-inch	Reel	6250 bpi	9	/dev/rmt/0h
SCSI front-loaded	HP	1/2-inch	Reel	800 bpi	9	/dev/rmt/0m
				6250 bpi	9	/dev/rmt/0h
SCSI	Sysgen(R)	1/4-inch	Cartridge	QIC-11	4	/dev/rmt/0l
				QIC-24	4	/dev/rmt/0m
				QIC-11	9	/dev/rmt/0l
				QIC-24	9	/dev/rmt/0m
	Emulex(R) MT-02	1/4-inch	Cartridge	QIC-11	4	/dev/rmt/0l
				QIC-24	4	/dev/rmt/0m
				QIC-11	9	/dev/rmt/0l
				QIC-24	9	/dev/rmt/0m
	Archive(R) QIC-150	1/4-inch	Cartridge	QIC-150	18	/dev/rmt/0h

Table 6-5

Controller	Drive Unit	Size	Type	Format	Tracks	Device Abbreviation
	Wangtek(TM) QIC-150	1/4-inch	Cartridge	QIC-150	18	/dev/rmt/0h
	Desktop Backup Pack	1/4-inch	Cartridge	QIC-150	18	/dev/rmt/0h
	Exabyte(R) 8200 (2.3 GB)	8 mm	Cartridge	8 mm	Helical Scan	/dev/rmt/0m
	Exabyte 8500 (2.3 GB)	8 mm	Cartridge	8 mm	Helical Scan	/dev/rmt/0l
	Exabyte 8500 (5 GB)	8 mm	Cartridge	8 mm	Helical Scan	/dev/rmt/0m
	Archive(R) Python	4 mm	Cartridge	4 mm	Helical Scan	/dev/rmt/0

Rack-Mounted Non-SCSI 1/2-Inch Reel Drives

For 1/2-inch rack-mounted tape drives with either a Tapemaster or Xylogics 472 controller, substitute the density from Table 6-6 for the A variable in the device name (/dev/rmt/XA).

Table 6-6

Character	Density
null	Default "preferred" (highest) density (usually 6250 bpi uncompressed)
l	800 bpi
m	1600 bpi
h	6250 bpi
u	6250 bpi compressed

If you omit the density character, the tape is usually written at its highest density, not compressed.

SCSI 1/4-Inch Cartridge and 1/2-Inch Front-Loaded Reel Drives

For SCSI 1/4-inch cartridge and 1/2-inch front-loaded reel drives, substitute the density from Table 6-7 for the A variable in the device name (/dev/rmt/XA).

Table 6-7

Character	Density 1/4-Inch Cartridge	Density 1/2-Inch Front-Loaded Reel-to-Reel
null	Default preferred (highest) density	Default preferred (highest) density
l	QIC-11 format	800 bpi
m	QIC-24 format	1600 bpi
h	QIC-150	6250 bpi
u	Reserved	Reserved

For 1/4-inch cartridges, density is specified by the format in which the data is written: the QIC format. The QIC-11 and QIC-24 format write approximately 1000 bytes per inch on each track. The density for QIC-150 is somewhat higher. The "preferred" density for a 60-Mbyte 1/4-inch cartridge drive is QIC-24 and for a 150-Mbyte 1/4-inch cartridge drive is QIC-150.

An 18-track drive can write only QIC-150; it cannot be switched to write QIC-24 or QIC-11. Format selection is only useful for drives that can write both QIC-24 and QIC-11.

Guidelines for Drive Maintenance and Media Handling

A backup tape that cannot be read is useless. It is a good idea to clean and check your tape drives periodically to ensure correct operation. See your hardware manuals for instructions on procedures for cleaning a tape drive. You can test your tape hardware by copying some files to the tape and reading them back and then comparing the original with the copy. Or you could use the v option of the ufsdump command to verify the contents of the media with the source file system. The file system must be unmounted or completely idle for the v option to be effective. Be aware that hardware can fail in ways that the system does not report.

Always label your tapes after a backup. If you have planned a backup strategy similar to those suggested in the next section, you should indicate on the label "Tape A," "Tape B," and so forth. This label should never change. Every time you do a backup, make another tape label containing the backup date, the name of the machine and file system backed up, backup level, the tape number (1 of n, if it spans multiple volumes), plus any information specific to your site. Store your tapes in a dust-free safe location, away from magnetic equipment. Some sites store archived tapes in fireproof cabinets at remote locations.

You need to create and maintain a log that tracks which media (tape volume) stores each job (backup) and the location of each backed-up file.

Considering Other Issues

This section describes these other issues to consider for determining a backup strategy for your site:

• "When to Run Backups" on page 108
• "How Long to Save Backups" on page 109
• "How to Back Up Files to a Remote Drive" on page 109
• "Do You Need to Become Superuser?" on page 110
• "Should You Check File Systems Before a Full Backup?" on page 110
• "Do You Want to Put Multiple Backups on the Same Tape?" on page 111
• "Where Do the Files Reside?" on page 111
• "How Do You Backup on a Heterogeneous Network?" on page 111

When to Run Backups

In deciding when to run backups, consider things such as availability of an operator, impact on system performance, minimizing data loss, and level of file system activity.

Although operators may be less available, doing backups during off hours minimizes the impact on system performance and decreases the likelihood of file system activity getting in the way. The sooner you back up files after they have been changed, the less chance there is of loss of data.

Traditionally, operator intervention was important--someone had to change the tapes when they filled up. It is becoming less important because of higher-capacity and autoloading drives.

You can automate off-hours backups by having the crontab utility call a script that starts the ufsdump command. Whatever time you decide on, consistently run your backups at the same time each day.

How Long to Save Backups

Depending on how many file systems you back up, their size, and the capacity of your media, you may use quite a few tapes. The longer you save the tapes (rather than reusing them), the more tapes you need. You should be able to restore files for the last four weeks. Thus you should have at least four sets of tapes, one for each week, and rotate them each month. In addition, you should archive the full backups done monthly for at least a year, and then keep a yearly backup for a number of years.

Requirements for backups vary from site to site. You may want to be able to restore files from the last three months instead of four weeks. You may also need to do full backups weekly instead of monthly and keep the full backups for more than a year. The number of tapes you require will vary depending on your backup schedule, the size of the file systems, and the amount of activity on the file systems.

How to Back Up Files to a Remote Drive

To back up a set of systems over the network, you can run the ufsdump command from one system on each remote system (through remote shell or remote login) and direct the output to the system on which the drive is located. Note that you cannot directly specify files on remote systems in the files-to-backup argument. Typically, the drive is located on the system from which you run the ufsdump command, but it does not have to be.

You can use the ufsdump command to access a remote drive over the network. The command syntax is:

ufsdump [options] remote-host:backup-file files-to-backup

The only difference between this command and one you would use when backing up to a local drive is that the backup-file argument is prefaced with the remote-host name: the name of the remote system with the tape drive you want to back up to. Be sure to include the colon (:) after the host name, with no spaces before or after it.

---

Note - The naming convention you use for the remote drive depends on the system where the drive resides. If the drive is on a system that is running SunOS 4.x, use the SunOS 4.x convention (for example, /dev/rst0). If the system is running SunOS 5.x system software, use the SunOS convention (for example, /dev/rmt/0m).

---

To run a backup as a different user on a remote host, the command syntax is as follows:

ufsdump [options] user@remote-host:backup-file files-to-backup

Another way to back up files to a remote drive is to pipe the output from ufsdump to the dd command. See Chapter 4, "Copying UFS Files and File Systems," for information about using the dd command.

To be able to do backups across the network, you need access to the systems. You have to put entries in /.rhosts files on both clients and server to do centralized backups. If you have appropriate permissions, edit the remote system's /.rhosts file. Add the system from which you back up to the list of trusted hosts. Thereafter, you can log in as superuser on that system and do a backup to the remote system. If you do not have the proper permissions for the remote system, ask the system administrator to edit /.rhosts for you.

Do You Need to Become Superuser?

Because ufsdump needs to have read access to the raw device files, you should become superuser or be a member of the sys group to run the ufsdump command. Giving ordinary users read permissions for raw device files is a potential security problem.

Should You Check File Systems Before a Full Backup?

Most of the time, you do not need to check file systems for consistency before doing a backup. If you suspect a file system problem, you probably should run a consistency check. You can use the -m option to the fsck command to see if a file system needs further consistency checking. See Chapter 12, "Checking File System Integrity," for information about using the fsck command.

Do You Want to Put Multiple Backups on the Same Tape?

If you are backing up multiple file systems that do not fill up a whole tape, you can use the "no rewind" option and place one file system after the next on a single tape. Putting multiple file systems on one tape can be quite useful for incremental backups, which may take up much less space than full backups, and it reduces the number of tapes needed. Keep in mind, however, that putting multiple file system backups on a single tape complicates finding the version of a file you want to restore.

Where Do the Files Reside?

You can back up local file systems only. Many of the file systems available to a workstation are mounted across the network from a server. Consequently, they reside on a server, not the workstation. For example, the /export/home directories for workstation users typically are located on servers. These file systems are backed up from the server, not the workstation. In fact, users are denied permission if they try to run ufsdump on files they own that are located on a server.

How Do You Backup on a Heterogeneous Network?

The command used to back up a file system has to be run on the local file system. You can, however, use the rlogin or rsh command to log onto the system. You can also direct the output of the ufsdump command to a remote tape drive.

When doing backups on a heterogeneous network, always use the device naming convention appropriate for the individual system. For example, run the SunOS 4.x dump command on a SunOS 4.x client system. Remember to use that SunOS 4.x device name (for example, /dev/sd0h).

The naming convention you use for the remote drive depends on the system to which the drive is attached. If the drive is on a system that is running SunOS 4.x, use the SunOS 4.x device name (/dev/rst0). If the system is running SunOS 5.x, use the SunOS 5.x device name (for example, /dev/rmt/0m).

To back up a SunOS 5.x client from a SunOS 4.x server, use the rlogin (or rsh) command and run ufsdump on the client system. If the tape drive is on a SunOS 5.x client, use the SunOS 5.x tape device name (for example, /dev/rmt/0m).

What Are the Security Issues?

The ufsdump and ufsrestore commands respect restricted access to back up devices and target file systems.

If you want to be cautious, you should:

• Set restrictive file permissions on any backup table of contents you create and store on the system (see the a option to ufsdump).
• Be sure the permissions on raw device files for disk slices are set so only privileged operators can back them up.
• Be aware that providing entries in /.rhost files on both clients and servers for centralized backups can be a possible security hole for unauthorized access.

Planning a Backup Schedule

You can use the ufsdump command to do two kinds of backups: full backups and incremental backups. A full backup includes all the files in the specified file system or directory. An incremental backup includes only those files in the specified file system that have changed since a previous backup at a lower level. The level of the backup determines which files are backed up.

Level 0 backs up the complete file system. Levels 1 through 9 perform incremental backups. Whenever you do a backup, you can tell the ufsdump command the level of the backup to perform. If you do not specify a level, the command defaults to level 9. A backup schedule is the schedule you establish to run the ufsdump command on a regular basis at different levels. You run the ufsdump command and specify the level of dump that matches the schedule you have chosen.

The Outcomes of Different Backup Schedules

The following sections discuss some possible schedules. All schedules assume you begin with a full backup (level 0) and that you use the u option to record each backup in the /etc/dumpdates file.

The Nine-to-Five The schedule shown in Table 6-8 is probably the most commonly used, and is recommended for most situations.

Table 6-8

	Floating	Mon	Tues	Wed	Th	Fri
1st of Month	0
Week1		9	9	9	9	5
Week2		9	9	9	9	5
Week3		9	9	9	9	5
Week4		9	9	9	9	5

With this schedule, each weekday tape accumulates all files changed since the end of the previous week (or the initial level 0 for the first week) and each Friday's tape contains all the files changed since the first level 0. For the level 9 backups, the previous level 0 or level 5 is the closest backup at a lower level. All the files that have changed since that lower-level backup at the end of the previous week are saved each day. For the Friday level 5, the nearest lower-level backup is the level 0 done at the beginning of the month. Consequently, each Friday's tape contains all the files changed during the month to that point.

Table 6-9 shows how the contents of the tapes can change across two weeks.

Table 6-9

	Mon	Tues	Wed	Th	Fri
Week1	a b	a b c	a b c d	a b c d e	a b c d e f
Week2	g	g h	g h i	g h i j	a b c d e f g h i j k

With this schedule, you need a minimum of six or nine tapes: one for the level 0, four for the Fridays, and one daily tape (if it is reused) or four daily tapes. Use four daily tapes to save different versions of files. When you reuse the daily tape, only the latest version of a file (during that week) is saved. If you use different daily tapes and save the daily tapes for four weeks before reusing them, which is recommended, the total needed is 21.

If you need to restore the complete file system you need three tapes: the level 0, the most recent Friday tape, and the most recent daily tape.

The Nine- to-Two-Three-Four-Five Table 6-10 shows a schedule where each weekday tape accumulates all files changed since the beginning of the week (or the initial level 0 for the first week) and each Friday's tape contains all the files changed that week.

Table 6-10

	Floating	Mon	Tues	Wed	Th	Fri
1st of Month	0
Week1		9	9	9	9	3
Week2		9	9	9	9	3
Week3		9	9	9	9	4
Week4		9	9	9	9	5

Table 6-11 shows how the contents of the tapes can change across two weeks.

Table 6-11

	Mon	Tues	Wed	Th	Fri
Week1	a b	a b c	a b c d	a b c d e	a b c d e f
Week2	g	g h	g h i	g h i j	g h i j k

With this schedule, you need at least six or nine tapes: one for the level 0, four for the Fridays, and one daily tape (if reused) or four daily tapes, assuming you reuse the daily tapes each week.

If you need to restore a complete file system, you need five tapes: the level 0, all preceding Friday tapes, and the most recent daily tape.

The Three-Four-Five-Six-to-Two Table 6-12 shows a schedule where each weekday tape contains only the files changed since the previous day and each Friday's tape contains all files changed since the initial level 0 at the beginning of the month.

Table 6-12

	Floating	Mon	Tues	Wed	Th	Fri
1st of Month	0
Week2		3	4	5	6	2
Week3		3	4	5	6	2
Week4		3	4	5	6	2

Table 6-13 shows how the contents of the tapes can change across two weeks.

Table 6-13

	Mon	Tues	Wed	Th	Fri
Week1	a b	c d	e f g	h	a b c d e f g h i
Week2	j k l	m	n o	p q	a b c d e f g h i j k l m n o p q r s

With this schedule, you need at least nine tapes: one for the level 0, four for the Fridays, and four daily tapes, assuming you reuse daily tapes each week, which is not recommended. If you save the weekly tapes for a month, you need 21 tapes.

If you need to restore the complete file system, you need six tapes: the level 0, the most recent Friday tapes, and all the daily tapes for that week.

Recommendations for Choosing a Backup Schedule

For most purposes, the 99995 ("nine-to-five") schedule is adequate. However, you may want to consider a number of factors in choosing the schedule that is best for your site. For example, do you want to minimize the number of tapes, the time spent doing backups, the time doing a full restore on a damaged file system, or the time spent retrieving individual files that get accidently deleted? In fact, if you do not need to minimize time and media spent on backups, you could do level 0 backups every day.

Here are some things to consider in choosing your backup schedule:

• You should probably do a level 0 backup of your root file system between once a week to once a month, depending on how much it changes. Back it up daily if /var and its mail spool files are in the root slice.
• You should do a full backup on most file systems (that need backups) at least once a month. Keep in mind that frequent level 0 backups produce large backup files that take a long time to write. It also may take a long time to retrieve individual files, since the drive has to move sequentially to the point on the tape where the file is located. Retrieving individual files may be easier if you run incremental backups to pick up the small changes in the file systems you back up. Finding which incremental tape a file is on can take time, however.
• If you have a file system that is used for an application like word processing, it may be very important to you to save a historical record of all the different versions of files across time. Consider doing incremental backups every working day, commonly at level 9. This schedule saves all files modified that day, as well as those files still on disk that were modified since the last backup of a level lower than 9. Remember that a file changed on Tuesday and then again on Thursday, goes onto Friday's lower-level backup looking like it did Thursday night, not Tuesday night. If a user needs the Tuesday version, you cannot restore it unless you have a Tuesday backup tape (or a Wednesday backup tape, for that matter). Similarly, a file present on Tuesday and Wednesday, but removed on Thursday, does not appear on the Friday lower-level backup. If you need the ability to restore different versions of files, be sure you do not reuse the same tape for the daily incremental backups.
• Save a week's worth of daily level 9 backups at least until you do a backup at a level lower than the daily level. However, you should save the daily tapes longer if you want to save different versions of files.
• If you are most concerned about being able to restore quickly a complete file system to its most recent state, do lower-level backups more frequently.
• If you are most concerned about minimizing the number of tapes you use, increase the level of the incremental backups done across the week, so only changes from day to day are saved on each daily tape. In addition, you can increase the level of the backups done at the end of the week, so only

changes from week to week (rather than the whole month) are saved on the weekly tapes. Finally, you can try to put each day's and week's incremental backup onto the same tape by not rewinding the tapes after each use.

• If you are backing up a number of file systems on the same server, you may want to offset the schedule for different file systems, so you are not doing all level 0s on the same day.

Example Backup Strategy for a Server

Table 6-14 shows an example backup strategy for a heavily used file server on a small network where users are doing file-intensive work, such as program development or document production. It assumes that the backup period begins on a Sunday and consists of four seven-day weeks.

Table 6-14

Directory	Date	Level	Tape Name
/	1st Sunday	0	n tapes
/usr	1st Sunday	0	"
/export	1st Sunday	0	"
/export/home	1st Sunday	0	"
	1st Monday	9	A
	1st Tuesday	9	B
	1st Wednesday	5	C
	1st Thursday	9	D
	1st Friday	9	E
	1st Saturday	5	F
/	2nd Sunday	0	n tapes
/usr	2nd Sunday	0	"
/export	2nd Sunday	0	"
/export/home	2nd Sunday	0	"
	2nd Monday	9	G
	2nd Tuesday	9	H
	2nd Wednesday	5	I

Table 6-14

Directory	Date	Level	Tape Name
	2nd Thursday	9	J
	2nd Friday	9	K
	2nd Saturday	5	L
/	3rd Sunday	0	n tapes
/usr	3rd Sunday	0	"
/export	3rd Sunday	0	"
/export/home	3rd Sunday	0	"
	3rd Monday	9	M
	3rd Tuesday	9	N
	3rd Wednesday	5	O
	3rd Thursday	9	P
	3rd Friday	9	Q
	3rd Saturday	95	R
/	4th Sunday	0	n tapes
/usr	4th Sunday	0	"
/export	4th Sunday	0	"
/export/home	4th Sunday	0	"
	4th Monday	9	S
	4th Tuesday	9	T
	4th Wednesday	5	U
	4th Thursday	9	V
	4th Friday	9	W
	4th Saturday	5	X

With this plan, you use 4n tapes (the number of tapes needed for four full backups of /, /usr, /export, and /export/home) plus 24 additional tapes for the incremental backups of /export/home. This plan assumes that each incremental backup uses one tape and you save the tapes for a month.

Here is how this plan works:

1. On each Sunday, do a full backup (level 0) of /, /usr, /export, and /export/home. Save the level 0 tapes for at least 3 months. Depending on your sites needs, you may want to save them longer.

2. On the first Monday of the month, use tape A to do a level 9 backup of /export/home. ufsdump copies all files changed since the previous lower-level backup, in this case, the level 0 backup that you did on Sunday.

3. On the first Tuesday of the month, use tape B to do a level 9 backup of /export/home. Again, ufsdump copies all files changed since the last lower-level backup--Sunday's level 0 backup.

4. On the first Wednesday, use tape C to do a level 5 backup. ufsdump copies all file changed since Sunday.

5. Do the Thursday and Friday level 9 backups on tapes D and E. ufsdump copies all files changed since the last lower-level backup--Wednesday's level 5 backup.

6. On the first Saturday of the month, do a level 5 backup of /export/home, which copies all files changed since the previous lower-level backup--in this case, the level 0 backup you did on Sunday. Store tapes A-F until the first Monday of the next 4-week period, when you use them again.

7. Repeat steps 1-6 for the next three weeks, using tapes G-L and 4n tapes for the level 0 on Sunday, and so on.

8. For each 4-week period, repeat steps 1-7, using a new set of tapes for the level 0s and reusing tapes A-X for the incremental backups. The level 0 tapes could be reused after 3 months.

This plan allows you to save files in their various states for a month. It requires many tapes, but does ensure that you have a library of tapes to draw on in case a user needs to work on an old project that was canceled and then started up again. If you cannot afford so many tapes, you could reuse Tapes A-F each week.