4    Backing Up and Restoring Data

Backing up file-system data is a critical component of an overall strategy of preparing for application failure, system failure, and disaster scenarios. Designing a good backup strategy ensures that the data in the backup is usable when it is needed.

This chapter covers items to consider when planning your backup strategy:

• Assuring data and metadata integrity (Section 4.1)

• Creating a backup source (Section 4.2)

• Methods and tools that can be used to perform the backup (Section 4.3)

4.1    Data and Metadata Integrity

Before backing up your data, ensure that the source of your backup, both the data in your files and the AdvFS metadata (file structure information), are in a consistent state and will not change during the time that the backup is running.

4.1.1    Ensuring Data Integrity

A backup is only useful if the data it collects is consistent. Before beginning a backup, you must place your data files into such a state. This process has two steps.

1. Stop or quiesce your applications so that the current state of the data files is consistent from the application's standpoint.

2. Make sure that updates to the application's data files are written to permanent storage and are not cached either by the application or by the file system.

Failure to take these steps could result in a backup that is not usable because the data in it is inconsistent from an application standpoint.

Some applications, such as Oracle, provide explicit ways to quiesce and flush data to disk. Other applications do not have this functionality but use synchronous writing methods to ensure that if the application is stopped, the data written is on disk. Finally, some applications do not provide quiesce-and-flush functionality and do not use synchronous writing techniques.

4.1.1.1    Ensuring Data Integrity Using An Application's Quiesce Function

Some applications can quiesce and flush data to disk in preparation for backup. In Oracle, for example, this is known as Hot Backup Mode. To use it, enter the following Oracle SQL command:

ALTER TABLESPACE name BEGIN BACKUP

Then, once the source of the backup has been created (Section 4.2), enter the following Oracle SQL command to take the tablespace out of Hot Backup Mode:

ALTER TABLESPACE name END BACKUP

4.1.1.2    Ensuring Data Integrity Using Synchronous Writing

AdvFS provides ways to ensure that data written by an application is in permanent storage and is not in the application or file-system buffer cache:

• Use an fsync() system call to flush the cached data.

• Open a file with the O_SYNC or O_DSYNC flag to cause all cached data to be synchronously written to storage.

If an application using either of these techniques is cleanly shut down, you are guaranteed that all cached data has been written to permanent storage.

4.1.1.3    Ensuring Data Integrity Without Using Synchronous Writing

If an application does not have a quiesce function and does not call for synchronous writes, you can ensure that all data written by the application to its data files has been written to permanent storage before you begin your backup by doing one of the following:

• Mounting the fileset with the -o sync option. This forces updates to files in the fileset to be synchronously written to storage. As using this option can cause a significant decrease in performance to all the applications using that fileset, it is preferable to have applications use one of the other methods described to flush only the updates that need to be flushed to storage.

• Entering the chfile with the -l on option. This causes updates to a file to be synchronously flushed to storage regardless of the I/O mode requested by the applications using the file. See Section 5.5.1 for a discussion of I/O mode.

• Cleanly stopping the application. This causes the operating system's smoothsync daemon to flush all cached data to disk. After the application has been stopped, wait at least twice as many seconds as the value of smoothsync_age kernel tunable before starting your backup or creating the backup source. The value of the smoothsync_age tunable can be retrieved by the command:

  # sysconfig -q vfs smoothsync_age
  

4.1.2    Ensuring Metadata Integrity

After you have ensured that your data files are consistent from an application standpoint, you must take steps to ensure that the AdvFS metadata is also consistent. Failure to do so could result in AdvFS domain panics, system panics, or user data corruption. To guarantee consistent AdvFS metadata in your backup source, do one of the following:

• Freeze the domain using the freezefs command (Section 4.1.2.1)

• Unmount all filesets in the domain (Section 4.1.2.2)

4.1.2.1    Ensuring Metadata Integrity by Freezing Domains

The freezefs command causes a domain to enter into a metadata-consistent state and guarantees that it stays that way until the specified freeze time expires or it is explicitly thawed with the thawfs command. All of the filesets in the domain are frozen. All metadata, which could be spread across multiple volumes or logical units (LUNs), is flushed to disk and does not change for the duration of the freeze.

