Admin Alert: Meditations on Full System Backups

June 27, 2007 Joe Hertvik

Long-time i5/OS and OS/400 administrators may think they know everything about full system backups (FSBs). However, there are several considerations to think about before performing an FSB, and IBM has recently slipped additional capabilities into the FSB process that you may not know about. So let’s take five minutes and meditate over the whys, whens, and hows of FSBs and how you can improve the backup process in your shop.

Why We FSB

Full system backups are performed as insurance for emergency situations, such as a total system crash or a full system recovery to another machine in the event of a complete disaster (fire, flood, etc). FSBs take a complete snapshot of your machine (operating system, security, configurations, and data) that can be restored back to the machine or to another machine in a different location. When restoring from a FSB, the ideal situation is that the restored machine is an exact operational duplicate of the original box.

Because of the need to back up everything on your operating system, i5/OS requires that you put your iSeries or i5 box into restricted mode before performing an FSB, so that you can back up all system objects, including the operating system, that are locked during regular operations.

The mechanics of an FSB are simple and they are discussed in an earlier article I wrote called Dissecting an Option 21 Save. For an explanation of the ins and outs of putting your system i box into restricted mode, see Getting In and Out of iSeries Restricted State.

When We FSB

Since it can be a hassle taking down and backing up your entire system, you will want to be choosy about exactly when you should perform your FSB. If your shop IPLs its partitions every week, it’s easy to schedule an FSB because you have more opportunities for backing up the system. However, if your system i, i5, or iSeries box participates in real-time transactions in a 24x7x365 environment, scheduling an FSB can be more difficult. Therefore, it’s helpful to create some guidelines for what situations offer full system backup opportunities. I generally consider performing a full system backup when any of the following events occur.

When I apply a significant number of PTFs, especially when I apply cumulative PTF changes (CUME). CUME PTFs can fundamentally change the nature of your operating system and correct some serious problems with how things run. Since cumulative PTFs almost always require a system IPL, you may want to IPL your machine into restricted mode and perform the FSB before bringing the machine up again for general usage. The only time you might not want to consider an FSB in conjunction with PTFs is if you are only applying only one or two recommended PTFs. In those cases, you may not want to bother with a FSB, preferring instead to wait until the next time a better FSB opportunity arises.
When I change an i5/OS licensed product, such as adding a product or loading up additional licensed programs options. Changing a licensed product can involve changes to your operating system and you may want to back up the operating system soon after modifying licensed product setups.
When I upgrade to a new i5/OS release. In the event of a possible upgrade failure, I like to perform two FSBs (if possible) with every upgrade attempt. First, I usually back up the entire system before I perform the upgrade so that I can restore it from scratch in case the upgrade goes horribly wrong. Then, if I have time before the system is scheduled to restart, I try to do a second FSB after the upgrade so that I can restore the new system in the event of a disaster. The only danger in not performing the second upgrade is that if a disaster hits after the upgrade, I would have to restore the system to the state it was in before the upgrade and then I would have to upgrade the restored system a second time in order to get my upgrade back.
When it’s time to run an FSB, because I haven’t performed an FSB in a year or more. As a busy administrator, I sometimes forget to perform an FSB if I haven’t done any major work on my box for a while. However, it’s wise to think about backing up the entire system at least once a year just to make sure that you catch any onesie and twosie changes that have been applied over the year. If you’re not sure when you last performed a full system backup, there’s a simple technique for finding out. You can do this by checking the object description of a data area called QSAVSYS, which resides in the QSYS library. The Save/Restore information in this object’s attributes will indicate the last time that you ran the Save System command (SAVSYS) on this system. For more information on determining when many i5/OS backup commands were last run, see When Did I Last Use That Save Command?.

The Alternative FSB

One of the problems with FSBs is that depending on how much data you have on your system, they can take several hours. Depending on how heavily used your system i, i5, or iSeries box is, a backup can put you in a severe time crunch, especially if you’re trying to perform two full system backups during an upgrade. An alternative to performing a time-consuming full system backup is to do the following:

When you need to backup the system due to changes in the operating system, put the system in restricted mode. Instructions for getting into and out of restricted mode can be found in this article.
Instead of performing a full system backup, only run the Save System command (SAVSYS). According to IBM documentation, the SAVSYS command does the following: The Save System (SAVSYS) command saves a copy of the Licensed Internal Code and the QSYS library in a format compatible with the installation of the operating system. It does not save objects from any other library. In addition, it saves security and configuration objects that can also be saved using the Save Security Data(SAVSECDTA) and Save Configuration (SAVCFG) commands. By doing this, you are saving all the system objects that need to be in restricted mode to be saved. Most other objects can be saved to media by using their relative Savxxx commands in save-while-active mode.
Get out of restricted mode and restart your system.
On a regular basis (nightly if possible), run a save-while-active backup to save all your system libraries, user libraries, document library objects, and the AS/400 Integrated File System (AS/400 IFS). In order to make sure that you have the latest additions to your user and device configurations in your regular backups, you may also want to backup your security data and system configurations through the SAVSECDTA and SAVCFG commands.

By doing these steps, you save time in restricted mode by just backing up your core system objects that need the system down to be saved. And because you are taking regular backups of your data, you can easily perform a restore by using the two different tapes: the system backup (which doesn’t change as often) and the latest save-while-active backup that contains your rapidly changing data and configurations.

Changes to the FSB

In addition to all this, you may not realize that IBM has been adding new options to its full system backup strategy. In i5/OS V5R3, IBM made it possible to run batch jobs in the i5/OS controlling subsystem while the machine is in restricted mode. This means that you can set up a procedure to place your system i box into restricted mode, perform a batch system backup in the controlling subsystem, and then restart your system. I haven’t yet tested this technique but I will explore it in a future column. If you want read a little more about batch system saves before then, check out IBM’s Software Technical Document on Running a Full System Save or SAVSYS in Restricted State Batch.

The other significant FSB change occurred in i5/OS V5R4, when IBM introduced the Save System Information command (SAVSYSINF). SAVSYSINF allows you to save the cumulative changes that have occurred to your licensed internal code and QSYS library since the last Save System command (SAVSYS) was completed, and you don’t need to be in restricted mode to run SAVSYSINF. For restoration, you would need to apply two sets of backup media to restore the system to its last known operating system configuration: the media that contained your last system save and the media containing your SAVSYSINF info. For more information on using SAVSYSINF, see IBM’s entry on the subject in the i5/OS Information Center, Version 5, Release 4.

About Our Testing Environment

Most configurations described in this article were tested on an i5 550 box running i5/OS V5R3. Many of the commands may also be available in earlier versions of the operating system, except where a command is noted to have minimum operating system requirements. . . . However, if a command is present in earlier versions of the i5/OS or OS/400 operating systems, you may notice some variations in the pre-V5R3 copies of these commands. These differences may be due to command improvements that have occurred from release to release.