Using ZFS clones to simplify upgrades


One cool ZFS feature that was introduced in Solaris 10 11/06 is the ability to clone a file system. This is a truly powerful tool, since it allows admins to create copies of file systems prior to performing upgrades, and a way to roll a file system back to a previous state (this provides a simple lightweight method to back out changes if upgrades go awry). To illustrated just how useful this is, let’s create a clone of the file system oradata. To clone oradata, we first need to take a sapshot of the oradata file system:

$ zfs snapshot striped/oradata@ordata_snap

Once a snapshot is created, the zfs utilities’ “clone” option can be used to create a clone of the file system from the snaphost we just created:

$ zfs clone striped/oradata@ordata_snap striped/oradata_clone

After the clone is created, it can be “promoted” to a file system with the zfs utilities’ “promote” option:

$ zfs promote striped/oradata_clone

If everything works correctly (which it should), the clone and the file system the clone was created from will appear in the df output:

$ df -h

Filesystem size used avail capacity Mounted on
/dev/dsk/c0d0s0 17G 2.9G 14G 18% /
/devices 0K 0K 0K 0% /devices
/dev 0K 0K 0K 0% /dev
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 1016M 768K 1015M 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
/usr/lib/libc/libc_hwcap1.so.1
17G 2.9G 14G 18% /lib/libc.so.1
fd 0K 0K 0K 0% /dev/fd
swap 1015M 0K 1015M 0% /tmp
swap 1015M 24K 1015M 1% /var/run
striped 52G 27K 50G 1% /striped
striped/oradata 52G 300M 50G 1% /striped/oradata
striped/oradata_clone
52G 300M 50G 1% /striped/oradata_clone

Now let’s pretend that a DBA accidentally deletes the Oracle datafiles in /striped/oradata:

$ rm -f /striped/oradata/

Oops! Since oradata_clone is a clone of the oradata file system, we can restore oradata by first deleting the original file system (you could also rename it if you wanted to keep it around):

$ zfs destroy -f striped/oradata

And then renaming the clone to take it’s place:

$ zfs rename striped/oradata_clone striped/oradata

Once the rename occurs, everything is as it once was:

$ df -h

Filesystem size used avail capacity Mounted on
/dev/dsk/c0d0s0 17G 2.9G 14G 18% /
/devices 0K 0K 0K 0% /devices
/dev 0K 0K 0K 0% /dev
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 1015M 768K 1014M 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
/usr/lib/libc/libc_hwcap1.so.1
17G 2.9G 14G 18% /lib/libc.so.1
fd 0K 0K 0K 0% /dev/fd
swap 1014M 0K 1014M 0% /tmp
swap 1014M 24K 1014M 1% /var/run
striped 52G 26K 50G 1% /striped
striped/oradata 52G 300M 50G 1% /striped/oradata

$ ls -la /striped/oradata

total 614555
drwxr-xr-x 2 root sys 5 Dec 24 11:49 .
drwxr-xr-x 3 root sys 3 Dec 24 11:59 ..
-rw-r--r-- 1 root root 104857600 Dec 24 11:47 iklts01.dbf
-rw-r--r-- 1 root root 104857600 Dec 24 11:48 iklts02.dbf
-rw-r--r-- 1 root root 104857600 Dec 24 11:49 iklts03.dbf

This has so many uses, and once ZFS boot is incorporated, using clones to protect yourself from rogue patches will be one of the coolest things ever! Shibby!

This article was posted by Matty on 2006-12-29 16:34:00 -0400 -0400