When you freeze a file system, all in-process file-system operations are allowed to complete. Some file-system operations that do not require metadata updates (for example, read) work normally even if the file system is frozen.

Once frozen, the file system remains in this metadata-consistent state until it is thawed:

• By timing out

• By the issuance of the thawfs command

• In a cluster, by shutting down any node of a frozen file system or if any cluster member fails

By default, the freezefs command freezes a file system for 60 seconds. Use the -t option to specify a lesser or greater time-out value in seconds or to specify that the domain remains frozen until being thawed by the thawfs command. See freezefs(8) and the Cluster Administration manual for more information.

4.1.2.2    Ensuring Metadata Integrity by Unmounting Filesets

You can ensure that AdvFS metadata doesn't change in a domain by unmounting all of the filesets in the domain. Do not run any AdvFS utilities that can run on unmounted domains when you want to ensure metadata integrity.

4.2    Creating a Backup Source

Once you have created your backup source from the mounted fileset, you can complete the backup. To create the source, use one of the following:

• Original fileset (Section 4.2.1)

• Fileset clone (Section 4.2.2)

• Logical Storage Manager (LSM) split mirror (Section 4.2.3)

• Controller-based clone (Section 4.2.4)

• Controller-based snapshot (Section 4.2.5)

4.2.1    Using a Mounted Original Fileset as a Backup Source

In some situations you can use your original mounted fileset as the source for your backup.

4.2.1.1    Advantages and Disadvantages

Table 4-1 lists the advantages and disadvantages of mounting the original fileset as a backup source.

Table 4-1:  Using a Mounted Original Fileset as a Backup Source

4.2.1.2    Ensuring Data and Metadata Integrity

To ensure that the data in the fileset is consistent, follow any procedure detailed in Section 4.1.

For backup applications that access the file system through the POSIX interface (such as the vdump utility), no special steps are needed to ensure the integrity of the metadata .

4.2.1.3    Preparing the Backup Source

Beyond ensuring data and metadata integrity, no special steps are needed to prepare a mounted original fileset for use as a backup source.

4.2.2    Using a Mounted Fileset Clone as a Backup Source

A fileset clone (Section 2.4.10) is a read-only snapshot of the data in an existing fileset. A fileset clone does not contain all the data at the time it is created. When you modify the data in your original files, AdvFS saves the data that existed in the original, page by page, into the fileset clone.

You must have the optional AdvFS Utilities to create a fileset clone. You must be the root user to clone a fileset. Only one clone can exist per fileset.

4.2.2.1    Advantages and Disadvantages

Table 4-2 lists the advantages and disadvantages of using a mounted fileset clone as a backup source.

Table 4-2:  Using a Mounted Fileset Clone as a Backup Source

4.2.2.2    Ensuring Data and Metadata Integrity

To ensure that the data in the fileset is consistent, follow any procedure detailed in Section 4.1. If the data spans more than one fileset, be certain that all associated filesets are consistent.

Because the fileset cloning process is done entirely within AdvFS, no special steps are needed to ensure the integrity of the AdvFS metadata.

4.2.2.3    Preparing the Backup Source

To create a fileset clone, ensure that the data in the original fileset is in a consistent state. Then create the fileset clone with the clonefset command.

The following example clones the pssm fileset in the domain1 domain. The name of the new fileset clone is pssm_clone.

1. Create the clone and mount it.

   # clonefset domain1 pssm pssm_clone
   # mkdir /pssm_clone
   # mount -t advfs domain1#pssm_clone /pssm_clone
   

2. Run the backup process using the pssm_clone. See Section 4.3.11 for more information.

3. Remove the clone.

   # umount /pssm_clone
   # rmfset domain1 pssm_clone 
   

4.2.3    Using a Mounted Fileset from an LSM Split Mirror as a Backup Source

If the data you want to back up is stored in a domain built entirely on LSM mirrored volumes, you can split off an LSM mirror (detach a mirror), mount it, and use it as your backup source. You must be the root user to perform this operation. See the Logical Storage Manager manual for directions on how to detach a mirror.

4.2.3.1    Advantages and Disadvantages

Table 4-3 lists the advantages and disadvantages of using an LSM split mirror as a backup source.

Table 4-3:  Using an LSM Split Mirror as a Backup Source

4.2.3.2    Ensuring Data and Metadata Integrity

