Example--Unmirroring root (/)
# metadetach d0 d20 d0: submirror d20 is detached # metaroot /dev/dsk/c0t3d0s0 # reboot ... # metaclear -r d0 d0: Mirror is cleared d10: Concat/Stripe is cleared # metaclear d20 d20: Concat/Stripe is cleared |
In this example, root (/) is a two-way mirror named d0; its submirrors are d10 and d20, which are made of slices /dev/dsk/c0t3d0s0 and /dev/dsk/c1t3d0s0, respectively. The metastat command verifies that at least one submirror is in the "Okay" state. (A mirror with no submirrors in the "Okay" state must first be repaired.) Submirror d20 is detached to make d0 a one-way mirror. The metaroot command is then run, using the rootslice from which the system is going to boot. This command edits the /etc/system and /etc/vfstab files to remove information that specifies the mirroring of root (/). After a reboot, the metaclear -r command deletes the mirror and the other submirror, d10. The last metaclear command clears submirror d20.
Example--Unmirroring swap
# metastat d1
d1: Mirror
Submirror 0: d11
State: Okay
Submirror 1: d21
State: Okay
...
# metadetach d1 d21
d1: submirror d21 is detached
(Edit the /etc/vfstab file to change the entry for swap from
metadevice to slice name)
# reboot
...
# metaclear -r d1
d1: Mirror is cleared
d11: Concat/Stripe is cleared
# metaclear d21
d21: Concat/stripe is cleared
|
In this example, swap is made of a two-way mirror named d1; its submirrors are d11 and d21, which are made of slices /dev/dsk/c0t3d0s1 and /dev/dsk/c1t3d0s1, respectively. The metastat command verifies that at least one submirror is in the "Okay" state. (A mirror with no submirrors in the "Okay" state must first be repaired.) Submirror d21 is detached to make d1 a one-way mirror. Next, the /etc/vfstab file must be edited to change the entry for swap to reference the slice that is in submirror d21. For example, if d1 was the mirror, and d21 the submirror containing slice /dev/dsk/c0t3d0s1, the following line:
/dev/md/dsk/d1 - - swap - no - |
should be changed to:
/dev/dsk/c0t3d0s1 - - swap - no - |
After a reboot, the metaclear -r command deletes the mirror and the other submirror, d11. The final metaclear command clears submirror d21.
Using a Mirror 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 taken offline, temporarily losing the mirroring, and backed up. That submirror is then placed online and resynchronized as soon as the backup is complete.
How 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:
If you use this procedure on a two-way mirror, be aware that data redundancy is lost while one submirror is offline for backup. A three-way mirror does not have this problem.
There is some overhead on the system when the offlined submirror is brought back online after the backup is complete.
The high-level steps in this procedure are as follows:
Write-locking the file system (UFS only). Do not lock root (/).
Using the metaoffline command to take one submirror offline from the mirror
Unlocking the file system
Backing up the data on the offlined submirror
Using the metaonline command to place the offlined submirror back online
Note - If you use these procedures regularly, put them into a script for ease of use.
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.
For all file systems except root (/), lock the file system from writes.
# /usr/sbin/lockfs -w mount point
Only a UFS 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 - Write-locking root (/) causes the system
to hang, so it should never be performed.Take one submirror offline from the mirror.
# metaoffline mirror submirror
In this command:
mirror Is the volume name of the mirror.
submirror Is the volume name of the submirror (volume) being taken offline.
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 offlined submirror is brought back online in Step 6.
There is no need to run the fsck command on the offlined file system.
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.
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.
Place the submirror back online.
# metaonline mirror submirror
Solaris Volume Manager automatically begins resynchronizing the submirror with the mirror.