Once you have decided which file systems to back up, you need to figure out which backup type you are going to use.

Determining the Backup Type

Solaris offers you several backup types to choose from. You can use the full backup or an incremental backup by using the ufsdump command. The full backup copies the whole file system or directory, whereas the incremental backup copies only those files from a file system or directory that have changed since a previous backup. Which previous backup? That can be determined by using the dump level, which we will discuss when we explore the ufsdump command later in this chapter.

A full backup takes longer and uses more tapes, but it's simple to perform. Furthermore, it is a very efficient way to restore the data in case of a crash or disaster. Simply take the most recent full backup and copy it to the system. An incremental backup takes less time and requires fewer tapes to copy the data from the system; however, it may take longer and require a greater number of tapes (or sets) to restore the entire data back to the system.

Before using the ufsdump command for a backup, your system should be in single-user mode, or the file system should be unmounted, to preserve data integrity. If you are backing up file systems while users are creating, removing, or editing files, some data will not be included in the backup. However, if you do want to make a backup of a file system while it is active, you can take a snapshot of it by using the fssnap command without putting the system into single-user mode. Then, you can back up the snapshot. These various backup types are compared in Table 9-2.

A good backup strategy is to choose a mix of these backup types based on your needs—for example, a weekly full backup combined with incremental backups on weekdays, as opposed to a full backup every day.

The data will be backed up on a removable medium that you need to choose.

Determining Which Backup Device to Use

You will need to choose an appropriate tape device depending on the volume of data that needs to be backed up. You will typically use the tape media listed in Table 9-3 for backups from the Solaris system. As shown, these drives differ by their storage capacity.

The amount of data you will be backing up partially determines which storage device you should use. Your choice of backup media also depends on the availability of the equipment (that supports it) and the media (usually tape) on which you store the data. Another criterion for choosing backup media might be the data transfer speed supported by the equipment and the media. Supposedly, you could perform backups with diskettes, but why would you? It would be so cumbersome and time consuming. But again, it depends on the backup needs of your site.

Once you know which media you are going to use for backup, you can determine your backup schedule.

Determining Backup Schedule

A backup schedule is the schedule that you put in place to execute regular backups—for example, by running the ufsdump command. In a nutshell , your backup strategy will be based on the business requirements of your site along with applicable regulatory requirements. In that context, while creating a backup schedule you should consider various issues related to your site's needs, including the following:

• Do you need to minimize the number of tapes used for backups?

• How much time do you have at your disposal to make backups?

• How much time will be available to perform a full restore should you lose a file system?

• How much time will be available for retrieving individual files that have been accidentally deleted?

The frequency of backups depends on your need to minimize the number of tapes used and the time needed for the backup (and restore) process. For example, if you have an unlimited number of tapes and unlimited time available for backup and restore operations and you have critical data, you should make a full backup every day. However, this is not realistic for most sites. Typically, you want to make enough backups to enable you to restore files from the last four weeks. Let's work through an example to design a strategy to meet this requirement. Consider the following elements of the strategy:

• Each month, use at least four sets of tapes: one set for each week—say a full backup on Friday and incremental backups on other days of the week. By the fifth week of the year you will start reusing the tapes from the first week.

• The last full backup of the fourth Friday would be considered the monthly backup. You archive the monthly backups for a year.

• The full backup of the 52nd week will be the yearly backup. You can archive it for a number of years .

As Figure 9-1 illustrates, you will need 18 sets of tapes (4 weekly, 13 monthly, and 1 yearly) for the year for this scheme. In the figure, we refer to a period of four weeks as a monthlet , for convenience.

Figure 9-1: A yearly backup strategy to meet the requirement of being able to restore files from the past four weeks

Once you have a backup strategy in place, you need to figure out how to use the commands for performing backups.

Performing Backups of an Unmounted File System

To perform full and incremental backups, Solaris offers the ufsdump command, which should be used only on the unmounted or read-only mounted file systems.