To ensure that the data in the fileset is consistent, follow any procedure detailed in Section 4.1.

If the storage making up the domain consists of only one LSM volume, no special steps are needed to ensure the integrity of the AdvFS metadata. If the storage spans multiple LSM volumes, see Section 4.1.2.

4.2.3.3    Preparing the Backup Source

The freeze and thaw steps are only necessary if your domain spans more than one LSM volume. If you are not sure, perform the commands anyway. They do not harm the domain. Freezing and thawing a single fileset freezes and thaws the entire domain.

The following example assumes that the original domain was comprised of two LSM volumes and that a mirror was detached from each. The data is in a domain that has a fileset named data mounted on /data. The two mirror volumes are called /dev/vol/mirrorvol1 and /dev/vol/mirrorvol2.

1. Freeze the domain.

   # /usr/sbin/freezefs /data
   

2. Execute the LSM commands necessary to detach the mirrors and reconstitute them as new LSM volumes. See the Logical Storage Manager manual for directions.

3. Once the LSM split mirror operations have completed, thaw the domain's metadata.

   # /usr/sbin/thawfs /data
   

   Now your applications can continue to run on the original domain.

4. Create a new domain directory using the two newly created LSM volumes.

   # mkdir /etc/fdmns/mirror_domain
   # ln -fs /dev/vol/mirrorvol1 /etc/fdmns/mirror_domain
   # ln -fs /dev/vol/mirrorvol2 /etc/fdmns/mirror_domain  
   

   Do not use the mkfdmn command to create the new directory. Doing so causes the mirror to become inaccessible.

5. Create a mount-point directory and mount the data fileset created from the split mirror in mirror_domain.

   # mkdir /backup
   # mount -o dual mirror_domain#data /backup
   

The backup can now be performed from the /backup directory.

4.2.4    Using a Mounted Fileset from a Controller-Based Clone as a Backup Source

Some storage controllers, such as the Compaq HSG80 and HSV110, allow you to split off a hardware mirror using controller-based commands. Conceptually, this is similar to a split : mirror: there are two (or more) complete physical copies of the data and one is separated for backup.

4.2.4.1    Advantages and Disadvantages

Table 4-4 lists the advantages and disadvantages of using a controller-based clone as a backup source.

Table 4-4:  Using a Mounted Fileset from a Controller-Based Clone as a Backup Source

4.2.4.2    Ensuring Data and Metadata Integrity

To ensure that the data in the fileset is consistent, follow any procedure detailed in Section 4.1.

If the storage making up the domain consists of only one hardware LUN, no special steps are needed to ensure the integrity of the AdvFS metadata. If the storage spans multiple hardware LUNs, see Section 4.1.2.

4.2.4.3    Preparing the Backup Source

The freeze and thaw steps are only necessary if your domain spans more than one LUN. If you are not sure, perform the commands anyway. They do not harm the domain. Freezing and thawing a single fileset freezes and thaws the entire domain.

The following example assumes that the data is in a domain that has a fileset named data mounted on /data. The clones created are /dev/disk/dsk25c and /dev/disk/dsk26c.

1. Freeze the domain.

   # /usr/sbin/freezefs /data 
   

2. Execute the commands necessary to create the controller-based clone. For examples of these commands using the Compaq HSG80 controller, see the Best Practice Using StorageWorks HSG80 Controller-Based Cloning and Snapshotting.

3. Thaw the metadata for the domain.

   # /usr/sbin/thawfs /data  
   

   Now your applications can continue to run on the original domain.

4. Create block device special files for the newly cloned LUNs. This should be done on the host that will mount the new backup source. The /sbin/hwmgr command is asynchronous, so it could complete before the block device special files are actually created.

   On a stand-alone system, enter:

   # /sbin/hwmgr -scan scsi
   

   On a cluster, enter:

   # /sbin/hwmgr scan component -category scsi_bus -cluster
   

   Every time a new LUN is created, a new set of device special files is created.

5. Identify the block device special files.

   # /sbin/hwmgr -view devices 
   

6. Create the directory and symbolic links necessary to access the new domain on /dev/disk/dsk25c and /dev/disk/dsk26c.

   # mkdir /etc/fdmns/clone_domain 
   # ln -fs /dev/disk/dsk25c /etc/fdmns/clone_domain 
   # ln -fs /dev/disk/dsk26c /etc/fdmns/clone_domain 
   

   Do not use the mkfdmn command to create the new domain. Doing so causes the cloned data to become inaccessible.

