Restoring mksysb

May 2015 | by David Tansley

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:         5.3.12.1
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'

Restoring

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     5.3.12.4    A     F    Network Install Manager –

Confident Footing

Knowing what you can do with your image before a request comes in for a restore should put you on a confident footing.