If you’ve started to play with OpenSolaris you might have noticed that one of our constant concerns is turning your beloved development workstation into a brick. Brickification, or the result of a bad BFU (upgrade), can be painful. You have to remember that OpenSolaris is in fact the OS/Net conslidation of Solaris (and we call the Solaris 11 codebase we all now use Nevada, hence ONNV or OS/Net Nevada - thats OpenSolaris) is not simply the kernel like Linux but the whole base OS, from LibC to the tools, to the kernel, to the modules. On Linux if you build a bad kernel, no problem, reboot and select a diffrent kernel from GRUB or LILO and figure out what went wrong, but even on Linux if you jack up GNU LibC or the base toolset your gonna be reaching for a rescue or install CD. So when you upgrade a complete OpenSolaris system a lot is at stake. For the record, you can infact install only a kernel using the Install (pronounced Cap-Eye-Install) tool, but thats not nearly as much fun as upgrading the whole system via BFU. So, what we need is a way to protect our investment of time and effort. On Solaris we have two amazingly kick ass tools to help us solve this problem, and they become more important than ever in OpenSolaris development: Live Upgrade and Flash Archives.
I’ve actually written a paper on OpenSolaris development that covers both, but I haven’t completed it yet and don’t have time, so I’ll blog it in request to several folks who are curious about it. I’d like to extend a hearty thank you to Mr. John S. Howard who is no longer with Sun (who ever decided that was a dipshit), who is the unquestioned Jumpstart, Live Upgrade, Flash Archive god of Solaris. John, you rule.
Live Upgrade (LU) and Flash Archive (Flar) are both essentially big ass wrapper around CPIO, and neither do anything that seems particuarly unusual at first look, they are both definately “Ya, of course!” tools, but the point is that no one else does it, at least not as well as they do.
Live Upgrade allows you to create a copy of your root disk onto another disk in the system, and then (the Live bit) upgrade that copy (which we call an Alternate Boot Enviroment, or ABE). When you finish patching or upgrading the ABE you simply activate the ABE and reboot into it. In this way you can do time consuming (a complete recommended patch cluster on Solaris9 for instance can take 3-4 hours to install) upgrades to Solaris without incurring any more downtime than it takes to reboot.
Flash Archives on the other hand are root disk images. You create a flash archive using the “flar” tool, which will output a single file containing your system image. We can use these system images in a variety of ways to provide a robust imaging and snapshot/backup solution. The reason Flash Archives are so much more polished than other solutions is the fact that when you run the Solaris Installer (from CD usually) you’ll notice you actually are given 3 (or more) install options: Install, Upgrade, or Flash. When we create a Flash Archive we can store it on either an NFS, FTP or HTTP server and then access it again via a CD installer, as well as the fact that we can also use these archives via both JumpStart and Live Upgrade! When archives are installed onto a system they are done with the networking unconfigured (just like a sys-unconfig’ed system) making them great for imaging, just get a Solaris install how you like it, create the archive, then JumpStart install the archive onto your pool of servers, effortless rollouts!
For our purposes we’re interested in simply creating point in time snapshots of our system. Flash Archives indeed could be cron’ed and made to act as a nightly backup solution, but there are certainly better tools for doing that. When you feel you’ve got your box the way you like you can use “flarcreate” to create a Flash Archive, which we can store in some place accessable via NFS, FTP or HTTP. If for some reason we destroy or extensively damage our installation for some reason we can just pop in the Install CD, enter the networking information and point the installer to the archive… minutes later we’re booting back into our system. Every time I feel I’ve significantly improved or upgraded a system I cut an archive just in case.
Creating Flash Archives is easy. NFS provides the best method for archive storage, imho, so mount an NFS share locally, I prefer to mount to /flash. Then run run “flar create” with the appropriate arguments like this:
$ flarcreate -n "Monolyth B16 Snapshot" -a "benr@cuddletech.com"> \
-S -R / -x /flash /flash/Monolyth-Snapshot-`date '+%m-%d-%y'`.flar
So, looking at the arguments:
- -n adds a description to the archive (this is displayed during installation later)
- -a adds a string containing conact information
- -S tells flarcreate to skip its size checks, normally it will estimate the size of the archive prior to creating it, which can take a really really long time, this argument just lets us speed up the process
- -R specifies the root directory, by default its /, but I often supply it for completeness.
- -x specifies a directory to exclude from the archive, supply one -x per directory to exclude (ie: -x /opt -x /export). NFS mounted filesystems are excluded by default, but again for completeness I tend to put them in there anyway.
- (archivename).flar is the actual name of the output archive file. You can name it whatever you want, but typically its wise to put the hostname, archive creation date, and a .flar extention in the filename just to help identify it. The filename should be a absolute pathname, so since we’ve mounted our NFS archive repository to /flash, we’ll specify that path.
If your not using NFS then you should create a directory to put the archive in and be sure to exclude (-x) that directory during creation before you move it to your FTP or HTTP server.
As you can see, Flash Archives are quick and easy methods of creation snapshot backups of your system. I used one just this morning! I needed a bigger IDE harddrive in Monolyth, so I created an archive last night before I left the office, then this morning I shutdown, pulled the old drive completely and put in the new one, booted the installation CD (Solaris Express: Community Release in this case), setup networking, partitioned the new drive, and then installed from my NFS archive, all from the graphical installer. An hour later the copy completed and the system rebooted. I didn’t know anything had changed! I logged in and got back to work. Absolutely painless and I’ve got a faster disk with 70GB more space! 
So, in the future as you play with OpenSolaris (or Solaris) and for whatever reason think that the system is good as it is, but you might want to reinstall it, or you want to see what rm -rf / does or whatever, don’t worry, don’t pull the drive and put it aside or mess with tapes, just create a Flash Archive and know that if you need to get back to where you were its only a quick install a way. Enjoy.
For more information check out:
