Because your limited budget contains no money for a hot site, you've never tested your backup process to see if you can actually restore your system. You know that if you must restore and the system fails, you're the one who'll be hung out to dry because the system wasn’t backed up properly.

How many of us feel good about our backup strategies? And how many of us perform a few simple operations that could put much of this uneasiness to rest? Those simple operations constitute an audit of the backups. Auditing involves running tests of your backup strategies to discover any holes in the plan. The effort can take as little as 30 minutes every three months; at the very least, auditing should be done twice a year.

What is an Audit?

Auditing your system requires a thorough understanding of what a good backup strategy entails. On every copy of OS/400 or i/OS, you should execute these save commands:

• Save System (SAVSYS)–-this includes licensed internal code, OS and security information
• Save Security Data (SAVSECDTA)
• Save configuration (SAVCFG)
• Save Library (SAVLIB)
• Save Document Object (SAVDLO)
• Save Object (SAV)

With the exception of SAVSYS, all of these commands should be executed daily. SAVSYS should be executed weekly, as should SAVLIB and SAV for IBM-supplied libraries and directories, respectively. For every copy of OS/400, there are different strategies and, of course, there are variations to these commands. For details, read, "Planning a backup and recovery strategy" at the IBM infocenter.

In i/OS, you can examine object descriptions, history log entries, the backup list, and some data areas to quickly determine if your system is being backed up. However, this doesn’t guarantee you'll know how to find the tape that contains the data. That's something you'll get only with a good manual logbook or one of the tape-management solutions on the market.

Save Data Areas

The QSYS library contains a series of data areas that are updated every time you run certain save commands. Although the following list isn’t all-encompassing, you can check these data areas to see if at least some of the save commands are being executed:

• QSAVALLUSR-SAVLIB LIB(*ALLUSR) (save of all user data libraries)
• QSAVGFG-SAVCFG (save of hardware configuration data)
• QSAVIBM-SAVLIB LIB(*IBM) (save of IBM libraries)
• QSAVLIBALL-SAVLIB LIB(*NONSYS) (save of all libraries)
• QSAVSTG-SAVSTG (dump of entire storage to media)
• QSAVSYS-SAVSYS (save of OS/400, licensed internal code and security information)
• QSAVUSRPRF-SAVSECDTA (save of profiles and authority information)

You might think you could find the last save date as a value stored within the associated data area using the Display Data Area (DSPDTAARA) command. However, the last save date is actually found in the object's description. When you use the command DSPOBJD OBJ(QSAYSYS) OBJTYP(*DTAARA), the save date of the object is the date of the last SAVSYS command. So, within seconds, you can tell if any system backup strategies have holes. These data areas don’t address the SAVDLO and SAV commands.

If you use the command WRKOBJ OBJ(QSYS/QSAV*) OBJTYPE(*DTAARA), you will be presented with the following display. Select option 8=Display Description to view the save date and time of the object. That is the date and time the associated operation(e.g. SAVSYS) was executed.

                               Work with Objects                                
                                                                                
 Type options, press Enter.                                                     
   2=Edit authority        3=Copy   4=Delete   5=Display authority   7=Rename   
   8=Display description   13=Change description                                
                                                                                
 Opt  Object      Type      Library     Attribute   Text                        
      QSAVALLUSR  *DTAARA   QSYS                    S/R DIRECTORY INFO FOR SAVE 
      QSAVCFG     *DTAARA   QSYS                    S/R DIRECTORY INFO FOR SAVE 
      QSAVIBM     *DTAARA   QSYS                    S/R DIRECTORY INFO FOR SAVE 
      QSAVLIBALL  *DTAARA   QSYS                    S/R DIRECTORY INFO FOR SAVE 
      QSAVSTG     *DTAARA   QSYS                    S/R DIRECTORY INFO FOR SAVE 
      QSAVSYS     *DTAARA   QSYS                    S/R DIRECTORY INFO FOR SAVE 
      QSAVUSRPRF  *DTAARA   QSYS                    S/R DIRECTORY INFO FOR REST 
                                                                                
                                                                                
                                                                                
                                                                                
                                                                         Bottom 
 Parameters for options 5, 7 and 13 or command                                  
 ===>                                                                           
 F3=Exit   F4=Prompt   F5=Refresh   F9=Retrieve   F11=Display names and types   
 F12=Cancel   F16=Repeat position to   F17=Position to                

Display Backup List

The Display Backup List(DSPBCKUPL) command is handy for summarizing, by library and folder, when these were last backed up. The display or report also lists whether the library or folder contents have changed since the last full backup.

DSPBCKUPL BCKUPL(*LIB)   List library backup dates  
DSPBCKUPL BCKUPL(*FLR)   List Folder backup dates

History Logs

i/OS history logs can provide good auditing information about how well backups are being executed on your system. Unfortunately, most users set up their systems to delete history logs after a few days. The more days of history logs you have, the better you can audit your backup. You should have at least seven days of history logs to examine.

To view the history log, execute the Display Log (DSPLOG) command. By default, this command shows the history log in a chronological sequence. It’s a lot of information to look through when searching for a problem, but if you know the message IDs you're searching for, you can speed up this process. OS/400 backup commands send predefined message IDs to QHST during SAVxxx operations. The following list shows message IDs for various save commands:

• CPC3701--Sent for each library that’s completely saved to media.
• CPC3722--Sent for each library that’s completely saved to a save file
• CPC9410--Completion message for SAVDLO saved completely to media
• CPC9063--Completion message for SAVDLO saved completely to save file
• CPC370C--Completion message for SAV save of directory completely to media
• CPC370D--completion message for SAV save of directory completely to save file
• CPF3771--Number of objects saved/not saved during SAVLIB command and is issued if not a complete save.
• CPF3837--Number of objects saved/not saved during SAV command and is issued if not a complete save.
• CPF9410--Number of objects saved/not saved during SAVDLO command and is issued if not a complete save.

The DSPLOG command allows you to specify a date and time range and to limit the list to a specific message ID or list of IDs. You can view the log on your display screen with the following command:

DSPLOG PERIOD((*AVAIL  121508))   MSGID(CPF3837  CPF9410)

Or, you may print the log to a printed report by specifying the OUTPUT parameter as shown here.

DSPLOG PERIOD((*AVAIL 121508)) OUTPUT(*PRINT) MSGID(CPF3837)

Displaying the history log at least guarantees you're executing these commands on a regular basis. It’s the first option, thus far, that shows any history of executing the SAV command on a system. It's also a good way to look for objects that aren't being saved. The message IDs given may vary for different i/OS release levels, and there are more message IDs that might be worth looking for in the backup and recovery area.

Auditing--A Continuous Process

As part of the audit process, you should evaluate the facility where you store your offsite media. You should also verify you have a proper procedure for recovering your data, as well as the proper materials to complete the restoration. You should have contact information for those staff members who can help you if you have any difficulties.

While auditing can't replace actual recovery testing, a thorough audit of your backup process can help you avoid problems when you test your recovery procedure. No matter how comfortable you feel about your strategy, take the time each quarter to check out your backups.