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 <top-level mirror> <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 <alias>`.
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 <top-level mirror> -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