— LiveStream

An AIX mksysb backup captures a bootable, restorable image of the root volume group (rootvg) so you can rebuild an entire LPAR after a disk failure, a botched upgrade, or a full site disaster. This guide shows how to schedule a weekly mksysb backup, write the image to a local filesystem, copy it safely to a remote central location, and verify the result so the backup is actually usable when you need it.

What an AIX mksysb backup actually contains

The mksysb command creates an installable image of rootvg only — the operating system, configured paging space, logical volume layout, and any user data that happens to live in rootvg filesystems. It does not back up other volume groups (datavg, appvg, etc.); those need savevg. Understanding that boundary is the single most common point of failure in AIX recovery plans.

A mksysb image is special because it is bootable. When written to tape, DVD, or used through NIM (Network Installation Management), it can boot the machine, recreate the rootvg structure, and restore the OS without a separate AIX install media set. Modern AIX (7.2 and 7.3) still uses mksysb exactly the same way it did on AIX 5.3 — the command and its image format are stable and fully supported.

The problem: weekly OS image backups for many LPARs

In a typical Power Systems estate you have dozens of LPARs, each needing a regular OS image so any single host can be rebuilt quickly. Tape libraries are slow and contended, so a practical pattern is:

• Each LPAR writes its mksysb to a local filesystem (fast, no tape contention).
• The image is then copied to one central remote server for off-host safekeeping.
• A scheduled cron job drives the whole thing weekly with no operator involvement.

This file-based mksysb approach is the same workflow that scales cleanly into a NIM master, where the central server becomes a restore source for network installs.

Step-by-step: schedule and run the mksysb backup

1. Create a dedicated filesystem for the image. Never write a mksysb into / or /tmp — a multi-gigabyte image can fill rootvg and crash the box mid-backup. Create a separate filesystem (ideally in a non-root VG):

   crfs -v jfs2 -g datavg -a size=20G -m /mkdvd -A yes

   mount /mkdvd

2. Run mksysb to a file. The key flag is -i (generate the image.data map) and the target is a filename, not a tape device:

   mksysb -i /mkdvd/$(hostname)_mksysb_$(date +%a%d%b%Y)

   Add -e to exclude files listed in /etc/exclude.rootvg, and -X to auto-grow /tmp if the boot image needs more room.

3. Wrap it in a script. A small KornShell script makes the cron entry clean and lets you add logging and the remote copy in one place:

   #!/usr/bin/ksh

   HOST=$(hostname); STAMP=$(date +%a%d%b%Y)

   IMG=/mkdvd/${HOST}_mksysb_${STAMP}

   /usr/bin/mksysb -i -e -X $IMG >> /var/log/mksysb.log 2>&1

4. Schedule it with cron. Edit root's crontab with crontab -e and add a weekly Monday-morning run. The five fields are minute, hour, day-of-month, month, day-of-week (0/7 = Sunday, 1 = Monday):

   1 2 * * 1 /home/scripts/mksysb_backup.ksh >/dev/null 2>&1

   That runs at 02:01 every Monday. Always redirect both stdout and stderr; an early source of confusion is the malformed redirect 2>&1 placed with nothing in front of it, which silently does nothing useful. The correct form is command >file 2>&1.

Copying the mksysb image to a remote filesystem

Once the local image exists, push it to your central server. The legacy approach used rcp over rsh, which sends data in clear text and should be retired. Use scp or rsync over SSH instead, with key-based auth so the cron job is non-interactive.

1. Set up passwordless SSH from each LPAR to the central server (run once):

   ssh-keygen -t rsa -b 4096 -N "" -f /.ssh/id_rsa

   ssh-copy-id root@centralsrv

2. Append the copy to your script. rsync is preferred because it can resume a partial transfer and verifies what it sent:

   rsync -av --partial $IMG root@centralsrv:/mkdvd/ >> /var/log/mksysb.log 2>&1

   If rsync is not installed, use scp -p $IMG root@centralsrv:/mkdvd/ (the -p preserves timestamps).

3. Confirm the central layout. On the central server, a long listing shows each LPAR's images side by side. Filenames that embed the hostname and date make this self-documenting:

   root@centralsrv:/mkdvd> ls -ltr

Note the mode -rw-r----- (640, root:sys): a mksysb is effectively a full copy of your OS including /etc/security/passwd, so it must not be world-readable. Lock down the /mkdvd directory too with chmod 750 /mkdvd.