7. Create a directory and mount the data fileset in clone_domain.

   # mkdir /backup
   

   If the clone domain and fileset are not mounted on the original host:

   # mount clone_domain#data /backup 
   

   If the clone domain and fileset are mounted on the original host:

   # mount -o dual clone_domain#data /backup 
   

The backup can now be performed from the /backup directory.

4.2.5    Using a Mounted Fileset from a Controller-Based Snapshot as a Backup Source

Some storage controllers, such as the Compaq HSG80 and HSV110, allow you to create a snapshot that copies the critical RAID metadata for a data set to other media and then employs copy-on-write technology to preserve a point-in-time copy of the original data set. Conceptually this is similar to a fileset clone.

4.2.5.1    Advantages and Disadvantages

Table 4-5 lists the advantages and disadvantages of using a controller-based snapshot as a backup source.

Table 4-5:  Using a Mounted Fileset from a Controller-Based Snapshot as a Backup Source

4.2.5.2    Ensuring Data and Metadata Integrity

To ensure that the data in the fileset is consistent, follow any procedure detailed in Section 4.1.

If the storage making up the domain consists of only one hardware LUN, no special steps are needed to ensure the integrity of the AdvFS metadata. If the storage spans multiple hardware LUNs, see Section 4.1.2.

4.2.5.3    Preparing the Backup Source

The freeze and thaw steps are only necessary if your domain spans more than one LUN. If you are not sure, perform the commands anyway. They do not harm the domain. Freezing and thawing a single fileset freezes and thaws the entire domain.

The following example assumes that the data is in a domain that has a fileset named data mounted on /data. The snapshots created are /dev/disk/dsk25c and/dev/disk/dsk26c.

1. Freeze the domain. The default freeze time is 60 seconds.

   # /usr/sbin/freezefs /data 
   

2. Execute the commands necessary to create the controller-based snapshot. For examples of these commands using the Compaq HSG80 controller, see the Best Practice Using StorageWorks HSG80 Controller-Based Cloning and Snapshotting.

3. Thaw the metadata for the domain.

   # /usr/sbin/thawfs /data  
   

   Now your applications can continue to run on the original domain.

4. Create block device special files for the newly cloned LUNs. This should be done on the host that will mount the new backup source. The /sbin/hwmgr command is asynchronous, so it could complete before the block device special files are actually created.

   On a stand-alone system, enter:

   # /sbin/hwmgr -scan scsi
   

   On a cluster, enter:

   # /sbin/hwmgr scan component -category scsi_bus -cluster
   

   Every time a new LUN is created, a new set of device special files is created.

5. Identify the block device special files.

   # /sbin/hwmgr -view devices 
   

6. Create the directory and symbolic links necessary to access the new domain on /dev/disk/dsk25c and /dev/disk/dsk26c.

   # mkdir /etc/fdmns/snap_domain 
   # ln -fs /dev/disk/dsk25c /etc/fdmns/snap_domain 
   # ln -fs /dev/disk/dsk26c /etc/fdmns/snap_domain 
   

   Do not use the mkfdmn command to create the new domain. Doing so causes the snapped data to become inaccessible.

7. Create a directory and mount the data fileset in snap_domain.

   # mkdir /backup
   

   If the snapshotted domain and fileset are not mounted on the original host:

   # mount snap_domain#data /backup 
   

   If the clone domain and fileset are mounted on the original host:

   # mount -o dual snap_domain#data /backup 
   

The backup can now be performed from the /backup directory.

4.3    Backup Methods and Tools

Once you have created a data-consistent and metadata-consistent backup source, you can back up your data. There are a number of ways to do this:

• Mount the backup source on the same host as the original data set to run the backup. This is required if your backup source is the original fileset or a fileset clone.

• Mount the backup source on a host different from the original data set to run the backup. This relieves the original host from the overhead of the backup processing.

• Back up the contents of your raw LUNs directly from disk to tape or other backing store.

There are many backup and restore products available. AdvFS provides the vdump and vrestore commands and the remote rvdump and rvrestore commands. The remainder of this section describes how to use these commands.

