mksysb works by creating several files on its backup tape, CD, DVD, or image file. The first few files boot the kernel and provide the LVM layout of the data that was backed up. The last files contain the files to be restored in backup format for AIX 4.3.3 and 5.x. (The AIX backup format is essentially the same as dump.) savevg backups are essentially the same except there is no bootable kernel information. Figure 13-1 shows a logical representation of such a tape.

Figure 13-1. A logical representation of a mksysb tape

The tape block size for the first three files is 512 bytes while the block size for the image data is variable, based on the settings of the tape drive at the time of the backup. If you choose 0 as the block size for that device, systems will, when possible, back up with 1024 bytes. When backing up to CD/DVD or image file, it is not necessary to specify a block size.

There are three common types of mksysb backups:

The first two require physical media. Both tape and CD/DVD produce bootable restore and recovery images. Backing up to an NFS mount is limited by the speed of the IP network when doing backups. Restore speed for NIM is limited by the speed of the network as well. Backing up to an NFS share and restoring via NIM is more work to set up but can be automated using scripts to make periodic backups of the rootvg without being dependant on a human to load media.

Another option that some people script is backups to a local disk that is not a member of rootug, and then a script to move them off to a remote host using FTP/SCP/RCP. Most users should avoid doing this. It adds a potentially weak link to your backup strategy. What happens when the copy script fails, and the backup you need is good but physically on a failed machine? A simple restore just got a whole lot harder. If NFS just isn’t an option, and you must use another transfer method, be sure to write solid verification scripts both on the client and the destination server. Whatever you do, don’t ever send your mksysb backups to the rootvg.

If you find yourself in this situation, you can restore from an older mksysb or CD-ROM, apply maintenance-level releases to get to the same level as when the host failed, mount the backup filesystem, and perform a second restore from the desired mksysb.

After you decide where to back up to, you need to decide whether you are going to quiesce the system to take a root backup. Will you log off all users and/or shut down your applications for the duration of the backup? The answer depends on your system configuration. The backup will likely take at least an hour, and any changes to files during the backup may lead to an inconsistent image on tape. There should not be any problems backing up files that are currently open, although any pending writes to the file at the time it is backed up will obviously not make it to the tape archive. If you have most or all of your user data off rootvg, and your system files are not constantly changing, you should have no problem doing mksysb backups on a “live” system.

If you are using this mksysb image to build other systems, you may want to prepare the rootvg even further. For example, you may want to do the following:

Next, decide what needs to be backed up. You can prevent specific files from being backed up to the archive by creating a file called /etc/exclude.rootvg and using the -e flag to mksysb (or savevg). Entries in this file can be simple lists of files, such as:

/etc/passwd

If you use the -e flag, mksysb filters out the files in your /etc/exclude.rootvg using egrep, so in effect, it supports egrep’s syntax. This allows complex entries such as:

.*/core$
^/tmp/
.*.o$

# ls ./bosinst.data ./image.data | backup -ivqf /dev/rfd0

Here is a quick summary of the options of mksysb that I’ll be using in this section:

The simplest scenario is to back up all filesystems in rootvg with a locally attached tape drive. In this situation, issue the following command from a root prompt:

# mksysb -i /dev/rmt0

The difference between the various ways to access a tape device on AIX systems is illustrated in Table 13-1 and explained in detail in the manpages.

This can also be achieved through the System Management Interface Tool (smit) menus, of course, and the following fast path brings you directly to the correct screen:

# smit mksysb

You should be able to use any locally attached tape drive supported by AIX.

You can perform a mksysb directly to a remote tape by following this procedure. For the purpose of this example, consider two machines:

First, make sure the /.rhosts or /etc/hosts.equiv file is set up properly on both machines to allow rsh from the client to the tapeserver. On the tapeserver, use this procedure to manually create a mksysb image:

Now that we have the bootable part of the tape (i.e., the boot block), the installation files, and the dummy table of contents, we need to transfer the data. On the client, run mkszfile , and create a file called /etc/exclude.vg that contains only /tmp/mksysb. pipe. Then, direct mksysb to a named pipe. Finally, cat the contents of the pipe to the tapeserver’s tape drive:

If you are lazy, a script written by Henk van Doorn called rmksysb does all of this.

It is possible to back up a system to a locally attached disk, but that obviously presents challenges during a restore. It’s even possible to back up the rootvg to a file in the rootvg, but that would really be a bad idea for a few different reasons. A common practice is therefore to set up a NFS share on a separate server to hold mksysb backups.

The filesystem must be large-file-enabled, and you must set ulimit to allow 9 GB files (by default, ulimit is set to 1 GB).

To see the current setting of ulimit:

Client # ulimit –f
2097151

The systemwide default setting is configured in /etc/security/limits. You can also change it in a shell using the ulimit command (9 GB plus a little for overhead):

Client # ulimit –f 19000000

