More On Automating Your Disaster Recovery Restore

By Rich Loeber,

Some while ago, I wrote a security tip about automating your IBM i disaster recovery restore process. Of the many tips I’ve done over the years, none has drawn as much “fan mail” as this particular tip.

The essence of the tip is an implementation of the OS/400 command LODRUN to automatically restore a full system backup tape. The LODRUN searches the tape for a known program (named QINSTAPP), loads that program into the session QTEMP library and then calls it. Your QINSTAPP program can then load the contents of the tape. The only thing you have to do is create the QINSTAPP program and include it in the backup.

Well, I created that methodology quite a while ago, and a “fan” recently contacted me to let me know that, during testing, he found a problem with it. It seems that the current versions of i/OS don’t like it when the SAVLIB for *ALLUSR or *NONSYS libraries is not the first backup set on the tape. The tip clearly was calling for the QINSTAPP *PGM object to be the first object on the tape, so there was a conflict.

First, I have to commend my “fan” (Keith Scott at Hoover Materials Handling Group) for putting the process to the test. Over the years, I’ve given away hundreds of copies of the shell CL program for QINSTAPP and Keith was the only one to test it and find the problem. No matter where you get your code, testing should ALWAYS be a requirement, especially for something so important as a disaster recovery procedure. I tested this process long ago and it worked then, but it is problematic today.

The news is not all bad, however. With the current versions of i/OS, the LODRUN command supports a SEQNBR parameter where you can use a *SEARCH parameter. This will cause the process to scan the tape until it finds the QINSTAPP saved from QTEMP. At that point, it will load the program and run it.

There is a downside, however. Because the SAVLIB has to come first on the tape, there is a lot of tape searching going on before the actual save gets going. This could add 30 minutes or so to your restore process, depending on the kind of tape you’re using. But, the restoration process is still fully automated, so there’s a strong benefit.

The modified save process should now be changed to save your system in the following sequence:

  • SAVLIB for the libraries you want to save (either *ALLUSR or *NONSYS)
  • SAVOBJ for the QINSTAPP saved from QTEMP
  • AVSECDTA to save your security setup
  • SAVDLO for your shared folder objects
  • SAV for the IFS (other than shared folders)

The QINSTAPP has to be changed to first restore the security data which will sit on the tape right after the QINSTAPP itself. Then, the restore should force a rewind on the tape and restore the libraries. When that’s done, the remaining restores for the IFS will complete the process. When all is said and done, the last step must be a RSTAUT to restore object authorities.

To properly illustrate this, I’ve updated my sample QINSTAPP CL program and also created a companion QDRSAVE CL program to show the system save process in the right sequence. If you’d like to see these sample programs, send me an email (rich@kisco.com) and I’ll send you the shells that I recently created.

Comments are closed.