Admin Alert: Quick Audits for i5/OS Backups
June 4, 2008 Joe Hertvik
|
In many shops, Sarbanes-Oxley and other regulations require iSeries, System i, and Power i administrators to audit their backup procedures and to keep records showing that regular backups are being administered and that their backups are working as advertised. To help with this effort, this week I’ll review a few common i5/OS commands and parameters that can make your backup auditing process easier to document. Two Alternatives for Auditing Backups When using an i5/OS or OS/400 SAVxxx command, it’s common to have the command produce a report detailing backup results by running the SAVxxx command like this: SAVLIB LIB(lib parameter) DEV(device_name) OUTPUT(*PRINT) In this example, I ran the Save Library (SAVLIB) command, which can be used to save individual libraries (LIB parameter = the library name), all libraries except the system libraries (LIB = *NONSYS), all user libraries (LIB = *ALLUSR), or all IBM supplied libraries (LIB = *IBM). The techniques I’m discussing here apply to almost all the other i5/OS and OS/400 SAVxxx commands that deal with native i5/OS objects (SAVLIB, SAVCHGOBJ, and SAVOBJ). Be warned, however, that the techniques I’ll be presenting don’t work for the Save Object (SAV) and Save DLO Library Object (SAVDLO) commands that save AS/400 Integrated File System and Folder objects. With the SAVxxx commands, the critical item to note is that the Output parameter (OUTPUT) for my SAVLIB example is set to *PRINT, which creates a report noting every library that the command attempted to backup, as well as all the objects in that library and whether or not each object was backed up. If you’re backing up a large number of objects such as all your non-system libraries, this report can be incredibly long, which can make more difficult to print, review, and store. To get around this limitation and to produce a more compact report showing when individual i5/OS libraries were last backed up and which libraries have changed objects since the last backup, you can also run the following commands.
I’ll use the rest of this article to show you how to use these two commands to produce a slimmed down audit report after backup. Using DSPBCKUPL To Check Up on Your Library Backups The Display Backup Library (DSPBCKUPL) command is a useful command for checking the following things:
The command is relatively easy to use. If you wanted to view backup information for all the user libraries on your system, you would run DSPBCKUPL this way: DSPBCKUPL BCKUPL(*LIB) And the system will display the following screen. 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
QMGTC2 Yes Yes Yes 05/25/08 Yes
QMPGDATA Yes Yes Yes 05/25/08 Yes
QPFRDATA Yes Yes Yes 05/25/08 Yes
QRCL Yes Yes Yes 05/25/08 No
QSRVAGT Yes Yes Yes 05/25/08 Yes
QSYS2 Yes Yes Yes 05/25/08 No
QS36F Yes Yes Yes 05/25/08 No
QUSRDIRDB Yes Yes Yes 05/25/08 Yes
QUSRINFSKR Yes Yes Yes 05/25/08 No
QUSRSYS Yes Yes Yes 05/25/08 Yes
F1=Help F3=Exit F5=Refresh F11=Display descriptions F12=Cancel
F14=Select other libraries
The screen lists out all the user libraries on your system along with their related parameters. If you’re not using i5/OS Operational Assistant to perform your backup, you can ignore the Daily, Weekly, and Monthly parameters listed on this screen, as these parameters relate to that backup strategy. For backup auditing, the two fields that you’re interested in on this screen are the Last Backup field and the Changed field. The Last Backup field shows the last date each particular library was backed up, while the Changed field shows whether or not any objects in the library have changed since the last backup. While the default settings display this information on a 5250 green screen, DSPBCKUPL info can also be generated to a spooled file. To do that, run the DSPBCKUPL this way: DSPBCKUPL BCKUPL(*LIB) OUTPUT(*PRINT) With the OUTPUT parameter set to *PRINT, DSPBCKUPL will output the report to a spooled file that can be printed and retained to show your auditors the next time they show up. If you want to modify DSPBCKUPL to display system folders instead of libraries, run the command this way: DSPBCKUPL BCKUPL(*FLR) And folder information will be displayed instead of library information. If you want to print the folder information, run the command like this: DSPBCKUPL BCKUPL(*FLR) OUTPUT(*PRINT) DSPBCKUPL’s strength is that you can use it to help document that you’re backing up all critical libraries or folders on your system. The command’s primary weakness is that it only displays limited information and your specific auditing needs may require you to get a more comprehensive view of your backups. Another weakness is that the command will only display information for user libraries and folders. It does not produce backup information for IBM system libraries, the AS/400 IFS, and shared folders (DLO). Configuring SAVxxx Commands to Pinpoint Objects that Weren’t Backed Up The biggest problem with the SAVxxx output reports is that they produce too much information, and it can be hard to easily scan the report to find objects that weren’t backed up. Fortunately, there’s another SAVxxx parameter that can cut down on backup report clutter by creating a smaller output file for effective backup report creation. In this case, the critical setting is the Type of Information parameter (INFTYPE) on the SAVxxx command. INFTYPE’s job is to specify what kind of information is contained in the spooled files or database files that contain the results of your save. If you run the command as shown at the beginning of this article, like this: SAVLIB LIB(lib parameter) DEV(device_name) OUTPUT(*PRINT) You’ll get a report listing out both the library name and the status of the save command as it was run over every single object in the library. If you ran this report over the QUSRSYS lib, for example, you would get a printout that looked something like this: 5722SS1 V5R3M0 040528 Save Library - Object Information Library . . . . . . . : QUSRSYS Save date/time . . . . : 05/28/08 21:00:08 Object Type Attribute Saved Size Owner QZMF4138 *JRNRCV YES 1183744 QSYS QZMF4139 *JRNRCV YES 110592 QSYS QZMF4140 *JRNRCV YES 1445888 QSYS CLICKLOG *FILE NO * CPF3741 ECOMDERROR *FILE NO * CPF3741 ECOMDLOG *FILE NO * CPF3741 ERRORLOG *FILE NO * CPF3741 QAOKP01A *FILE NO * CPF3741 QAOKP09A *FILE NO * CPF3741 In its default format, the SAVxxx report lists out what happened as the command tried to save all the objects in its target libraries. This is because the default setting for the command’s INFTYPE parameter is *OBJ, which tells the command to create an entry for each object that was requested to be saved. To cull the herd and to only retrieve the information about which libraries were saved and which objects the command was unable to save, you have to make two adjustments. First, you have to change the command so that it no longer prints your SAVxxx command information. Rather, you need to output the save attempt information to a database, as that is the only command configuration this particular technique allows. You can specify that command output should go to a particular database by changing the SAVxxx Output parameter (OUTPUT) to *OUTFILE and the File to receive output parameter (OUTFILE) to the name of a database file that you want to contain the result information. The second adjustment is to change the command’s INFTYPE parameter to *ERR, which tells the command to only create two types of entries: a record for each library that the command attempted to save; and a record for each object in the saved library that the command was unable to save. By making these two changes, your new SAVLIB command will look like this: SAVLIB LIB(lib parameter) DEV(device type) OUTPUT(*OUTFILE) OUTFILE(lib name/file name) INFTYPE(*ERR) After you run this command, you’ll have a database that contains entries listing out the names of the libs that were backed up by using the command, the number of objects that were saved in each library, and the name and number of objects that the command wasn’t able to back up. You can then print this file and you’ll have an auditable report that you can show to your auditors when the time comes. Like the DSPBCKUPL command, this technique works well with the SAVxxx commands, but as far as I know there aren’t comparable features for producing this database when saving objects from the AS/400 Integrated File System (AS/400 IFS) or when saving shared folders by using the Save Document Library Object (SAVDLO) command. About Our Testing Environment Configurations described in this article were tested on multiple i5 550 boxes running i5/OS V5R3 and V5R4. Most of the commands shown here are available in earlier versions of the operating system running on iSeries or AS/400 machines. If a command or function is present in earlier versions of the i5/OS or OS/400 operating systems, you may notice some variations in the pre-V5R4 copies of these commands. These differences may be due to command improvements that have occurred from release to release.
|