4.3.1    Introduction to the vdump and vrestore Commands

Once you have prepared your backup source, you can use the vdump command for back up. The vdump command works at the file level. It scans the directories and uses regular POSIX file system calls to access directories and files. See vdump(8) and vrestore(8) for more information.

The dump and restore commands function differently from the vdump and vrestore commands. They work at the inode level so they can handle only UFS files.

In this section only the vdump and vrestore commands are discussed, but the rvdump and rvrestore commands can be substituted for remote operation.

Note

You do not have to be root user to use the vdump and vrestore commands. However, you must have write permission for the directory to which you want to restore files. Only the root user can save and restore the AdvFS user and group quota files and the fileset quotas.

Caution

The vrestore command for operating system versions earlier than Version 4.0 does not properly restore information saved by the vdump command for Version 4.0 or later. The vdump and vrestore dump file formats are compatible in Version 4 and Version 5 operating systems.

The vdump command creates a collection of fixed-size blocks, called a saveset. It copies all files that are new or have changed after a certain date to the default storage device or to the device that you specify.

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 vdump command closes the saveset.

The vdump command has the following form:

vdump options mount_point

For example, to dump the filesets mounted at /psm to tape:

# vdump -0 -f /dev/tape/tape0_d1 /psm

4.3.2    Unique Features of the vdump Command

The vdump command has a number of functions that the UFS dump command does not have. With the vdump command you can do the following:

• Save mounted filesets.

• Choose a 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. Maximize throughput by choosing a number compatible with your storage device.

• 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 recovers data even if a read error occurs when you restore.

• Handle AdvFS and UFS sparse files without zero fills.

4.3.3    Specifying Backup Level Using the vdump Command

You can specify the level of incremental backup in the vdump command. A value of 0 specifies complete fileset backup. A higher number specifies a less complete backup. The vdump(8) reference page describes a plan that cycles dump levels so that complete backups are saved on two tapes at a time.

User and group quota files and fileset quotas are saved only when you are root user and you specify a level 0 backup. You can only back up quotas for locally-mounted systems.

The vdump command operates by checking the file modification date. This might cause problems on a subsequent incremental backup because the file modification date does not change if you rename or move a file and do not modify the data. Therefore, if you back up your files then move or rename them, change the modification date using the touch command:

touch filename

4.3.4    Dumping to Tape Using the vdump Command

You can place more than one saveset on a single tape by using the vdump command. Set the -N option to specify no rewind or specify a no-rewind device such as /dev/ntape/tape0. This ensures that the tape does not rewind when the vdump command finishes. Executing another vdump command causes the next saveset to be stored starting at the current tape position.

If your saveset requires more than one tape to complete, the vdump command prompts you to mount another.

To restore data from a tape containing more than one saveset, see Section 4.3.16.

To locate a tape device on your system, enter the /sbin/hwmgr command with the -view devices option.

For more information see hwmgr(8) and the Hardware Management manual.

4.3.5    Dumping to Standard Output Using the vdump Command

When the backup saveset device is the dash (-) character, the vdump command writes to standard output. Therefore, you can use the vdump and vrestore commands in a pipeline expression to copy one fileset to another. The following are typical commands; they are equivalent:

# vdump -0f - /usr | vrestore -xf - -D /mnt

# vdump -0 -f - /usr | (cd /mnt; vrestore -x -f -)

The rvdump and rvrestore commands are unable to use the dash (-) character. The output device must be specified.

4.3.6    Dumping Subdirectories Using the vdump Command

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

4.3.7    Dumping to Files or Disk Partitions

You can store your saveset as a file on disk. This feature is useful if you want to do full weekly backups to tape for archiving and incremental backups to disk for quick access. Saving to disk increases the speed of saving and recovery because disks are faster than tape devices.

For example, Monday evening you can save an incremental backup to a file containing Monday's activity. In this example, the day's files are backed to a fileset called projects.Monday. The fileset is mounted on /projects.

# vdump -9f /backup/projects.Monday /projects

To restore the copy of a file, revenue, saved to disk in the backup on Monday:

# vrestore -xf /backup/projects.Monday -D /projects revenue

You can also store your saveset on an empty partition. However, the saveset is not available under file system control and could be lost if the partition is reassigned. For example, to dump the fileset mounted at /projects to the partition /dev/disk/dsk2g:

