Solaris Volume Manager Administration Guide

Using a RAID 1 Volume to Back Up Data

Although Solaris Volume Manager is not meant to be a “backup product,” it does provide a means for backing up mirrored data without unmounting the mirror or taking the entire mirror offline, and without halting the system or denying users access to data. This process happens as follows: one of the submirrors is detached, temporarily losing the mirroring, and backed up. That submirror is then reattached and resynchronized as soon as the backup is complete.

The UFS Snapshots feature provides the ability to take a backup of a system without taking the file system offline, and without needing to detach a submirror and incur the performance penalty of resynchronizing the mirror later. See Chapter 24, Using UFS Snapshots (Tasks), in System Administration Guide: Devices and File Systems for more information.

ProcedureHow to Use a RAID 1 Volume to Make an Online Backup

You can use this procedure on any file system except root (/). Be aware that this type of backup creates a “snapshot” of an active file system. Depending on how the file system is being used when it is write-locked, some files and file content on the backup might not correspond to the actual files on disk.

The following limitations apply to this procedure:

The high-level steps in this procedure are as follows:

Note –

If you use these procedures regularly, put them into a script for ease of use.

Tip –

The safer approach to this process is to attach a third or fourth submirror to the mirror, allow it to resync, and use it for the backup. This technique ensures that data redundancy is maintained at all times.

  1. Run the metastat command to make sure the mirror is in the “Okay” state.

    A mirror that is in the “Maintenance” state should be repaired first.

  2. Flush data and UFS logging data from cache to disk and write-lock the file system.

    # /usr/sbin/lockfs -w mount point 

    Only a UFS volume needs to be write-locked. If the volume is set up as a raw device for database management software or some other application, running lockfs is not necessary. (You might, however, want to run the appropriate vendor-supplied utility to flush any buffers and lock access.)

    Caution – Caution –

    Write-locking root (/) causes the system to hang, so it should never be performed. If you are backing up your root file system, skip this step.

  3. Detach one submirror from the mirror.

    # metadetach mirror submirror 

    In this command:


    Is the volume name of the mirror.


    Is the volume name of the submirror (volume) being detached.

    Reads will continue to be made from the other submirror. The mirror will be out of sync as soon as the first write is made. This inconsistency is corrected when the detached submirror is reattached in Step 7.

  4. Unlock the file system and allow writes to continue.

    # /usr/sbin/lockfs -u mount-point 

    You might need to perform necessary unlocking procedures based on vendor-dependent utilities used in Step 2 above.

  5. Use the fsck command to check the file system on the detached submirror to ensure a clean backup.

    # fsck /dev/md/rdsk/name
  6. Perform a backup of the offlined submirror.

    Use the ufsdump command or your usual backup utility.

    Note –

    To ensure a proper backup, use the raw volume, for example, /dev/md/rdsk/d4. Using “rdsk” allows greater than 2 Gbyte access.

  7. Attach the submirror.

    # metattach mirror submirror

    Solaris Volume Manager automatically begins resynchronizing the submirror with the mirror.

Example 11–22 Using a Mirror to Make an Online Backup

This example uses a mirror named d1, consisting of submirrors d2, d3 and d4. The submirror d3 is detached and backed up while submirrors d2 and d4 stay online. The file system on the mirror is /home1.

# /usr/sbin/lockfs -w /home1
# metadetach d1 d3
# /usr/sbin/lockfs -u /home1
# /usr/sbin/fsck /dev/md/rdsk/d3
(Perform backup using /dev/md/rdsk/d3)
# metattach d1 d3