Knowing what you can do with your mksysb image before a request comes in for a restore should put you on a confident footing.
Every week, most AIX administrators take a weekly mksysb backup of rootvg. When it completes without problem, they generally shove it off to tape and forget about it. No need to worry, right? Well, you may want to give it a little more thought. Suppose you need to restore some files or directories from the image, perhaps due to file corruption or someone accidently removing some files in rootvg. (Let’s ignore a full restore scenario here.) It’s best to get accustomed with the procedure up front rather than wait until you get that urgent call.
So in this article, let’s look at a typical mksysb image on disk, accessed from the mksysb command line or via NIM. The image I’ll be using in these examples is called uk01wrs6008.mksysb
First, how do you verify an image is good? There’s no straight answer to this, as there is no verify option for an image placed on disk. What I normally do is check the header or do a partial list on the image, or check the backup log contained within the image, so let’s look at those first. These procedures do provide some interesting information about the backup.
Check the Header and Log History
Look at the header of the image with:
# lsmksysb -lf uk01wrs6008.mksysb VOLUME GROUP: rootvg BACKUP DATE/TIME: Fri Apr 10 13:45:03 BST 2015 UNAME INFO: AIX uk01wrs6008 3 5 00CD94A64C00 BACKUP OSLEVEL: 22.214.171.124 MAINTENANCE LEVEL: 5300-12 BACKUP SIZE (MB): 87424 SHRINK SIZE (MB): 60695 VG DATA ONLY: no rootvg: LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT hd5 boot 1 1 1 closed/syncd N/A hd8 jfs2log 1 1 1 open/syncd N/A hd6 paging 171 171 1 open/syncd N/A hd4 jfs2 8 8 1 open/syncd / hd10opt jfs2 164 164 1 open/syncd /opt …. ….
This output has been truncated, but we see it displays the layout of rootvg. But more importantly we can tell the source of the mksysb image even if the actual filename isn’t descriptive. Note the UNAMEINFO; this is the source of the image. The number at the end is the machine serial number. The output also shows the current AIX level as well as the backup timestamp. For the BACKUP SIZE, this is the total of all filesystems (in rootvg), which will also include unused space.
The image also holds the previous backups of the host. This can be shown with:
# lsmksysb -B uk01wrs6008.mksysb #Device;Command;Date;Shrink Size;Full Size;Maintenance Level /hold/mksysb_53;"mksysb -e -i /hold/mksysb_53";Thu Feb 26 13:48:48 GMT 2015;84115;105856;5300-08 /hold/uk01wrs6008.mksysb;"mksysb -eiX /hold/uk01wrs6008.mksysb";Fri Apr 10 13:35:17 BST 2015;60695;87424;5300-12 /hold/uk01wrs6008.mksysb;"mksysb -eiX /hold/uk01wrs6008.mksysb";Fri Apr 10 13:49:04 BST 2015;60695;87424;5300-12
Here the output is in semicolon format, so easy to extract information when used with shell scripts. Note we have the full path of the image, the parameters parsed and the date. So in the last entry of the log we can deduce:
- The fullname of the image is /hold/uk01wrs6008.mksysb
- The parameters passed were eiX, which means use the exclude file, generate new image.dat file, expand /tmp if needed
- The backup was taken on Fri April 10
- The shrink size
- The total size and maintenance level
That’s pretty good information extracted. AIX is great at producing this type of information.
Searching for Files in the Image
To get a full listing of the image—that is, all the files that were backed up—use:
# lsmksysb -f uk01wrs6008.mksysb
However, you’ll more than likely want to search for a specific filename or to pattern match a range of files to see if they’re present in the image. Just use grep using the previous command. Here, I search for my mail file, dxtans, which is installed in /var/spool/mail:
# lsmksysb -f uk01wrs6008.mksysb |grep "/var/spool/mail/dxtans" New volume on uk01wrs6008.mksysb: Cluster size is 51200 bytes (100 blocks). The volume number is 1. The backup date is: Fri Apr 10 13:45:31 BST 2015 Files are backed up by name. The user is dxtans. 1410 ./var/spool/mail/dxtans The number of archived files is 100334.
The output shows it’s found the file. Note the output of the path starts with a dot. This means it’s stored relative. This is useful when restoring files, so you can restore it to a temp area first, without overwriting the original. Of course, if you’re restoring to replace missing files, then that doesn’t matter so much. If this is the case, then ensure you cd to the root directory (cd /) to make sure the restored files go to the original place.
To find multiple files on the image (for instance, to see all files that have installp or hostid in their filename), you can use egrep, like so:
lsmksysb -f /hold/uk01wrs6008.mksysb | egrep 'installp|hostid'
Now let’s restore the aforementioned mail file. You can use a couple of commands to restore from an image. In this example, we’ll use the lsmksysb and the restorevgfiles commands.
With the restorevgfiles command, note we give it the full pathname to restore.
# pwd /hold # restorevgfiles -f uk01wrs6008.mksysb ./var/spool/mail/dxtans New volume on uk01wrs6008.mksysb: Cluster size is 51200 bytes (100 blocks). The volume number is 1. The backup date is: Fri Apr 10 13:45:31 BST 2015 Files are backed up by name. The user is dxtans. x 1410 ./var/spool/mail/dxtans The total size is 1410 bytes. The number of restored files is 1.
The restore is completed; it’s a very quick operation as we are restoring a file from an image on disk. The file was restored relatively, so as the command was executed in:/hold. The resulting file, dxtans, will be in:
# cd var/spool/mail # pwd /hold/var/spool/mail # ls dxtans
Restoring a directory is the same procedure as restoring a file.
If you a have a few files to restore, you can parse it on the command line. In this example, let’s use the lsmksyb command with the ‘r’ parameter. To restore the files, /etc/resolv.conf and /etc/hosts, we could use:
# lsmksysb -f uk01wrs6008.mksysb -r './etc/resolv.conf ./etc/hosts' New volume on uk01wrs6008.mksysb: Cluster size is 51200 bytes (100 blocks). The volume number is 1. The backup date is: Fri Apr 10 13:45:31 BST 2015 Files are backed up by name. The user is dxtans. x 2165 ./etc/hosts x 158 ./etc/resolv.conf The total size is 2323 bytes. The number of restored files is 2.
Of course this is all well and it works, but for better efficiency, it would be good to put all the files you want to restore into a file. I always find this risks fewer typos.
So assume we wish to restore three files. Let’s put the full pathname of them into a file, like so:
# cat filedt ./var/spool/mail/dxtans ./etc/hosts ./etc/resolv.conf
Now we can invoke the lsmksysb command to restore them, using command substitution (back ticks), so the contents of the file gets evaluated when lsmksysb gets executed:
# lsmksysb -f uk01wrs6008.mksysb -r `cat filedt` New volume on uk01wrs6008.mksysb: Cluster size is 51200 bytes (100 blocks). The volume number is 1. The backup date is: Fri Apr 10 13:45:31 BST 2015 Files are backed up by name. The user is dxtans. x 1410 ./var/spool/mail/dxtans x 2165 ./etc/hosts x 158 ./etc/resolv.conf The total size is 3733 bytes. The number of restored files is 3.
The files are now restored.
To finish, if you need to know what filesets were backed up on the image (for example, to see if the nim client fileset was installed on the system when the image was taken), use:
# lsmksysb -Lf uk01wrs6008.mksysb |grep nim bos.sysmgt.nim.client 126.96.36.199 A F Network Install Manager –
Knowing what you can do with your image before a request comes in for a restore should put you on a confident footing.
David Tansley is a freelance writer. He has 15 years experience as a UNIX administrator, using AIX the last eight years.
See more by David Tansley