# vdump -f /dev/disk/dsk2g -D /projects

To examine the devices on your system, enter the /sbin/hwmgr command with the -view devices option.

Do not back up to the a or c partition because these partitions include block 0, which contains the disk label. The device driver does not overwrite the disk label so you lose part of your data. If you use the a or c partition, an error message is displayed only if you are using a character or raw device; block special devices do not return an error. It is better to back up to another disk partition that does not contain block 0 if you have the space.

If you want to use the a or c partition and the rest of the disk is empty, you must first clear the disk label using the disklabel command with the -z option. All prior information that existed on the disk is lost. If you do not clear the disk label, the vdump command might appear to save valid savesets, but when the vrestore command attempts to interpret the disk label as part of the saveset, it returns the following message:

vrestore: unable to use save-set; invalid or corrupt format

This is also true for the rvdump and rvrestore commands.

See disklabel(8), vdump(8), vrestore(8), and the System Administration manual for more information.

If you want to copy a complete disk, see the System Administration manual.

4.3.8    Compressing Savesets

You can compress savesets 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 vdump command with the -C option to request compression. You cannot specify the compression ratio; it is determined by the contents of the dump.

Note

If you are using a tape drive that automatically does hardware compression, using the vdump command with compression might result in a larger saveset than expected. Sometimes, due to compression algorithms, already compressed data gets expanded when an attempt is made to do more compression.

4.3.9    Dumping with Error Protection

You can use the vdump command with the -x option to place checksum 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. The valid range of n is 2 to 32; the default is 8. If the vrestore command detects a read error in a block, it uses the other blocks and the checksum block to recreate the bad 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 is a trade-off because extra storage is needed to provide the added security.

• If you believe tapes are error prone or if you require extremely accurate backups and you have many tapes available for backup, set the value of the -x option to 2. This permits error correction of one bad block for every two blocks saved. It requires 50% more tape because after every two dump blocks, a checksum block is 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 the -x option to 32. This requires 3% more tape because an extra block is added for every 32 blocks written. You can then recover information from any one bad block in the group of 32 dump blocks.

4.3.10    Listing Saved Files in a vdump Saveset

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

4.3.11    Backing Up a System Disk Using the clonefset and vdump Commands— an Example

This example illustrates a level 0 backup of a disk where the clonefset command is used to create the source of the backup information. It assumes that dsk6, the backup disk, is the same size disk as dsk0, the disk being backed up. In this example the root domain, named root_domain, is on /dev/disk/dsk0a. The usr domain, named usr_domain, is on /dev/disk/dsk0g and the swap partition is on /dev/disk/dsk0b. The /var fileset is in usr_domain.

It is a good idea to shut down and reboot the system in single-user mode for the duration of fileset clone creation. This ensures that there is no activity on /, /usr, and /var. The backup procedure can be done in multiuser mode, but it is highly recommended that it be done when the system activity is low.

1. Copy the disk label directly from the current system disk and restore it to the new system disk.

   # disklabel -r dsk0 > /tmp/backupdisklabel
   # disklabel -R -r -t advfs dsk6 /tmp/backupdisklabel
   # rm /tmp/backupdisklabel
   

2. Create the backup domains and filesets and mount them.

   # mkfdmn -F -r /dev/disk/dsk6a root_domain_backup
   # mkfset root_domain_backup root
   # mkfdmn -F /dev/disk/dsk6g usr_domain_backup
   # mkfset usr_domain_backup usr
   # mkfset usr_domain_backup var
   # mkdir /root_backup /usr_backup /var_backup
   # mount root_domain_backup#root /root_backup
   # mount usr_domain_backup#usr /usr_backup
   # mount usr_domain_backup#var /var_backup
   

3. Create the fileset clones for the filesets and mount them.

   # clonefset root_domain root root_clone
   # clonefset usr_domain usr usr_clone
   # clonefset usr_domain var var_clone
   # mkdir /clones /clones/root /clones/usr /clones/var
   # mount root_domain#root_clone /clones/root
   # mount usr_domain#usr_clone /clones/usr
   # mount usr_domain#var_clone /clones/var
   