Now that we can write out a large file (over 1 GB), we can write a backup of the rootvg to an NFS mount on the client system. In the following examples, we use / NFS_mount/mksysb from the server NFS_Server to hold mksysb backups. We’ll use the command mksysb –e –m /directory/filename. The –e option tells it to exclude patterns listed in / etc/exclude.rootvg, and the –m option specifies the media to write to. The last argument should be the full pathname of the file in which to store the image.

Client # mksysb –e –m /NFS_mount/mksysb/client-6-1-06.msb_image
Creating information file (/image.data) for rootvg..
Creating list of files to back up.
Backing up 39932 files..........#
# 39932 of 39932 files (100%)
0512-038 mksysb: Backup Completed Successfully.

It’s just that easy to make a backup of the rootvg. We now have a backup that we can restore to this host. In the event of a minor problem, we can restore a single file, and in the event of a major problem, we can create a bootable restore DVD or restore using NIM.

Once you create a mksysb image on disk, you can use it to create a set of bootable DVDs or CDs that can be used to restore the system very quickly. This process has three steps:

We are going to need some local scratch space for the first two steps. This scratch space should not be in rootvg and needs to have enough space to hold the temporary CD/DVD filesystem and the CD/DVD ISO images. For each CD, this is about 645 MB, and each DVD holds 4.38 GB. The temporary files can probably be on an NFS directory, but it’s probably best if the ISO images are stored locally to prevent buffering problems when creating the DVDs or CDs.

We’ll use the following arguments to the mkcd command to perform this task:

In the following examples, the host named NFS_Server has a DVD writer. It also has a local 18 GB filesystem called /mkcd that we use for both the temporary images as well as the ISO images. NFS_Server also shares the filesystem /NFS_Share/mksysb with other clients so they can write their mksysb backups there. (This is the same directory we backed up to in the previous example.)

The example that follows uses the NFS server to create a bootable CD image from the mksysb image we created on the NFS mount in the previous example (/NFS_share/mksysb/client-6-1-06.msb_image). We use the directory /mkcd/cd_fs to hold the temporary images and the directory /mkcd/cd_images to hold the final ISO images.

NFS_Server # mkcd -m /NFS_share/mksysb/client-6-1-06.msb_image -C /mkcd/cd_fs
-I /mkcd/cd_images -R –S
Initializing mkcd log: /var/adm/ras/mkcd.log...
Verifying command parameters...
Populating the CD or DVD file system...
Copying backup to the CD or DVD file system...
.
Building chrp boot image...
Creating Rock Ridge format image: /mkcd/cd_images/cd_image_295108.vol1
Running mkisofs ...
.
mkrr_fs was successful.

Making the CD or DVD image bootable...

Copying the remainder of the backup to the CD or DVD file system...
Creating Rock Ridge format image: /mkcd/cd_images/cd_image_295108.vol2
Running mkisofs ...
.
mkrr_fs was successful.


Copying the remainder of the backup to the CD or DVD file system...
Creating Rock Ridge format image: /mkcd/cd_images/cd_image_295108.vol3
Running mkisofs ...
.
mkrr_fs was successful.

This gives us three ISO CD images in /mkcd/cd_images. The temporary data that was copied to /mkcd/cd_fs was removed after the cd image was created. We can now transfer that image to another server with a CD drive and burn the .ISO images.

If we want to create a DVD image, we add the –L flag to the command:

NFS_Server # mkcd –L -m /NFS_share/mksysb/client-6-1-06.msb_image 
-C /mkcd/cd_fs -I /mkcd/cd_images -R –S
Initializing mkcd log: /var/adm/ras/mkcd.log...
Verifying command parameters...
Populating the CD or DVD file system...
Copying backup to the CD or DVD file system...
.......
Building chrp boot image...
Creating Rock Ridge format image: /mkcd/cd_images/cd_image_405642
Running mkisofs ...
........
mkrr_fs was successful.

Making the CD or DVD image bootable...

Our earlier example created three ISO images of CD size, but in this example, we specified the –L flag, so we have one large DVD ISO image. You can use these ISO images to create a CD or DVD on any host.

If you want to create the images and burn the CD/DVD all in one step, you can drop the –S and –R options and add the –d option, followed by the device name of the CD/DVD burner:

NFS_Server # mkcd –d /dev/cd0 –e -m /NFS_share/mksysb/client-6-1-06.msb_image -C /mkcd/cd_fs -I /mkcd/cd_images

If you want to burn a CD from an ISO image created earlier, use a command like this:

NFS_Server # burn_cd /dev/cd0 /NFS_share/mksysb/client-6-1-06.msb_image

If there is more than one CD image file, repeat the command for each image file.

If you want to burn a DVD from an ISO image, add the –d flag:

NFS_Server # burn_cd –d /dev/cd0 /NFS_share/mksysb/client-6-1-06.msb_image

