Auditing Your Backups, Part 3: System Objects and More

We’ve been talking about running independent checks of your data backup strategies to look for holes in your backup and restoration plan. First, we covered printing system information and save data areas. Then, we talked about history logs. Now, we’ll wrap things up by taking a look at the rest of your data backup and recovery information.

Object Descriptions

Every object on the system can be updated with the date it was last saved by using one of the save commands. Every save command has an Update Save History parameter. With updated save information, you can dump an object to paper or to an outfile (a database file that some commands create as output), and query the results to see whether the object was ever saved. For example, all of the library descriptions on the system reside in the QSYS library. Every time a SAVLIB command is executed, the save information in each library description is updated. You can use the following command to send the results to an outfile and query those results:

DSPOBJD OBJ(QSYS/*ALL) OBJTYPE(*LIB)

In the query, you might look for libraries that have never been backed up. You can use the same command to put all the output, for every object in all libraries, into an outfile and query these results to locate any objects that have never been saved.

Outfile Support On Save Commands

Every save command supports the OUTPUT parameter, which generates a database file summarizing the results of each save operation. If you execute the SAVLIB command against the QUSRSYS library, the outfile lists all objects that were (or weren’t) saved during the operation. Just query this file for objects that weren’t backed up. If you turn this feature on, be sure to examine the output. Otherwise, it only causes overhead.

Many tape-management packages use the OUTPUT parameter to build an inventory of which objects are saved on which volume. It’s handy for keeping an up-to-date inventory of what was saved. The SAV command doesn’t support outfiles, but you can direct the output to a report or stream file. This type of report is useful for auditing because you can limit it to the errors that occurred during the SAV operation (usually the results of object locks).

Final Details

Remember to audit the facility where you store your off-site media and verify that you have a procedure and materials for recovering you data, as well as contact information for staff members who can help. Finally, have hard copies of IBM’s Backup and Recovery Manual (SC41-5304-05), available on the iSeries Information Web site. (The link is included in the “Planning a Backup Strategy” document on IBM’s iSeries Information Center Web site at www.ibm.com/iseries/infocenter.)

Summary

Auditing can’t replace recovery testing, but a thorough audit of your backup process can help you avoid problems with your data backup and recovery procedures. No matter how comfortable you feel about your data recovery strategy, take the time each quarter to check your backups. Start auditing your data backups and you’ll have no regrets down the road.