Admin Alert: A Simple Save While Active Backup Program

Published: June 17, 2009

by Joe Hertvik

The problem with 24x7 environments is that it's difficult to make time to run complete system backups. Modern processing needs dictate that you can rarely, if ever, take down your machine to back up the entire system. This week, I'll look at a hybrid backup scheme that lets you achieve the dual goal of performing occasional full system backups while still saving all your critical system and user data.

A Simple Strategy

The following is a simple save strategy that you may be able to use in your shop. It consists of two system backup elements that allow you to occasionally perform a complete system backup while maintaining nightly backups of your most important data.

1. A full system backup that can be taken weekly, monthly, or even quarterly during off-hours. This backup provides a baseline copy of your system that can be used for restoring all system objects in the event of a disaster.
2. An intermediate backup program that saves all the changed objects on your system since the last full backup, without taking your system down. This backup uses IBM's save-while-active technology to save all your critical system objects and user files without disrupting processing. It can be run in between your full system backups and it will save data and configurations that are changed between backups.

While this scheme does not provide complete 24x7 availability because you still need to run occasional full system backups, it does provides most of the tools you'll need to backup your system with minimal disruption.

The Full System Backup

i5/OS full system backups are performed by running option 21 off the Save menu (GO SAVE). A full system backup provides a baseline picture of your system that can be used to restore the entire system in the event of a disaster. To perform a full system backup, simply select option 21, Entire System, off the Save menu and the operating system will prompt you for all the parameters it needs to take a complete snapshot of your entire system. For a complete picture of how an option 21 backup works, check out this article that discusses in detail how an option 21 save works.

Between the Full Backups

The problem with an option 21 save is that you may not be able to save your entire system every night, due to processing commitments. To fill in the gaps and to make sure that I can restore most objects that are changed between full system backups, I wrote the following CL program that saves all critical and changed objects every night. The name of the program is NGHTLYBKP and this is the code I use to back up the system on off-nights.

