How To Use Svm Mirrors To Roll Back System Changes.

Solution 213018 : How to use Solaris[TM] Volume Manager/Solstice DiskSuite[TM] mirrors to roll back system changes Description: How to use Solaris[TM] Volume Manager/Solstice DiskSuite[TM] mirrors to roll back system changes. There are many circumstances where major changes are being made to the system, such as a patch cluster install or OS upgrade, when it would be nice to have the option to undo those changes and revert to a previous system state in case something goes wrong. With software volume management and a little preparation, it is possible to keep a temporary copy of the boot disk and roll back to it if needed. The boot disk needs to be mirrored. If it is not mirrored, then consult the Solaris[TM] Volume Manager documentation which is available from http://docs.sun.com to find the boot disk mirroring procedure. Steps to Follow In the examples below, the disk that will be updated is "disk1" and the disk used to mirror it is "disk2". Part I: Preparing the system 1) Any time major system changes are being made it is wise to back up the system to tape, even when we're setting aside a disk copy of the data. 2) Collect the outputs of `metastat -p` and `metadb -i` and set them aside on another system. They won't be used in this procedure, but if the Solaris[TM] Volume Manager configuration needs to be rebuilt due to a complete disaster, these outputs will enable that. 3) Detach all metadevice slices that reside on disk2. Run this command for each mirror metadevice on the boot disk: # metadetach <mirror> <submirror> For example, if d0 is the mirror of your root slice and it contains d1 (on disk1) and d2 (on disk2), you would run `metadetach d0 d2`. If you also have d10, which is a mirror of /var with submirrors d11 and d12, you would also run `metadetach d10 d12`. The metadevices d2 and d12 will be separated from the mirror and will contain the copy of the system in its original state. 4) Proceed with the system changes. Note that if you need to be in single-user mode during this procedure (such as when you install a patch cluster) it is recommended to go all the way down to the ok prompt and then boot back up to single user mode: # init 0 ... ok boot -s If the metadevices that reside on disk1 have to be removed during the course of the system changes, as in the case of a Solaris[TM] upgrade, they will need to be recreated before proceeding. Consult the Solaris Volume Manager documentation for help with this. 5) If the system changes need to be rolled back, skip step 6 and follow the

procedure in Part II of this document. 6) Once the changes are made successfully and it's confirmed that the system will not need to be reverted to its original state, you can re-attach all metadevice slices that reside on disk2: # metattach <submirror> Continuing with the example from step 3, you'd run `metattach d0 d2`. This will re-attach the submirrors that were set aside and propagate your system changes to both sides of the mirror. After this point it's no longer possible to use the mirrors to return to an older system state, so make sure you're ready. Part II: Rolling back changes To roll back to the original system state at any time after step 2 of Part I: 1) If the system is still booted, bring it down to the ok prompt: # init 0 2) Insert the Solaris CD in the CD drive and boot to cdrom: ok boot cdrom -s 3) fsck the filesystems on disk2. Note that the swap partition can't be (and doesn't need to be) fscked. 4) mount the root partition of disk2 to the /a directory. For example, if disk2 is c0t1d0 and root is on slice 0: # mount /dev/dsk/c0t1d0s0 /a 5) Make copies of vfstab and system on the root slice of disk2. # cd /a/etc # cp vfstab vfstab.orig # cp system system.orig 6) In the /a/etc/vfstab file, replace the lines for the system metadevices with the underlying partitions on disk2. You only need to change the lines for root (/) and the other filesystems that reside on the boot disk. For example, change lines from: /dev/md/dsk/d0 /dev/md/rdsk/d0 / ufs 1 no to: /dev/dsk/c0t1d0s0

/dev/rdsk/c0t1d0s0 / ufs 1 no -

7) Edit the /a/etc/system file, and delete the "rootdev" line, which will look similar to this: rootdev:/pseudo/md@0:0,0,blk 8) Unmount disk2 and go back to the ok prompt: # cd /; umount /a # init 0 9) Boot to disk2. If there's an alias set up you can just enter `boot `.

You can use the `devalias` command at the ok prompt to see what device aliases are configured. Otherwise, you'll have to enter the full device path to the device. See Technical Instrustion < Solution: 201868 > (Ultra[TM] Enterprise x000 servers: Using show-disks command to create devalias for disk-board boot-drive) for one way to identify devices at the OBP and set up device aliases. 10) Delete the old top-level mirrors for the boot disk. For example, if d0 used to be mounted as root, d10 used to be mounted as /var, and d30 used to be your swap space, you would do: # metaclear d0 # metaclear d10 # metaclear d30 At this point, you should have a system that's booted from the underlying c#t#d#s# partitions on disk2. You can confirm that by looking at output from `df -k`. If you look at `metastat` output, you should see simple concatenated metadevices for the slices on disk1 and disk2, with no mirrors built on top of them. 11) Recreate the top-level mirrors using the metadevices on disk2: # metainit -m <submirror from disk2> For example, `metainit d0 -m d2`. The `metastat` command should now show that the slice currently mounted as root (c0t1d0s0 in this example) is initialized into a metadevice (d2), and that metadevice is part of a mirror that only has one side (d0). 12) Now you're ready to change vfstab and /etc/system back so that the system will boot from the metadevices containing the original system state. Make copies of the current files, for example `cp /etc/system /etc/system.temp` just in case, and then copy vfstab.orig and system.orig from step 4 back into place as the active vfstab and system files. 13) Reboot the system. # init 6 14) Now you can re-attach the metadevices on disk1 so that the unwanted system changes are wiped out, and the preserved data from disk2 is put in its place. For each mirror that's on the boot disk, you'd run the following: # metattach <mirror> <metadevice from disk1> For example, `metattach d0 d1`. This will start the process of synchronizing the data, and you can monitor the progress via the metastat command. Once that's done, the system should be back in its original state. Product Solstice DiskSuite 4.2.1 Solstice DiskSuite 4.2 Solstice DiskSuite 4.1 Solstice DiskSuite 4.0 Solaris Volume Manager Software