Manage Learn to apply best practices and optimize your operations.

Omitting processes during a save while active backup?

Find out if log files can be omitted during a save without causing problems in a full restore.

I've written a full system backup program in CL that takes advantage of the save while active functionality to decrease our downtime window.

Although it has to be started in a restricted state to do a SAVSYS, SAVLIB *IBM, a SAV of the IBM directory objects, I also added the SAVDLO command while restricted. At this point, I start a subsystem and a message monitoring program in that subsystem to monitor for CPI3712 and then start QCTL to allow users to sign on. Then, the initial program continues to do a SAVLIB *ALLUSR with SWA set to *SYNCLIB. Afterward, I save the IFS using SAVACT *YES.

My issue is that during the save of the IFS, some objects are locked since the system is up for the users. A lot of these objects are log files. Can these log files be omitted during the save without causing a problem in the case of a full restore? Are there other directory objects that can be omitted as well?

A save while active backup isn't a save while locked backup...as you have already discovered.

I'm just kidding around a bit, but in order for a SWA backup to work, you have to establish a CHECKPOINT for all the backup processes BEFORE you release the system for use.

There are two different versions of a SWA backup:

  1. REDUCE the save-outage time (the easiest)
  2. ELIMINATE the save-outage time (the hardest)

If at all possible, try to implement option #1. You can also run concurrent SWA backups if you have multiple tape drives, and release the system for use after both the SAVLIB and SAV processes have issued the CPI3712 message indicating a CHECKPOINT has been reached. More information about SWA can be found from IBM.

If you want to continue doing things the way you are, then the only way to validate whether or not backing up some objects will create an issue during recovery is to practice recovering your system and document what happens.

TEST, TEST, TEST. In fact, I would recommend doing a complete disaster recovery test at least once a year.

Dig Deeper on Data backup, storage and retrieval on iSeries