Make System Backup!

The best feature, that AIX has and Linux is missing

Of course, there are many possibilities to make a system backup in Linux. And let’s be honest, mksysb is not state-of-the-art software. It is just like any UNIX tool. It makes one thing, and it makes it good. I think my favorite outcome of mksysb is the ease to create system clones.

mksysb basics

The mksysb command makes a system backup. That’s it. In its easiest form, you simply specify the file to create, like:

mksysb /path/to/mybackup.mksysb

Like many other commands, mksysb has many options. One option is a must-have. Even the man page says:

You must use the -i flag.

The -i indicates that the command mkszfile must be executed before mksysb. The command mkszfile creates the new image.data file. Do you remember that I wrote about image_data resource in NIM?

Forgotten NIM resource type

Here it is. The AIX installer must know the sizes of the filesystems to create. If you don’t specify an image.data file, it uses the image.data file from the backup. If the file in the backup contains wrong data, you will get a problem. It is better to recreate the file every single time you make a system backup.

Another useful option is -e. If the option is specified and you have the file /etc/exclude.rootvg, all files that match the patterns from /etc/exclude.rootvg, will be excluded from the system backup.

The usual way is to create the file /etc/exclude.rootvg containing at least /tmp:

^./tmp/

You probably don’t need to back up temporary files. Of course, you can do it if you wish, but why waste space on your filesystem?

You may also want to skip log files. Especially if you create an image for future clones.

Inspecting mksysb

After mksysb is created, you check what is there by using lsmksysb:

lsmksysb -f /path/to/mybackup.mksysb

If you want to restore some files from the mksysb, you can use the restorevgfiles command:

restorevgfiles -f /path/to/mybackup.mksysb ./myfile

You can specify several files to extract at once in the command line.

If you remember that mksysb is nothing else but a normal backup/restore archive, you can use the restore command to perform the same operations.

To list the files:

restore -Tvqf /path/to/mybackup.mksysb

To restore specific files:

restore -xvqf /path/to/mybackup.mksysb ./myfile

Where to create mksysb

By default, the mksysb command creates the system backup on /dev/rmt0 - on the first tape device attached to the system. In the modern virtualized world, you probably don’t have a tape drive on your LPAR.

Of course, you can create mksysb directly on the server itself. You specify a path to the new system backup file, and you got it!

Don’t you feel it is a little bit stupid to save backup on the server itself? If the server is not available anymore, the backup is also not available. What is the purpose of such a backup?

That’s why it is quite usual to create an mksysb on an NFS share. If you have a NIM server, you already have an NFS server in your environment. You only must share a directory from your NIM server to your AIX clients. Then mount the NFS share, execute the mksysb command, and unmount it.

By the way, I wrote how to automate this procedure using Ansible one year ago:

Automating mksysb and backupios with Ansible

If we create mksysb on the NIM server and the NIM server has an mksysb resource type, we can create everything in one step. No manual NFS share mounting, unmounting, backups, and NIM resource creation. Simply:

nim -o define -t mksysb -a server=master -a location=/nim/mksysb/aix_mksysb -a mk_image=yes -a source=aix_lpar aix_mksysb

Several minutes later, you have your mksysb on the NIM server.

Nothing is wrong with the procedure. There is only one limitation - how many tasks your NIM server can handle in parallel.

If you have a smaller environment, you will never hit the limit. Especially if you made it a little bit bigger.

If you have a bigger environment, I think it is better to create system backups from the client LPARs using an Ansible playbook like I provided.

Support the Power DevOps Newsletter!

If you like reading technical articles about IBM Power, AIX, and Linux on IBM Power, consider upgrading to the paid tier to show your support. As a paid subscriber, you not only get regular posts, but you will get additional posts with the full code and further explanations, access to the whole archive of the blog, and take part in our monthly calls where you can ask your questions and propose topics for future newsletters. Be an active member of our community!

Restore!

Yes, we are all experienced administrators. Who needs all these backups and restore tests? We know, it works!

That’s why I will be short today.

If you have an mksysb on your NIM server, you define a new mksysb resource, unless it is already defined:

nim -o define -t mksysb -a server=master -a location=/nim/mksysb/aix_mksysb aix_mksysb

Then you create a SPOT resource from the mksysb:

nim -o define -t spot -a server=master -a location=/nim/spot -a source=aix_mksysb aix_spot

Now you are ready to restore your mksysb to a server:

nim -o bos_inst -a spot=aix_spot -a mksysb=aix_mksysb -a accept_licenses=yes aix_lpar

But there is much more to tell about this beautiful tool!

Have fun making system backups!

Andrey

Hi, I am Andrey Klyachkin, IBM Champion and IBM AIX Community Advocate. This means I don’t work for IBM. Over the last twenty years, I have worked with many different IBM Power customers all over the world, both on-premise and in the cloud. I specialize in automating IBM Power infrastructures, making them even more robust and agile. I co-authored several IBM Redbooks and IBM Power certifications. I am an active Red Hat Certified Engineer and Instructor.

Follow me on LinkedIn, Twitter and YouTube.

You can meet me at events like IBM TechXchange, the Common Europe Congress, and GSE Germany’s IBM Power Working Group sessions.