If you attempt to dump a mounted read-write file system, it may cause system disruption or inability to restore the backed up files.

Using the ufsdump Command

The ufsdump command has the following syntax:

ufsdump [<options>] [<arguments>] <files>

An option is a one-character single string. An argument may be a list of multiple strings whose association with the option is determined by order. The <files> argument is mandatory and must appear last in the command. It is used to specify a whole file system or files within a file system that will be copied to a magnetic tape, a diskette, or a disk file. Some common options and arguments for the ufsdump command are listed here:

• 0–9. Specify the backup (dump) level. 0 for a full backup, 1–9 for incremental backups.

• a <archiveFile>. Store a table of contents for the backup in a file specified by <archiveFile> . This file will be used by the ufsrestore command to determine whether a file is there for a restore.

• D. Dump to a diskette.

• f <dumpFile>. Specify the device to which the files will be dumped. The default value is the first tape drive: /dev/rmt/0 . Possible values for <dumpFile> are a local tape drive or disk drive, a remote tape drive or disk drive, or—for dumping to standard output.

• n. Notify all operators in the sys group in case the ufsdump needs attention.

• o. Take the drive offline when the backup completes.

• s < size >. Specify the size of the volume to which the files are being copied.

• S. Estimate the amount of space in bytes needed to perform a backup without actually performing the backup.

• u. Update the dump record by adding an entry to the /etc/dumpdates file. The entry contains information about when a file system was backed up and at which dump level.

• v. Verify the content on the backup media against the source file after a tape (or a disk) has been written. Can't be used when the dump is done to the standard output.

• w. Warn by listing the file systems that have not been backed up within a day. This information is retrieved from the /etc/dumpdates and /etc/vfstab files. When this option is specified, all other options are ignored and the command exits immediately after producing the list.

• W. Warn by highlighting all the file systems that have not been backed up within a day, but produce a list of all the file systems in the /etc/dumpdates file.

Remember the following about the ufsdump command:

• It backs up data only from the raw disk slice.

• If the file system is still active during copying, any data in memory buffers will not be copied.

• The backup performed by the ufsdump command does not include the free blocks—that is, the blocks that are not being used as storage blocks, inodes, or indirect address nodes.

• The ufsdump command does not make an image of the disk slice.

• If symbolic links on the slice that's being backed up point to files on other slices, only the links are copied.

  Exam Watch

  Make sure you understand the effects of various options that can be issued with the ufsdump command.

The ufsdump command has built-in support for incremental backups.

Using the Dump Levels in the ufsdump Command

You can use the ufsdump command to make full backups or incremental backups. The support for this characteristic is built into the command though dump levels. By specifying dump level 0, you tell the command to make a full backup. Dump levels 1 to 9 are used for backing up the files that have changed since the last backup was performed. Which backup? It's the last lower-level backup. For example, if you backed up on Monday by using dump level 1, on Tuesday using dump level 3, and on Wednesday using dump level 2, then the command entered on Wednesday will copy the files that have been changed since Monday. As you can see, the dump levels give you lots of freedom to design a backup scheme according to your need. Two such schemes are presented, as examples, in Table 9-4.

The scheme presented in the first row of the table will make a full backup on each Sunday, and on any other day of the week it will back up only the files that have changed since the backup made on the previous day. The scheme presented in the second row will make a full backup on each Sunday, and on any other day of the week it will back up the files that have changed since the last full backup was made. This scheme is called differential backup. Let's assume it takes one tape to make a backup on each day, and further assume that the system crashes on Friday morning before the Friday backup. How many tapes will you need to restore the data? You will need five tapes if you were using the incremental scheme and only two tapes (Sunday and Thursday) if you were using the differential scheme. Accordingly, it takes more effort to back up using a differential scheme and less effort in restoring, as compared to an incremental scheme.

You may need to keep the backup information so that you could use it later to restore the data. The backup information can be automatically maintained by using the /etc/dumpdates file.

Purpose of the dumpdates File

The ufsdump command issued with the -u option maintains the /etc/dumpdates file. The command updates the /etc/dumpdates file by adding an entry into it that contains the following information:

• The file system backed up

• Dump level of the backup

• The day, date, time, and year of the backup

So, the entries in an /etc/dumpdates file will look like the following:

/dev/rdsk/c0t0d0s3 0 TUE APR 12 15:25:13 2005 /dev/rdsk/c0t0d0s5 0 MON APR 18 14:12:30 2005

When you perform an incremental backup, the ufsdump utility docs the following:

1. Checks the /etc/dumpdates file to find the date of the most recent backup of the next lower dump level.

2. Copies to the backup media all the files that were modified since the date of the lower-level backup.

3. After the backup is complete, a new information line, which describes the backup you just completed, replaces the information line for the previous backup at that level.

You can also take a look at the /etc/dumpdates file to verify that backups are being performed as scheduled. If a backup has not completed—for example, due to an equipment failure—the backup is not recorded in the dumpdates file. You may also need information from the dumpdates file for restoring the data. For example, assume you need to restore an entire disk. To determine which tapes you need to restore, you would check the dumpdates file for a list of the most recent backup dates and levels of backups.

When you need to back up complete file systems to a backup device and you want to use the combination of full backups and incremental backups, use the ufsdump command. There are many other kinds of backups that you may be interested in. For example, you might just want to copy or move individual files or groups of files to another directory, to an archive file, or to another disk or tape. In that case, you can use an appropriate command from a set of commands discussed in the following section.

Using Other Backup Utilities

You can use the cpio , pax , and tar commands to copy files and file systems to tapes, and you can use the dd command to copy files and file systems between disks. The choice of the command depends on the flexibility and precision required for the copy. You do not need to format or make a file system on tapes before you use any of these commands, because all three commands use the raw device.

The cpio Command

You can. use the cpio (copy in and out) command to transfer individual files or groups of files from one file system to another. The syntax for this command is shown here:

cpio <mode> [<options>]

The <mode> specifies the mode in which the command will run, and <options> specify the options. There are three possible modes in which the cpio command can be used:

• -i. This specifies the copy-in mode used to read an archive. It reads an archive from the standard input, conditionally extracts the files contained in it, and places them into the current directory tree according to the options.

• -o. This specifies the copy-out mode, which is used to create an archive. It reads a list of file path names from the standard input and copies those files to the standard output in the form of a cpio archive according to the options.

• -p. This specifies the pass mode used to copy the content of one directory to another. It reads a list of file path names from the standard input and copies those files into the specified destination directory tree according to the options.

The options for the cpio command are described in Table 9-5.

For example, consider a combination of the find command and the cpio command:

find . -print -depth  cpio -pdm /tmp/data1

In this example, the find command pipes the file names to the cpio command, which copies those files to the directory /tmp/data1 . This was an example of a pass mode. Consider an example of cpi command used in the -o mode:

ls  cpio -oc > /tmp/testfile.backup

It takes all the files piped to it by the ls command, groups them together, and sends them to a single file /tmp/testfile.backup . The following example demonstrates the cpio command in the -i mode:

cat /tmp/testfile.backup  cpio -icd "notes/pol*" "notes/sen*"

This command takes the output file of the previous command and extracts only those files that match the pattern notes/pol* or notes/sen* . The directories will be created as needed because of the -d option.

The tar Command

You can use the tar command to archive files to a single file in the tape archive (tar) format, or extract files from a tar file. This is a very popular archiving and backup command, as most of the software for UNIX platforms is distributed in the tar format. The syntax for the tar command is shown here:

tar <options> <tarfileName> <filesToBackup>

The options are listed here:

• c. Create the tar file with the name specified by <tarfileName> .

• f. Use the file name or device name specified by <tarfileName> as a name of the archive.

• t. List the names of files in the archive.

• u. The files are added only if they do not already exist in the archive or if they have been modified since they were archived to that tar file last.

• v. Verbose.

