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 the data to the media.
The ufsdump command needs to know only an appropriate block size and how to detect 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.
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 ufsdump command, when used with the -u option, maintains and updates the /etc/dumpdates file. 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/c0t0d0s0 9 Tue Jul 13 10:58:12 1999 /dev/rdsk/c0t0d0s0 0 Tue Jul 13 10:46:09 1999 /dev/rdsk/c0t0d0s1 0 Tue Jul 13 13:41:04 1999
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 modified 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.
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 in order to restore the entire file system.
The /etc/dumpdates file 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 might not be able to find the tapes (or files) you need.
The dump-file argument (to the -f option) specifies the destination of the backup, which can be one of the following:
Local tape drive or diskette drive
Remote tape drive or diskette drive
Use this argument when the destination is not the default local tape drive /dev/rmt/0. If you use the -f option, then you must specify a value for dump-file.
The dump-file argument can also point to a file on a local or remote disk, which, if used by mistake, can fill up a file system.
Typically, dump-file specifies a raw device file for a tape or diskette drive. When ufsdump writes to an output device, it creates a single backup file that might span multiple tapes or diskettes.
You specify the tape or diskette device on your system using a device abbreviation. The first device is always 0. For example, if you have a SCSI tape controller and one QIC-24 tape drive that uses medium-density formatting, use this device name:
When you specify a tape device name, you can also type the letter "n" at the end of the name to indicate that the tape drive should not rewind after the backup is completed. For example:
Use the "no-rewind" option if you want to put more than one file onto the tape. If you run out of space during a backup, the tape does not rewind before ufsdump asks for a new tape. See "Backup Device Names" for a complete description of device naming conventions.
You specify a remote tape or diskette drive using the syntax host:device. ufsdump writes to the remote device when root on the local system has access to the remote system. If you usually run ufsdump as root, the name of the local system must be included in the /.rhosts file on the remote system. If you specify the device as user@host:device, ufsdump tries to access the device on the remote system as the specified user. In this case, the specified user must be included in the /.rhosts file on the remote system.
Use the naming convention for the device that matches the operating system for the system on which the device resides, not the system from which you run the ufsdump command. If the drive is on a system that is running a previous SunOS release (for example, 4.1.1), use the SunOS 4.1 device name (for example, /dev/rst0). If the system is running Solaris software, use the SunOS 5.8 convention (for example, /dev/rmt/0).
You must specify remote devices explicitly with the dump-file argument. In previous SunOS releases, the rdump command directed the output to the remote device defined by the dumphost alias. ufsdump does not have an rufsdump counterpart.
When you specify a dash (-) as the dump-file argument, ufsdump writes to the standard output.
The -v option (verify) does not work when the dump-file argument is standard output.
You can use the ufsdump and ufsrestore commands in a pipeline to copy a file system by writing to the standard output with ufsdump and reading from the standard input with ufsrestore, as shown in this example:
# ufsdump 0f - /dev/rdsk/c0t0d0s7 | (cd /home; ufsrestore xf -)
You must always include files-to-backup as the last argument on the command line. This argument specifies the source or contents of the backup. It usually identifies a file system but can also identify individual files or directories.
For a file system, specify the raw device file for a disk slice. It includes the disk controller abbreviation (c), the target number (t) for SCSI devices only, a number indicating the disk number (d), and the slice number (s). For example, if you have a SCSI disk controller on your standalone system (or server) and you want to back up /usr located in slice 6, specify the device as follows:
You can specify the file system by its mount point directory (for example, /home), as long as there is an entry for it in the /etc/vfstab file.
See "Backup Device Names" for a complete description of device naming conventions.
For individual files or directories, type one or more names separated by spaces.
When you use ufsdump to back up one or more directories or files (rather than a whole file system), a level 0 backup is done. Incremental backups do not apply.
The ufsdump command automatically detects the end-of-media for most devices. Therefore, you do not usually need to use the -c, -d, -s, and -t options to perform multivolume backups.
The only time you need to use the end-of-media options is when ufsdump does not understand the way the device detects the end-of-media or you are going to restore the files on a system with an older version of the restore command. To ensure compatibility with older versions of the restore command, the size option can still force ufsdump to go to the next tape or diskette before reaching the end of the current tape or diskette.
If you do not specify any tape characteristics, the ufsdump command uses a set of defaults. You can specify tape cartridge (c), density (d), size (s), and number of tracks (t). Note that you can specify the options in any order as long as the arguments that follow match the order of the options.
The ufsdump Command Does Not ...
Automatically calculate the number of tapes or diskettes needed for backing up file systems
You can use the dry run mode (S option) to determine the amount of space that is needed before actually backing up file systems.
Provide built-in error checking to minimize problems when backing up an active file system
Enable you to back up files that are remotely mounted from a server
Files on the server must be backed up on the server itself. Users are denied permission to run ufsdump on files they own that are located on a server.