Section 13.1. IBM s mksysb and savevg Utilities


13.1. IBM's mksysb and savevg Utilities

The basis for a bare-metal recovery of an AIX system is the mksysb utility, which is included in AIX. It backs up all the files in the root volume group. mksysb backs up the rootvg, including:

  • Boot files

  • Base operating system (BOS)

  • System and configuration files in the rootvg

  • Additional software installed in the rootvg

It also backs up:

  • rootvg volume group information

  • Logical volume information

  • Paging space information

It does not consume space in the backup to save the paging space; it recreates it on a restore. mksysb is primarily useful for a bare-metal recovery. It also has limitations that may prevent it from becoming your only backup solution. Here are some of those limitations:

  • It cannot back up filesystems on something other than rootvg (see savevg)

  • It cannot back up raw logical devices

  • It has a limited ability to preserve logical volume layout (AIX 4.x)

  • It has restrictions restoring across different RS/6000 architectures (see the later section "System Cloning")

  • It cannot track backups or perform incremental backups

  • It does not have tape robot controls

  • It can back up to a remotely attached tape drive but cannot remotely boot from it

Before AIX 5.x, there were significant differences in the mksysb program from one version to the next. As of AIX 5.x, mksysb is more stable. All AIX 5.x versions can preserve logical volume characteristics and paging space size. mksysb does not back up raw logical volumes. It cannot back up anything other than the root volume group.

mksysb can also be a good solution if you need to make occasional tape backups of your system in case of disk failure. It also can make an excellent companion to other backup programs that handle your application and user data, and provide things that mksysb cannot, such as incremental backups and remote restores. mksysb is not a good solution for environments that are using raw logical volumes; have data outside rootvg; or need to do incremental backups, flexible restores, and backups across the network.

You should always make backups before and after applying IBM maintenance-level upgrades. Maintenance-level upgrades with patches for JFS and JFS2 may not be backward-compatible. So without current and older backups, you run the risk of not being able to mount your filesystems.

Versions 4.3.3 and 5.x of AIX include a utility called savevg , which is actually a link to the mksysb command. When invoked this way, you can back up any volume group on your system, but the other mksysb constraints still apply.

Here are other requirements of the savevg command:

  • Volumes backed up using the savevg command must be varied on and have their filesystems mounted.

  • savevg cannot back up remotely mounted NFS and CIFS filesystems.

  • Filesystems must be of type JFS or JFS2.

mksysb and savevg can back up to different types of media:

  • Tape (bootable in the case of rootvg)

  • CD/DVD (bootable in the case of rootvg)

  • Image file on NFS mount

mksysb and savevg can be restored from:

  • Tape (bootable in the case of rootvg)

  • CD/DVD (bootable in the case of rootvg)

  • Internal disk (not recommended for rootvg)

  • NFS mount (bootable when used with a NIM server)

13.1.1. mksysb and savevg Format

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.

13.1.2. Preparing to Use mksysb and savevg

There are three common types of mksysb backups:

  • Backing up and restoring from a tape drive

  • Creating a bootable CD/DVD

  • Backing up to an NFS mount and restoring via NIM

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:

  • Clear out /tmp.

  • Disable the network (by commenting out from inittab, rc.net, rc.tcpip, and rc.nfs anything that hangs the computer if it has no network or causes an IP address conflict).

  • Remove the root password or set it to a well known password in your environment.

  • Clear the error report using errclear, and clear /var/spool, /var/adm, /var/logs, and the like.

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$

13.1.2.1. Preparing for the restore

The /image.data file in the / filesystem being backed up contains information about how disks, filesystems, logical volumes, and paging space are rebuilt when the backup is restored. In general, the entries in image.data correlate to flags in the mklv and crfs commands (commands used to create logical volumes and filesystems). Running the mkszfile command before the mksysb creates the image.data file itself. You also can start mksysb with the -i option, which tells mkszfile to generate the image.data file automatically. Running mkszfile independently enables you to edit image.data and change what is backed up, the size of the filesystems, and other variables. You also can edit bosinst.data to customize what runs after the image is restored. If you run mkszfile and edit image.data, make sure you run mksysb without the -i option, or your modifications will be overwritten.

One useful option to edit in bosinst.data is the RECOVER_DEVICES variable. This specifies whether or not to restore the ODM definitions that were in place at the time of the backup. The default (YES) is correct if you plan to restore to the same or similar hardware. If you are performing a backup for a generic system image, set it to NO.

If you specify the -m option to mkszfile, a map file is created for each logical volume in the archive. Each map describes where on the disk the logical volume should be created at restore time. This is similar to the options available to the mklv command (exact layout ability). The map file for a given logical volume contains one line for each physical partition (PP) it occupies, along with the hard disk (hdisk) it is on. Note that this is useful only if the target system has exactly the same disk layout as the source system.

Here is an example of what the image.data file contains. The AIX documentation gives a more complete description of all the options contained in this file.


[SHRINK = yes]

Shrinks the filesystems on restore


[VG_SOURCE_DISK_LIST = hdisk0]

Changes the target disk for the restore

Once backed up, these files cannot be edited on tape or CD/DVD media. You can, however, create a customized diskette containing an image.data and/or bosinst.data file. The diskette could be used at restore time instead of the files in the backup. To create a customized diskette, follow this simple procedure.

Edit image.data and/or bosinst.data extracted from a tape or other media (see the instructions for extracting a single file from a mksysb tape), place a diskette in the drive, and issue the following command:

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




Backup & Recovery
Backup & Recovery: Inexpensive Backup Solutions for Open Systems
ISBN: 0596102461
EAN: 2147483647
Year: 2006
Pages: 237

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net