• x. Extract the files from the archive file with the name specified by <terfileName> .

As an example, the following command will copy the /home/jkerry directory to the tape device /dev/rmt/0 :

tar cvf /dev/rmt/0 /home/jkerry

You can extract the files from the tape by issuing the following command:

tar xvf /dev/rmt/0

As the following command shows, you can also create the archive file on the disk:

tar cvf jkerry.tar /home/jkerry

You can extract the files from the tar file as follows :

tar xvf jkerry.tar

While using the tar command, remember the following:

• Archiving files to a tape with the -c option destroys any files already on the tape at or beyond the current tape position.

• You can use the substitution wildcards (? and *) to specify the names of the files to be archived. For example, *.doc means copy all files with the .doc extension.

• You cannot use substitution wildcards in the file names to specify which files to extract from a tar file.

• The tar command does not transport user permissions and timestamps along with the files.

There is another command you can use to handle the archive files: the pax command.

The pax Command

You can use the pax (portable archive interchange) to perform the following tasks: read and write the members of an archive file, make a list of the members of an archive file, and copy directory hierarchies. It supports multiple archive formats such as cpio and extended tar. The syntax for the pax command is shown here:

pax [<mode>] [<options>]

The <mode> specifies the mode in which the pax command operates. The four available modes are described here:

• -r. Read mode when -r is specified and -w is not. Read an archive file from the standard input and extract the files with the path names that match specified patterns.

• -w. Write mode when, -w is specified, and -r is not. Write the specified files into the standard output in a specified archive format. If no file operands are specified, a list of files (one per line) to archive are read from the standard input.

• -rw. Copy mode when both r and w are specified. Copy the specified files to the destination directory. If no file operands are specified, a list of files (one per line) to archive are read from the standard input.

• <mode> not specified. List mode when neither -r and nor -w is specified. Write to the standard output the names of members of an archive file that matches the patterns specified in the standard input.

Some common options for the pax command are described in Table 9-6.

For example, the following command copies the contents of the current directory into a tape device /dev/rmt/0 :

pax -w -f /dev/rmt/0

As another example, the following command copies the directory subtree with the top directory specified by <sourcedir> to the directory specified by <destdir> :

pax -rw <sourcedir> <destdir>

The pax archive can span across multiple volumes , and it has better portability than the tar and cpio commands across POSIX-compliant systems. The cpio , pax , and tar commands are compared in Table 9-7.

If you simply want to clone a disk, the dd is the command to use.

The dd Command

The dd command is used to copy files or file systems between disks. In addition, by using this command you can make a copy of a complete file system from the hard disk to a tape. Note that the dd command makes a literal block-level copy of a complete UFS file system to another file system or to a tape.

The syntax for the dd command is shown here:

dd if=<inputFile> of=<outputFile> [<options>]

<inputFile> specifies the path for the input, and <outputFile> specifies the path for the output. The default values for the if and of arguments are standard input and standard output, respectively. Of course, you can specify appropriate input and output devices. For example, to make a literal copy of a file system on a diskette to a file in the /tmp directory, you can issue the following command:

dd if=/floppy/floppy0 of=/tmp/floppydump.file

As another example, the following command will copy the entire content of one hard disk to another hard disk:

dd if=/dev/rdsk/c0t0d0s2 of=/dev/rdsk/c0tld0s2 bs=128k

The option bs=128k specifies the block size. The source disk and the destination disk must have the same geometry.

The cpio archive may span across multiple volumes. The cpio archive created using one UNIX system can be read by many other UNIX systems. Here is a summary of when to use these various commands:

• Use cpio , or pax , or tar to transport file systems from one disk to another.

• Use dd to clone a disk.

• Use tar to copy files to a diskette, or to make an archive of files for distribution on the Internet.

• Use ufsdump to perform full and incremental backups.

Another criterion to distinguish one backup command from another is whether the command is aware of the file system boundaries and whether it supports multiple volumes. You can check these properties from the information supplied in Table 9-8.