Common pitfalls in an AIX mksysb backup workflow

These are the issues that turn a "successful" backup into a useless one:

• Tiny images (a few MB) are failures, not backups. In a directory listing, a real rootvg image is gigabytes. An entry like a 4 MB image file means mksysb aborted almost immediately — usually out of space in the target filesystem or in /tmp. Treat any image far smaller than peers as a failed run.
• Forgetting non-root volume groups. mksysb saves only rootvg. Schedule savevg -if /mkdvd/$(hostname)_datavg datavg for each additional VG, and copy those off-host too.
• Filesystem fills mid-backup. Size /mkdvd for at least 1.5x your largest expected image and prune old copies. A simple find /mkdvd -name '*_mksysb_*' -mtime +21 -delete keeps three weeks.
• Clear-text copy tools. Replace rcp/rsh with scp/rsync over SSH; the old r-commands are disabled by default on hardened modern AIX.
• No restore test. A backup you have never restored is a hope, not a plan. Periodically restore one image via NIM into a spare LPAR.
• Cron PATH surprises. cron runs with a minimal environment. Use full paths (/usr/bin/mksysb) in scripts so the job does not fail only when scheduled.

Verification: prove the mksysb backup is restorable

Verifying an AIX mksysb backup takes two minutes and is the difference between a real disaster-recovery plan and wishful thinking.

1. Check the exit status and log. A clean run ends with 0512-038 mksysb: Backup Completed Successfully. Grep the log: grep -i 'completed successfully' /var/log/mksysb.log.
2. List the image contents. The image is a backup-format archive you can inspect without restoring:

   lsmksysb -lf /mkdvd/$(hostname)_mksysb_*

   or, for the raw table of contents, restore -Tqf /mkdvd/<image>.

3. Confirm bootability metadata. lsmksysb -f <image> shows the AIX level, build, and that a valid boot image is present.
4. Compare sizes across runs. Week-over-week the image size should be stable. A sudden drop signals truncation; a sudden jump signals new data accidentally left in rootvg.
5. Verify the remote copy. On the central server compare byte counts: ls -l /mkdvd/<image> on both hosts must match exactly. With rsync, a re-run that transfers nothing confirms the copy is identical.

Restoring from a file-based mksysb

The cleanest restore path for file images is NIM. Define the mksysb as a NIM resource on the central server and run a bos_inst against the target LPAR, which network-boots it and lays down the image. For a single host without NIM, you can convert the file image to bootable tape or DVD, or boot the LPAR into SMS/maintenance mode and point it at the network image. Either way the rootvg structure, OS level, and rootvg data come back exactly as captured.

Key Takeaways

• mksysb backs up rootvg only — use savevg for every other volume group and copy those off-host too.
• Write images to a dedicated, sized filesystem (never / or /tmp), then push them to a central server for off-host safety.
• Use a cron-driven KornShell script with full paths and proper >file 2>&1 redirection for unattended weekly runs.
• Replace legacy rcp/rsh with scp or rsync over SSH using key-based auth.
• Always verify: check the success message, inspect with lsmksysb, compare sizes, and periodically do a real restore.

Frequently Asked Questions

Does mksysb back up all volume groups in AIX?

No. mksysb captures only the root volume group (rootvg) and produces a bootable image. For application or data volume groups (datavg, appvg, and so on) you must run savevg separately, and you should copy those images off-host alongside the mksysb.

How do I schedule a weekly mksysb backup with cron?

Add an entry to root's crontab with crontab -e. A line like 1 2 * * 1 /home/scripts/mksysb_backup.ksh >/dev/null 2>&1 runs your backup script at 02:01 every Monday. Use full command paths inside the script because cron runs with a minimal environment.

How can I verify an AIX mksysb image is good?

Confirm the run logged "Backup Completed Successfully," list the image contents with lsmksysb -lf <image> or restore -Tqf <image>, compare the file size against previous weeks, and ensure the remote copy is byte-for-byte identical. The ultimate test is restoring one image into a spare LPAR via NIM.

Is mksysb still supported on AIX 7.2 and 7.3?

Yes. The mksysb command and its image format are unchanged and fully supported on current AIX releases. File-based images, NIM-based restores, and the cron workflow described here all work identically on modern Power Systems hardware.

For more hands-on AIX, Linux, and sysadmin walkthroughs, subscribe to YouTube @explorenystream.