0001.00     PGM        PARM(&TAPDEV)
0002.00
0003.00     DCL        VAR(&TAPDEV) TYPE(*CHAR) LEN(6)
0004.00     DCL        VAR(&TAPDEVLNG) TYPE(*CHAR) LEN(40) +
0005.00                  VALUE('/QSYS.LIB/')
0006.00     DCL        VAR(&TAPDEVEND) TYPE(*CHAR) LEN(5) +
0007.00                  VALUE('.DEVD')
0008.00
0009.00     CHGVAR     VAR(&TAPDEVLNG) VALUE(&TAPDEVLNG *TCAT +
0010.00                  &TAPDEV *TCAT &TAPDEVEND) /* set up +
0011.00                  parameter for saving to tape device in +
0012.00                  the SAV command */
0013.00
0014.00     CLRMSGQ    MSGQ(QUSRSYS/SAVEMSGQ) /* Clear out old save +
0015.00                  messages before starting */
0016.00
0017.00     SAVSECDTA  DEV(&TAPDEV) ENDOPT(*LEAVE) /* Save user +
0018.00                  profiles, private authorities, and other +
0019.00                  security data */
0020.00
0021.00     SAVCFG     DEV(&TAPDEV) ENDOPT(*LEAVE) /* Save all +
0022.00                  current configurations */
0023.00
0024.00     SAVCHGOBJ  OBJ(*ALL) LIB(*ALLUSR) DEV(&TAPDEV) +
0025.00                  OBJJRN(*YES) ENDOPT(*LEAVE) UPDHST(*NO) +
0026.00                  SAVACT(*SYNCLIB) SAVACTWAIT(60) +
0027.00                  SAVACTMSGQ(QUSRSYS/SAVEMSGQ) ACCPTH(*YES) +
0028.00                  QDTA(*DTAQ)        +
0029.00                  OUTPUT(*OUTFILE) +
0030.00                  OUTFILE(QUSRSYS/SAVCHGOBJ) INFTYPE(*ERR) +
0031.00                  /* Save all library objects that were +
0032.00                  changed since the last backup */
0033.00     MONMSG     MSGID(CPF3778) /* Ignore message CPF3778 - +
0034.00                  Not all objects saved from all libraries */
0035.00
0036.00
0037.00     SAVDLO     DLO(*SEARCH) DEV(&TAPDEV) +
0038.00                  REFCHGDATE(*SAVDLOALL) ENDOPT(*LEAVE) +
0039.00                  SAVACT(*YES) SAVACTWAIT(60) /* Save all +
0040.00                  Document Library objects changed since +
0041.00                  last backup */
0042.00     MONMSG     MSGID(CPF906B)
0043.00
0044.00     SAV        DEV(&TAPDEVLNG) OBJ(('/*') ('/QSYS.LIB' +
0045.00                  *OMIT) ('/QDLS' *OMIT)) SAVACT(*SYNC) +
0046.00                  OUTPUT(*PRINT) ENDOPT(*LEAVE) +
0047.00                  SAVACTMSGQ('/QSYS.LIB/QUSRSYS.LIB/SAVEMSGQ.+
0048.00                  MSGQ') INFTYPE(*ALL) CHGPERIOD(*LASTSAVE) +
0049.00                  /* Save all IFS objects except for the +
0050.00                  QSYS.LIB folder and the DLO objects */
0051.00     MONMSG     MSGID(CPF3837)
0052.00
0053.00     DSPJOBLOG  OUTPUT(*PRINT) /* Print out the joblog for +
0054.00                  review later on */
0055.00
0056.00
0057.00     DSPTAP     DEV(&TAPDEV) DATA(*SAVRST) OUTPUT(*PRINT) /* +
0058.00                           Display tape contents for review, if +
0059.00                           needed */
0060.00
0061.00     ENDPGM

Here's what each piece of code does.

Line 1.00--The calling user passes in the name of the backup media device to use in the &TAPDEV parameter. By passing in the device name, I can easily change the media save device name by changing the program call statement, instead of changing and recompiling the program.

Lines 3.00-12.00--Program variables are defined for the media device name (&TAPDEV), as well as for the AS/400 Integrated File System (AS/400 IFS) name of the media device name (&TAPDEVLNG). An AS/400 IFS name consists of a specific designation that pinpoints exactly where in the IFS the device is located. Lines 9.00-12.00 build the AS/400 IFS name of the device where I will be saving the data.

Lines 14.00-15.00--Clears out the message queue that will contain any messages arising from the programs save commands. In this CL, all messages are saved to the SAVEMSGQ message queue in library QUSRSYS. Saving messages to a separate message queue allows you to view the messages apart from messages in other public message queues on the system, such as QSYSOPR. Before attempting to run this program, make sure to create the SAVEMSGQ message queue.

Lines 17.00-22.00--These commands save critical system data that may change from day to day. Lines 17.00-18.00 save all the system security data (user profiles, private authorities, etc.) by using the Save Security Data (SAVSECDTA) command, while lines 21.00-22.00 save all the device configuration data (display devices, printer devices, RF devices, etc) by using the Save Configuration (SAVCFG) command. Since user profiles and devices can be created on the system every day, you need to back them up between your full system backups.

Lines 24.00-32.00--The Save Changed Objects (SAVCHGOBJ) command saves all the user library objects (*ALLUSR) that have changed since the last time those objects were saved during the full system backup. Furthermore, this command will save objects while they are in use. All of the objects and the libraries saved by this command reach their save checkpoints together and they are saved in a consistent state in relationship to each other (they are saved as a set). Here's how each of the SAVCHGOBJ parameters affect command execution:

• The Objects (OBJ) and Library (LIB) parameters tell the command to save all of the changed objects (*ALL) in each user library (*ALLUSR) that match the rest of the parameters in the command. By default, the command will save all of the objects that have been changed or added since the last running of the Save Library (SAVLIB) command over these libraries (which occurs during the full system backup).
• The Device (DEV) parameter tells the command to save these objects to the media device listed in the &TAPDEV parameter.
• The Journaled Objects (OBJJRN) parameter is set to *YES, which means the command will save objects that are currently being journaled or have been journaled since the date and time specified in the Reference Date (REFDATE) and Reference Time (REFTIME) parameters.
• The End of Media Option (ENDOPT) parameter is set to *LEAVE, which means that the command should not rewind the backup save media the objects are being saved to after the command completes.
• The Update History (UPDHST) parameter is set to *NO, which means that after an object is saved, the command will not update that object's history flag. This makes changed objects eligible to be saved every time this program is run, until the object's flag is reset when you run another option 21 save. The only issue this creates is that more objects will be added to your backup media each time you run this program (making your backup tape bigger every day), until you reset all the object history flags during the next full system backup.
• The Save Active (SAVACT) parameter is set to *SYNCLIB, which means that all the objects saved by the command will reach a community checkpoint and be saved in a consistent state with each other (i.e., as a set). In addition, the Save Active Wait Time (SAVACTWAIT) parameter tells the command to wait 60 seconds for any objects that are exclusively being used before giving up and moving on to the next object. Objects that are held with an exclusive lock cannot be saved by this command.
• The Save Active Message Queue (SAVACTMSGQ) parameter designates the message queue that any command messages are sent to. This is the same message queue that was cleared after the program starts.
• The Save AccessPpaths (ACCPTH) parameter tells the command to save certain logical file access paths that are dependent on physical files being saved. The Queue Data (QDTA) parameter value of *DTAQ tells the command to save both the description and the physical contents of all standard data queues during the save.
• The Output (OUTPUT) parameter value of *OUTFILE combined with the Type of Output Information (INFTYPE) parameter tell the command to save abbreviated result information to the file name specified in the File to Receive Output (OUTFILE) parameter. In my case, INFTYPE is set to *ERR, which means that the command will write one entry to the OUTFILE for each library the command processed and a separate entry for each object that was not successfully saved. This file can be queried later to determine any problems in saving objects.

Line 33.00-35.00--Contains a Monitor Message (MONMSG) command that tells the program to ignore message CPF3778 (not all objects saved from all libraries) if that message is issued as a result of the SAVCHGOBJ command. CPF3778 is an informational message that has no effect on command processing.

Lines 37.00-41.00--Using the Save Document Library Object (SAVDLO) command, this code saves all the changed Document Library Object (DLO) objects that were updated or added since the last backup. It designates that it should save all newly changed objects by designating *SEARCH in the Document Library Object (DLO) parameter and *SAVDLOALL in the Last Changed Date (REFCHGDATE) parameter. *SAVDLOALL tells the command to save all objects that have been added or updated since the last backup. This command also saves objects while they are active (Save Active parameter = *YES) and it will give up trying to save held objects after 60 seconds (Save Active Wait Time parameter = 60).

Line 42.00--The program uses another MONMSG command to prevent the CPF906B message (No document library objects saved) from holding up program execution, if it is generated by the SAVDLO command.

Lines 44.00-50.00--The Save (SAV) command is used to save AS/400 IFS objects that have changed since the last full system backup. It does this by setting the Time Period for Last Change (CHGPERIOD) parameter to *LASTSAVE, which tells the command to save any object that was changed since the last time the object had its Update History parameter turned on. In addition, this command synchronizes the backup so that all changed objects are saved even if they are in use; that all saved objects reach their save checkpoint at the same time (Save Active parameter = *SYNC); and that all messages are sent out to the message queue specified in the Save Active Message Queue (SAVACTMSGQ) parameter.

Line 51.00--Like the other save commands, the program monitors the SAV command to ignore message CPF3837 (&1 objects saved, &2 not saved) if it is issued, so that the program does not stop if that message is displayed.

Lines 53.00-59.00--These lines output the job's job log information, through the Display Job Log (DSPJOBLOB) command, to a printer file. They also output the Save Restore information on the tape to a spooled file, through the Display Tape (DSPTAP) command. These reports allow the operator to review the results of the save whenever he wishes.

Line 61.00--The End Program (ENDPGM) command ends program processing.

By running the NGHTLYBKP program on a daily basis, you can save most updated configuration and user objects to media on a save-while-active basis without disrupting system processing. With the option 21 save and this save-while-active backup shell, you have two different sets of backup media that contain a baseline of your system along with any database or configuration changes that were made after the option 21 media was created. This minimizes the amount of downtime you need to securely back up your system while other people are using it.

RELATED STORY

Dissecting an Option 21 Save

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot