AdvFS provides extended file-system backup capabilities with the vdump and vrestore commands. In addition, AdvFS filesets can be safely backed up on line using the AdvFS clonefset utility.

While the dump command supports UFS exclusively, the vdump command can be used to back up not only AdvFS filesets, but also UFS and other standard file systems. The dump and restore commands function differently from the vdump and vrestore commands. The dump command works at the inode level so it can handle only UFS files. The vdump command works at the file level. It scans the directories and uses regular POSIX file-system calls to access directories and files. This processing method allows the vdump command to back up different types of file systems.

Caution The tools you use to back up and restore files must be compatible. For example, if you use the vdump command to back up a file system, you must use the the vrestore command to restore saved files. You cannot use the vrestore command to restore files backed up with the dump command.

This chapter includes the following sections:

• Unique Features of vdump
• Dumping to Tape
• Dumping Subdirectories
• Compressing Filesets
• Dumping with Error Protection
• Verifying Backup
• Dumping and Restoring Files Remotely

• How Cloning Works
• Using Clones

Restoring Data

• Unique Features of vrestore
• Restoring Files
• Restoring Selected Savesets

The vdump command provides features that are not available with the UFS dump command. For example, you can back up mounted filesets or individual subdirectories, print the names of files as they are backed up, or compress your data.

There are many options available for the vdump command. See the vdump(8) reference page for details on all of the flags. To issue a vdump command, use the following format:

vdump options fileset_name

The vdump command creates a three-part array of fixed-size blocks called a saveset as it copies all files that are new or have changed after a certain date to the default storage device or the device that you specify. The first block of the saveset contains the block size and other saveset attributes. The vdump command then makes two passes through the directory hierarchy of the file system being backed up. In the first pass it saves the directories and the file names to the second area of the saveset. In the second pass, it writes the files to the third area of the saveset.

A saveset can span multiple tapes or a tape can contain multiple savesets. Savesets on tapes are delimited by file marks that are written when the saveset is closed by the vdump command.

The vdump command has a number of functions that the UFS dump command does not have. These extended features are available for all file-system types (not just AdvFS) that you back up with the vdump command. You can:

• Save mounted filesets.
• Choose the subdirectory that you want to back up. You do not need to dump an entire fileset.
• Compress files to minimize the saveset size.
• Specify the number of in-memory buffers. You can maximize throughput by choosing a number compatible with your storage device. Specify the same number when you run the vrestore command.
• Display the current vdump version number.
• Display help information during the dump process.
• Limit your display to error messages. You do not need to display warning messages.
• Display the names of files as they are backed up.
• Configure output with an error-protection system that will allow you to recover data even if there is a read error when you restore.

Because the AdvFS vdump command supports other file-system types, you can use a single backup utility for your entire facility. You can use the unique features provided by the vdump command on all your file systems.

You can place multiple savesets on one tape with the vdump command. Set the -N flag to specify no rewind or specify a no-rewind device such as /dev/nrmt0h. This ensures that the tape does not rewind when the dump finishes.

If a saveset requires more than one tape to complete, you will be prompted to mount more.

Do not combine the output from the dump and vdump utilities on the same tape. If the vrestore command is used to recover files from a tape created by the dump utility, the results are unpredictable and can result in data loss.

You can selectively back up individual subdirectories of a fileset by specifying the subdirectory with the -D flag of the vdump command. Without the -D flag, if you specify a subdirectory instead of a fileset on the command line, the vdump command backs up the entire fileset that contains the named subdirectory. If you specify the -D flag, backup is always run at level 0.

You can compress filesets as they are backed up. This reduces the amount of storage required for the backup and allows the dump to run faster on slow devices because less data is written. Use the -C flag with the vdump command to request compression.

You can use the -x flag with the vdump command to place exclusive-or (XOR) blocks on your tape so that the vrestore command can recover damaged blocks. The vdump command creates these blocks every n number of blocks you specify to form a checksum block. The valid range of n is 2 to 32; the default is 8.

If a block is bad and you have dumped it using the -x flag, the vrestore command automatically skips the bad block. It reads the rest of the n-1 blocks and the checksum block. (The checksum block is ignored unless a previous bad block is found.) The bad block is then recreated from the good blocks and the checksum block.

Dumping with error protection requires saving one extra block for every n blocks. It can correct only one block in each series of n blocks when the blocks are restored. This means there is a trade-off:

• If you believe tapes are error prone or you require extremely accurate backups and you have many tapes available for backup, set the value of -x to 2. This will permit error correction of one in two bad blocks. It will require 50% more tape because after every two dump blocks, a checksum block will be written.
• If you believe that tapes are generally reliable but you want to be able to correct a rare bad block, set the value of -x to 32. This will require 3% more tape because an extra block will be added for every 32 blocks written. You could then recover information from any one bad block in the group of 32 dump blocks.

You can check your saveset and make sure you have backed up the files you intended. After your backup is complete, run the vrestore command with the -t flag to display the files you have saved. This will not initiate the restore procedure.

Although AdvFS does not have a remote dump command equivalent to the UFS rdump command, it is possible to dump AdvFS files to remote locations. Use the vdump command on the local host. Then access the remote host using the rsh command and copy the file to tape with the dd command. To perform this procedure, the /.rhosts file on the remote system must allow access from root on the local node.

The following example dumps a fileset named sar to a tape on node rachem:

# /sbin/vdump -f - /sar | rsh rachem dd of=/dev/rmt0h

To restore the fileset sar from the remote tape drive, enter:

# rsh rachem -n dd if=/dev/rmt0h obs=60k |
                     /sbin/vrestore -x -f - -D /sar

Note that the output block size for dd has been set to 60 kilobytes to match the default block size of the vdump command. If your tape drive is more efficient using another block size, change the size by using the -b flag when you issue the vdump command.

When you run the vrestore command, you must specify the same block size that you used with your vdump command. If the output block size for dd does not match the vdump block size, the vrestore command will exit with the following error message:

vrestore: unable to use saveset; invalid or corrupt format 

Because AdvFS backs up at the file level, you can also do remote dumping and recovery by using the vdump command to dump NFS mount points. Mount each disk on the tape server and use the vdump command for each mount point. The vrestore command can then be used to restore information. However, with this method you will lose some AdvFS extended file attributes because NFS does not recognize them. For example, if you have a striped file, it will be restored to a single volume.

A clone fileset is a read-only snapshot of the data in an existing fileset. You create a clone with the clonefset utility (typically daily) to capture the fileset data at a particular time. As you modify the data in your original files, AdvFS saves the data that existed in the original, page by page, into the clone.

Cloning is transparent to the user. Clone filesets are built quickly and have little impact on system performance. To clone a fileset, issue the clonefset command using the following format:

clonefset domain_name fileset_name clone_name

After mounting the clone fileset, you can backup the clone fileset with any supported backup tool. Because the clone is a picture of the fileset at a particular time, it is not affected by current system activity. You can back up the clone whenever it is convenient.

Note You can create a clone fileset for any AdvFS fileset including root. You cannot clone UFS file systems. Only one clone can exist per fileset.

When you create a clone fileset, only pointers to the file metadata (file structure) are stored in the clone fileset. Data files are not copied. When you modify your data in the original fileset, AdvFS uses the concept of copy-on-write to save the pages that existed when the clone fileset was created. As you update data in a file, the original pages associated with the change are copied to the clone fileset. The original pages are then rewritten with the new data. The clone fileset retains the originals of all data that has changed since the clone was created.

To create a clone fileset, AdvFS:

1. Creates a read-only fileset to be the clone.
2. Copies only the original fileset tag directory to the clone.
3. Creates a link between the two filesets.
4. Sets up bookkeeping to track whether a given page has been updated.

Once a page has been added to the clone, it is marked. If the same page is updated again, the clone does not change. It already contains the information that existed when the clone was created.

AdvFS allocates clone fileset space by pages (8 kilobytes). If you modify one page in a large file, then only one additional page is allocated by the clone. Note that if a file is modified so that pages are appended, these pages will not appear in the clone because they were created after the clone was created.

Unless you modify every page of every file in the original fileset during the life of clone, the clone fileset occupies less disk space than the original fileset.

Note Changing text files with an editor may cause the entire original file to be copied to the clone. Many editors rewrite the entire file regardless of what has changed. When this happens, your clone fileset may grow very large. There is no way for AdvFS to alter this process.

When you delete a file that existed when the clone was created, it remains available (but not visible in the original fileset) for the life of the clone. The file is not copied to the clone, but the actual delete is delayed until the clone is deleted. The version of the file that is retained is the one that existed when the clone was created. Later updates are lost.

The size of the clone fileset depends upon the number of updates that occur during the life of the clone. This is not information that is of general interest because it constantly changes as files are updated. Thus, the df command does not accurately reflect the size of the clone fileset.

