Two Ways to Audit Your Backup Strategy
April 18, 2007 Hey, Joe
|
Nice article on five things that kill backups. In regards to auditing backup results, however, I find it a little tedious to check joblogs as you recommended. I prefer to use the Display Log command for reviewing the system history log to check backup results. It’s easy to spot missed objects from this display. I also like to use the Display Backup List command (DSPBCKUPL) for Sarbanes-Oxley compliance. –Bill Thanks, Bill for bringing up two ideas I hadn’t thought of when I wrote that article. Here are the details on what Bill is discussing and how it can help in your shop. The Display Log command (DSPLOG) shows all messages that are written to the system history log (QHST), including backup messages. If you want to retrieve your backup messages, you can easily access them by running DSPLOG with the name of your backup job in the Jobs to Display parameter (JOB). DSPLOG JOB(backup_job_name) Running DSPLOG this way will display all the backup messages generated during the current date for any job that ran under your backup job name. After running DSPLOG, you will see a set of system messages that look something like these. Job 381900/QSYSOPR/DAILYBKUP started on 04/10/07 at 01:00:00 in subsystem QSYSWRK in QSYS Volume XXXX not under media management control. All security objects saved. All configuration objects saved. 6050 objects saved from library LIB1. 1301 objects saved from library LIB2. 59 objects saved from library LIB3. Once the QHST messages are displayed, it’s a fairly easy task to run your finger down the screen and look for any library whose objects were not completely backed up. This allows you to quickly identify any problems with your backup job. You can also run DSPLOG so that it prints out backup messages to a spooled file that can be retained for your backup logs. To do that, you would run DSPLOG like this: DSPLOG LOG(QHST) OUTPUT(*PRINT) JOB(backup_job_name) The other trick to remember is that by default, DSPLOG will only display backup job messages that occurred on the current date. To view backup messages from another day or a range of days, you can fill in beginning and ending dates in the command’s Time period for log output parameter (PERIOD). To look at messages from yesterday through today, I could run DSPLOG with the following parameters: DSPLOG LOG(QHST) PERIOD((*AVAIL ’04/17/2007′)) JOB(backup_job_name) The *AVAIL literal tells DSPLOG to show me any QHST messages from the earliest available time of the beginning date, as specified in the first date of PERIOD. Since I only entered a beginning date, DSPLOG would show me any messages from any backup job that ran on April 17 or later. If I wanted to run the command showing all backup messages from April 15 through April 17, I could run DSPLOG this way. DSPLOG LOG(QHST) PERIOD((*AVAIL ’04/15/2007′) (*AVAIL ’04/17/2007′)) JOB(backup_job_name) The moral here is that you can use your system logs to audit your backup jobs. However, as Bill pointed out, system logs are not the only way to double-check your backup results. Another audit backup technique involves using one of the backup commands that IBM provides in its Backup Tasks menu (GO BACKUP). Unlike the Save menu (GO SAVE) which provides options for immediately backing up your entire system or different functions in the system (Files, libraries, documents, ect), the Backup Tasks menu allows you to set up a backup schedule for automatically running backup jobs. While reviewing the Backup Tasks menu is an article in itself, IBM provides one backup command that can help you with backup auditing, the Display Backup Library List command (DSPBCKUPL). You can run DSPBCKUPL to display the last dates your user libraries or folders were backed up, as well as whether any of the library objects in each library were changed since the last backup. If you’re running DSPBCKUPL without any parameters, you might see a display that looks something like this:
Display Library Backup List
System:
Find library . . . . . . Starting characters
Type options below, then press Enter.
5=Display library contents 8=Display details
-----------Backup----------- Last
Opt Library Daily Weekly Monthly Backup Changed
#LIBRARY Yes Yes Yes 04/10/07 No
LIB1 Yes Yes Yes 04/10/07 No
LIB2 Yes Yes Yes 04/10/07 Yes
LIB2 Yes Yes Yes 04/10/07 No
In its default format, DSPBCKUPL shows you all the user libraries on your system. If you want to see all your system folders and the last dates they were backed up, you can also run DSPBCKUPL like this. DSPBCKUPL BCKUPL(*FLR) While DSPBCKUPL doesn’t contain as much information as the QHST job messages you would retrieve with DSPLOG, it provides the following information. Last Backup: The last date when the entire library or folder was saved. Changed: A Yes or No field that designates whether any objects in the library of folder were changed since the last time that library/folder was saved. This information comes in handy if you’re trying to determine whether any libraries that don’t change on a regular basis should be omitted from a daily backup. If you are using DSPBCKUPL for auditing purposes, you can ignore the three fields under the Backup section (Daily, Weekly, and Monthly) because they pertain to whether these libraries will be saved by using the GO BACKUP commands. The nice thing about these two techniques is that they provide different pieces of information that speak to how complete your backup strategy is. Using DSPLOG allows you to determine whether your backup job saves all the libraries and objects you are intending to save. DSPBCKUPL records the latest dates that your user libraries and folders were backed up. Together, you can use them to audit and verify that your backup strategy is working correctly. While they may or may not meet Sarbanes-Oxley compliance, they do represent documentation that can be presented to an auditor. –Joe RELATED STORY
|