4. Use the vdump command to dump the clones and the vrestore command to restore the filesets.

   # vdump -0f - /clones/root | vrestore -xf - -D /root_backup
   # vdump -0f - /clones/usr | vrestore -xf - -D /usr_backup
   # vdump -0f - /clones/var | vrestore -xf - -D /var_backup
   

5. Change the backup /etc/fdmns directory to point to the correct disk.

   # rm -rf /root_backup/etc/fdmns/root_domain
   # mv /root_backup/etc/fdmns/root_domain_backup\
     /root_backup/etc/fdmns/root_domain
   # rm -rf /root_backup/etc/fdmns/usr_domain
   # mv /root_backup/etc/fdmns/usr_domain_backup\
     /root_backup/etc/fdmns/usr_domain
   

6. Edit the /etc/sysconfigtab file to point to the new swap file:

   Search for the entry that sets the swap device:

   1. Search for the entry that sets the swap device.

      swapdevice=/dev/disk/dsk0b
      

   2. Replace it with the new swap device name.

      swapdevice=/dev/disk/dsk6b
      

7. Shut down the system and reboot from dsk6 to verify the newly created backup.

   If you are creating dsk6 for backup and plan to return to the original root domain, shut down and reboot from dsk0.

4.3.12    Dumping and Restoring Files Remotely

The rvdump command backs up files from a single mounted fileset or an AdvFS fileset clone to a remote storage device. You must be able to execute the rsh command on the remote node to which you are dumping. See rsh(8) for server and client access rules.

The rvdump command has the same options as the vdump command, but you must specify the node name for the device that you are backing your files to. The following example dumps a fileset sar to a tape on node rachem:

# rvdump -0f rachem:/dev/tape/tape0 /sar

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

# rvrestore -xf rachem:/dev/tape/tape0 -D /sar

You cannot back up user and group quota files and fileset quotas with remote backup commands.

The rvdump and rvrestore commands do not recognize the dash (-) character to specify standard output. You must specify the output device.

4.3.13    Unique Features of the vrestore Command

The vrestore command restores files by processing the blocks from a saveset created by the vdump command. The vrestore command does not work on a saveset created by the UFS dump command.

You do not have to be root user to run the vrestore command, but you must have write privilege for the directory you restore to. Only the root user can restore quota files and fileset quotas. See vrestore(8) for details.

The vrestore command performs a number of activities that the UFS restore command does not. The command allows you to do the following:

• Display the current vrestore version number.

• Display the source directory path.

• List the saveset structure, that is, the files that were saved.

• Display error messages only. Information messages are not shown.

• Specify how the vrestore command should proceed if it encounters a file that already exists. You can choose whether the command always overwrites an existing file, never overwrites an existing file, or queries you for each event.

4.3.14    Restoring Files Using the vrestore Command

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

Use the same version of the vdump and vrestore utilities. If your version of the vrestore utility is unable to read the format of your saveset, you get an error message.

Run the vrestore command with the -t option to display the names and sizes of all files in the saveset. The restore operation is not performed.

You can also display the files and directories in the saveset by running the vrestore command with the -i (interactive) option. You can then select individual files or directories to restore.

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

Start with the full backup if you are restoring an entire fileset. Then restore later incremental backups on top of this to retrieve files that have changed since the full backup was created. Files that were deleted after the full backup was performed are restored. It is necessary to delete these files manually.

4.3.15    Restoring Quotas Using the vrestore Command

You can restore AdvFS user and group quota files either to an AdvFS fileset or to a UFS file system. If you are restoring AdvFS quota files to a UFS file system, quotas must be activated on the UFS file system. AdvFS fileset quotas cannot be restored to a UFS file system because no UFS analog exists for AdvFS fileset quotas. You must be root user to restore quotas.

4.3.16    Restoring from a Tape with Many Savesets Using the vrestore Command

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

The following example selects and restores the fourth saveset on a tape:

# mt fsf 3
# vrestore -xf /dev/ntape/tape0

If you do not know the location of the saveset directory you want to restore, run the vrestore command with the -i option. When you have reached the saveset you want, use the interactive shell to specify the files you want to retrieve.

You can use the vrestore command with the -x option followed by the file names to selectively restore files from your saveset. You can 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: Fri Apr 26 15:27:36 2002
 

If your restore operation requires more than one tape, the vrestore utility notifies you to mount another.