The following steps explain the process AdvFS uses when you modify data in a file after you create a clone fileset:

1. AdvFS checks to see if this is the first time the data has changed for this file. If so, the original data may need to be saved in the clone. AdvFS determines this by examining the status of the clone's metadata. There are three possibilities:

   • Metadata does not exist.

     The file was created after the clone was created and is not part of the clone fileset. Nothing is done to the clone fileset.

   • Metadata exists and the data has been marked as saved.

     This is not the first update to this page of the file. Nothing is done to the clone fileset.

   • Metadata exists but this page has not been marked as saved.

     This is the first change to this page of the file. Original data is being updated. Metadata for this page of the clone is altered and the page marked as saved. Disk space is allocated in the clone fileset and the original data is copied into the new space.

2. AdvFS updates the original file.

You can create clones either with the command-line interface or with the AdvFS GUI. A description of the command-line procedure follows.

Clones are created with the clonefset command. Specify the file domain and fileset you want to clone and then assign a clone fileset name. After creating a mount point and mounting the clone, you can run the vdump utility on the clone at any time.

The following example backs up the public fileset on line by creating the public_clone fileset and backing it up. The file domain in this example is domain1.

# clonefset domain1 public public_clone

# mkdir /public_clone

# mount -t advfs domain1#public_clone /public_clone

# vdump -0 -u -C /public_clone

To remove the public_clone fileset, enter:

# umount /public_clone

# rmfset domain1#public_clone

If your database has an online backup utility, Digital recommends that you use it for your backup. If it does not, you can back up databases with database down time limited to the short time it takes to create the clone fileset. Backing up a database with a clone fileset is the same as backing up any other fileset. You get the same benefits. See Cloning for Online Backup.

The procedure for backing up a database from a clone is as follows:

1. Shut down the database so that all database buffers are flushed and the filesets have a complete, consistent copy of the database files.
2. Clone the fileset and mount the clone.
3. Reactivate the database.
4. When you want to back up the clone fileset, run a backup procedure such as the vdump utility or Digital NetWorker.
5. Unmount and delete the clone.

Caution Do not use anything except the database's own utilities to back up an active database. You can use the vdump and vrestore commands on a database clone.

The vrestore command reads the blocks from a saveset created with the vdump command and processes the records in the block. The vrestore command will not work on a saveset created by the UFS dump command.

You must have write access to the directory you restore to. Root-user privilege allows you to restore to any directory that has write privileges. See the vrestore(8) reference page for details on the vrestore command options.

The vrestore command performs a number of activities that the UFS restore command does not. You can:

• Display the current vrestore version number.
• List the saveset structure.
• Display error messages only. Information messages will not be shown.
• Specify how the vrestore command should proceed if it encounters a file that already exists. You can choose whether the command will always overwrite an existing file, never overwrite an existing file, or query you for each event.

The vrestore command allows you to select specific files and directories to be restored. It can restore data from a file, a pipe, magnetic tapes, or disks.

Before you restore files, you can check if the saveset you are accessing contains the information you wish to recover. You can list the names and sizes of all files in your backup by running the vrestore command using the -t flag. The restore operation will not be performed. You can also display the files and directories saved by running the vrestore command with the -i flag. This interactive option allows you to select individual files or directories to restore from a list.

Restoring data from a clone fileset is the same as restoring data from any other fileset.

To restore from a tape containing multiple savesets, use the mt command with the
fsf n (which means forward space n files) option to locate the saveset you want to restore. Then use the vrestore command.

You can selectively restore files from your saveset with the -x flag of the vrestore command. You can also specify a destination path other than the current directory for the restored files.

The following example restores the file named data_file from the /mnt/fdump saveset. It is restored to the /mnt directory.

# vrestore -f /mnt/fdump -D /mnt -x data_file

vrestore: Date of the vdump save-set: Tue Jun 13 15:27:36 1995

Digital's NetWorker Save and Restore product provides scheduled, online, automated backup. Use NetWorker with AdvFS as a comprehensive backup solution. NetWorker can automatically back up multiple servers in a heterogeneous environment. It has a graphical interface and several scheduling options.

To use the automated backup capabilities of NetWorker, use the AdvFS clonefset utility to clone all filesets for backup and mount the clone filesets. (You can create a script to accomplish this task.) Then, set up NetWorker to automatically back up the clone filesets on a convenient schedule.