With good reason, people are testing their backups more often than they used to.

There's an old saying: "You can back things up, but can you restore?" It's almost become a bit of a mantra that rolls off the tongues of business partners as easily as the words "scalable," "robust," or "paradigm." 

Since recovery is the major reason for backing up your system, much attention and focus have been given to the end process of recovery. In fact, starting in V6R1, IBM's backup and recovery manual has been renamed Recovering Your System. Much of the information on saving your system has been omitted and now exists primarily in the IBM Information Center for V6R1 and V7R1.

But what if you attempt a restore and realize that you haven't been backing everything up? Every now and then, you should look at your backup to ensure you've got all the saving bases covered to ensure you have everything you need to recover. Your backup and recovery strategy should also include a test restore.

I know of a company with an old AS/400 that had a disk failure a few months ago. They had no raid protection and were relying on their last full system save from 2009 to do the OS restore. The plan was to restore the data libraries from the nightly backup.

Here's the kicker. Since data grows over time, the amount of data going to tape was exceeding the capacity of the tape used; therefore, each night there was a message in the QSYSOPR message queue stating that a second tape was needed and asking for an operator to load the second tape and press either C or G (C meaning Cancel, G for Go). The message was automatically answered incorrectly every evening with a C. This means that the save job would cancel halfway through the backup, so the only real usable data was from the 2009 full system save.

That's a scary situation, so let's make sure we know all aspects of saving the system.

In this article, I'll explain how the Save Security Date (SAVSECDTA) command works and how it relates to the restore commands Restore User Profile (RSTUSRPRF) and Restore Authority (RSTAUT).

The SAVSECDTA command saves all security information from a system. Save System (SAVSYS) also saves this information amongst other data; however, SAVSYS requires putting the system in a restricted state. Essentially, SAVSECDTA backs up your user profiles, authorization lists, and authority holders.

The frequency of authority and object changes on your system will dictate how often you do a SAVSECDTA. I run it every night because we use part of our IFS as a file server (which can be a high volume of file additions) and we sometimes have daily object additions. If you have a more "static" system, you can get away with a less frequent run of SAVSECDTA, but I'd suggest running it on a frequent basis for good measure.

The corresponding restore commands for SAVSECDTA are RSTUSRPRF and RSTAUT. RSTUSRPRF will restore user profiles or group profiles saved with SAVSECDTA (including attributes such as user class, special authorities, etc.). RSTUSRPRF will not restore a user profile's authority to other objects. You have to run the RSTAUT command to accomplish that. Furthermore, objects a user profile is authorized to (or not) must be restored before the RSTAUT command is run.

All three of these commands require you to have the *SAVSYS special authority.

It's very simple but also very important. If you're only doing a SAVSECDTA once every month but you have users creating files in the IFS every day, then you may be in for a bit of a shock when you restore your system and can't recover a month's worth of authority changes.

as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7,

Steve Pitcher works with iTech Solutions, an IBM Premier Business Partner. He is a specialist in IBM i and IBM Power Systems solutions since 2001. Feel free to contact him directly This email address is being protected from spambots. You need JavaScript enabled to view it..