Auditing Your Backups, Part 1: Getting Started
Does this sound familiar? Your limited budget contains no money for a “hot site”, so you’ve never tested your backup process to see if you can actually restore your system. You do know that if you must restore your system and can’t, you’ll be in trouble—all alone on an island because your system wasn’t backed up properly.
I hope this doesn’t sound familiar. But, do you feel good about your backup strategies? You can perform a simple operation to put your uneasiness to rest: audit your backups. Run independent checks of your backup strategies (takes about 30 minutes) a few times a year to look for holes in your backup plan.
What Is A Backup Audit?
Auditing your backups requires a thorough understanding of a good backup strategy. On each copy of the operating system, you should execute the following save commands:
- Save System (SAVSYS)—includes licensed internal code, operating system, and security information
- Save Security Data (SAVESECDTA)
- Save configuration (SAVCFG)
- Save Library (SAVLIB)
- Save Document Object (SAVEDLO)
- Save Object (SAV)
Execute the SAVSYS command weekly, as well as SAVLIB for IBM-supplied libraries and SAV for directories. Execute the other commands daily. For each version of the operating system, there are different strategies and variations to these commands. For details, read, Planning a Backup Strategy on IBM’s iSeries Information Center Web site at www.ibm.com/iseries/infocenter. Just select Go, Systems Management, and Backup, Recovery and Availability.
In the operating system, you can examine object descriptions, history log entries, PRTSYSINF, and some data areas to quickly determine whether your system is being backed up. That doesn’t guarantee you’ll know how to find the tape that contains the data. For that, you need a good manual logbook or a tape management solution.
Save Data Areas
The QSYS library contains a series of data areas that are updated every time you run certain save commands. Check these data areas to see whether some save commands are being executed (this list isn’t exhaustive):
| Command |
Result |
| QSAVALLUSR-SAVLIB LIB(*ALLUSR) | Saves all user data libraries |
| QSAVGFG-SAVCFG | Saves hardware configuration data |
| QSAVIBM-SAVLIB LIB(*IBM) | Saves IBM libraries |
| QSAVLIBALL-SAVLIB LIB(*NONSYS) | Saves all libraries |
| QSAVSTG-SAVSTG | Dumps entire storage to media |
| QSAVSYS-SAVSYS | Saves operating system, licensed internal code, and security information |
| QSAVUSRPRF-SAVSECDTA | Saves profiles and authority information |
You might think you could examine the internals of the Display Data Area (DSPDTAARA) command on any of these data areas to see when the command was executed. However, this isn’t so. You must use following the Display Object Description (DSPOBJD) command for the data area and look at when the save date value on this object description was updated:
DSPOBJD OBJ(QSYS/QSAV*) OBJTYP(*DTAARA)
This command displays the last time one of these commands was executed. Within seconds, you can tell if any of your system backup strategies have holes. Remember, these data areas don’t address the SAVDLO and SAV commands.
Print System Information (PRTSYSINF)
The PRTSYSINF command is great for summarizing, by library and folder, when data holders where last backed up. The downside is that it generates about twenty reports. Ideally, IBM should add a parameter, or allow you to place the information in a database file. The spooled file, QPEZBCKUP, contains the information. This command doesn’t address SAVSYS, SAVSECDTA, SAVCFG, or SAV saves, nor does it address whether individual objects were backed up.
For most of us, critical business data is still stored in libraries, folders, and directories. So verify backups for directories and the operating system. These areas can cause grief if you don’t have good backups. Next time, we’ll talk about the importance of history logs. Stay tuned…





Comments
Post new comment