• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

The Geek Diary

CONCEPTS | BASICS | HOWTO

  • OS
    • Linux
    • CentOS/RHEL
    • Solaris
    • Oracle Linux
    • Linux Services
    • VCS
  • Database
    • oracle
    • oracle 12c
    • ASM
    • mysql
    • MariaDB
    • Data Guard
  • DevOps
    • Docker
    • Shell Scripting
  • Interview Questions
  • Big Data
    • Hadoop
    • Cloudera
    • Hortonworks HDP

Solaris Volume Manager (SVM) : How to Use Mirrors to Roll Back System Changes

By admin

There are many circumstances where major changes are being made to the system, such as a patchset 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.

SVM root encapsulation and mirroring [SPARC]

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 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 [top level mirror] [sub mirror]

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 set) it is recommended to go all the way down to the ok prompt and then boot back up to single user mode:

# init 0

Ensure that you boot from disk1 (the active disk in SVM). Do NOT boot from the disk2 which is detached from the SVM mirror!

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 upgrade, they will need to be recreated before proceeding. Consult the mentioned SVM documentation above 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] [sub mirror]

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:

If the system is still booted it is possible to save a reboot and make this procedure faster. If at this point you start with step3 mount and edit the detached mirror of root such that it points to the physical disk devices prior to finding out the system changes failed. This would allow that the system can be booted from from the detached mirror without having to ‘boot net’ or ‘boot cdrom’ to fix up the detached mirror.

1. Otherwise 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

Certainly, it is also possible to boot from network.

3. Run fsck for 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.

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 [sub mirror]

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 [top level mirror] [sub mirror]

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.

Filed Under: Solaris, SVM

Some more articles you might also be interested in …

  1. How to install a ZFS boot block in solaris
  2. Determining which network interface will be used for jumpstart installation / network boot
  3. The ultimate Solaris sendmail troubleshooting guide
  4. How to Collect a Forced Crash Dump of a Hanging Solaris Guest LDom
  5. Solaris (SPARC) : How to create OBP boot device alias at ok prompt
  6. Solaris : How to set limit on the maximum number of open files per process
  7. How to collect XSCF snapshot on M-series servers (M3000 / M4000 / M5000 / M8000 / M9000)
  8. How to find Number of Physical/Logical CPUs, cores and memory in Solaris
  9. How to Use the Oracle Solaris Fast Crash Dump Feature
  10. Solaris ZFS : How to Create and Manage Mirrored Storage Pools

You May Also Like

Primary Sidebar

Recent Posts

  • How to set the default character set in MySQL and how to propagate it in a master-master replication scenario
  • “Connection reset by peer” – error while ssh into a CentOS/RHEL system with a specific user only
  • MySQL: how to figure out which session holds which table level or global read locks
  • Recommended Configuration of the MySQL Performance Schema
  • Archives
  • Contact Us
  • Copyright

© 2021 · The Geek Diary