If you are lucky enough to have a CD/DVD writer available on the system you want to make DVDs for and have sufficient local scratch space to build a CD image, you can use mkcd to create the CD/DVD in one step. Although all of the steps in the previous method are still required and performed, mkcd manages and automates the whole process, from making the mksysb backup all the way to burning the actual DVDs/CDs. In the following example, we want to make a bootable DVD-sized backup of the rootvg with map files (restore LVM), excluding all files and directives in /etc/exclude.rootvg:

NFS_Server # mkcd -L -P –e –M /NFS_Share/mksysb –C /mkcd/cd_fs 
–I /mkcd/cd_images -R –S
Initializing mkcd log: /var/adm/ras/mkcd.log...
Verifying command parameters...
Creating image.data file...
Creating mksysb image...

Creating list of files to back up.
Backing up 39945 files...............
39945 of 39945 files (100%)
0512-038 mksysb: Backup Completed Successfully.
Populating the CD or DVD file system...
Copying backup to the CD or DVD file system...
.......
Building chrp boot image...
Creating Rock Ridge format image: /mkcd/cd_images/cd_image_323664
Running mkisofs ...
....
mkrr_fs was successful.

Making the CD or DVD image bootable...
NFS_Server #

This command performs a mksysb of the rootvg and from that makes a bootable DVD ISO image in /mkcd/cd_images called cd_image_323664. You can either transfer that image to another system (including a PC with a DVD burner) and make a DVD from it, or make a DVD on the local system using the –d device argument to mkcd. If you want to make CD images, just issue the same command without the –L flag. It then produces multiple CD images if the backup is larger than one CD.

The purpose of the NIM server is to provide a boot image to the client over the network using BOOTP and TFTP. In our case, we want to boot and install a mksysb that we have previously created.

The easiest way to set up NIM is to use the eznim wizard introduced in AIX 5.2:

NIM_Server # smit eznim

For versions before 5.2, there is the regular smit panel for NIM, which has a setup option:

NIM_Server # smit nim

Setting up NIM through the smit panels is the easiest and most thorough method. If you choose to install it using the command-line interface (CLI), read the manpage for nim_master_setup for any options to specify relative to your environment. The following instructions create a quick and easy CLI setup:

This step adds the host that we want to back up to the NIM server. We need to do this so that the NIM server knows who to serve images to.

The easiest way to add a client is to use the smit fastpath:

NIM_Server # smit nim_mkmac

It can also be installed and set up using CLI. The following instructions apply to a typical client. Both the client and server need to be able to resolve each other via DNS. The example’s hostname is client, and it has a chrp mp architecture that uses twisted pair. For a more detailed usage of the CLI, see the manpage for the niminit command. We run the niminit command from the client, not the server. This has the added benefit of making sure that the client can talk to the NIM server.

client # niminit -a name=client -a master=NIM_server -a pif_name=en0 
-a platform=chrp -a netboot_kernel=mp -a cable_type1=tp

Now that we have defined a client, we can select the installation type. This tells the NIM server which image the client should install.

The easiest way to select which mksysb to have a client boot is to use the smit fastpath. To do this, select mksysb as the image resource and set the location:

client # smit update_client_eznim

In the smit panel, select the installation type “mksysb - Install from a mksysb,” and set that to the mksysb image that you want to restore.

This can also be set up using CLI. Again, for a more detailed usage of CLI, see the manpage for the nim command. In this example, we want the host we are on (client) to NIM boot from NIM_Server using the mksysb file /export/backups/client-6-1-06.msb_image. We also assign a resource name of mksysb_res1 to client-6-1-06.msb_image:

client # nim -o define -t mksysb -a server=NIM_Server –a location=/export/backups/ client-6-1-06.msb_image mksysb_res1

In this example, we back up datavg to an NFS share:

Client # mount NFS_Server:/NFS_mount/savevg /NFS_mount/savevg
Client # savevg –e –m –f /NFS_mount/savevg/client-datavg-6-1-06.svg_image datavg
Creating information file for volume group datavg.

Creating list of files to back up.
Backing up 13 files
13 of 13 files (100%)
0512-038 savevg: Backup Completed Successfully.

The 4.x versions of AIX require special attention because not all the drivers are installed with the BOS. In this case, you are left with two choices:

In AIX 5.x, all device drivers and supported kernels are installed with the BOS. This means that a system backup should be largely hardware-independent. However, there are issues when backing up older 32-bit systems. A system backup of a 32-bit AIX system running in 32-bit mode will still run in the same 32-bit mode if installed onto 64-bit hardware. A backup of a 64-bit system will not run on a 32-bit system because 32-bit hardware cannot run 64-bit software. To change system modes between 32 and 64 bits, see the IBM systems operation guide for the version of AIX you are running.

You should edit the bosinst.data file to set the RECOVER_DEVICES variable. This specifies whether or not to restore the ODM definitions that were in place at the time of the backup. Since this backup may be restored onto a machine with very different hardware, let AIX rebuild its own ODM definitions at boot.

If you make a bootable CD/DVD on a different platform, you must add the –G flag to mkcd. This forces it to include the chrp, rs6k, and rspc boot images on the CD.