There are certain operational considerations that must be taken into account when performing a master backup and subsequent master restore.
To begin, system software cannot backup all iSeries data, such as licensed internal code and certain system libraries. Therefore, the iSeries software is not intended to perform as a bare metal product and cannot recover a system to its original state in the event of hardware or software failure. To enable disaster recovery, it is recommended that a GO SAVE option 21 or option 22 system backup is also performed periodically e.g. monthly as a supplemental system backup to ensure current critical files are available. For more information on GO SAVE command options access IBM’s Infocenter site at:
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=/rzarm/rzaiurzaiu209.htm
The iSeries software invokes the save-while-active option when performing backup operations. These operations require a brief lock in order to reach a stable checkpoint. An object with a prolonged conflicting lock may not be able to reach a valid checkpoint. When a library contains an object that fails to reach a checkpoint the default behavior is to skip the entire library. This behavior may be changed to backup the remainder of the library and skip only the objects that failed to reach a checkpoint. In this case it is logged that N files were not saved but the names of specific files skipped cannot be determined. This behavior can be changed by selecting Settings > System, Updates, and Licensing > General Configuration > Debugging and changing the iSeriesprecheck field from 1 (default) to 0. If an object is consistently skipped in this manner it may be a protected system object. In this case it can only be backed up in a restricted state.
Be sure to carefully configure your iSeries exclude list to properly identify the operating system files that are active and therefore should not be included in the master or incremental backup. Active iSeries files which cannot reach a suitable checkpoint will be excluded from the backup.
The backup and restore operations must run without conflict or interruption. There should be no other active jobs running during execution of a backup or restore job. Use the WRKACTJOB command to monitor all active jobs on the iSeries.
With Unitrends version 7.1 and higher, iSeries backups can be restored to the original server or to an alternate iSeries server. For earlier Unitrends versions, only restores to the original iSeries server are supported.
The following security guidelines should be adhered to prior to executing a master backup or restore.
The user performing the master backup or restore should, at a minimum, have *SECADM privileges added to their profile.
Files to be restored must have read-write attributes. This is accomplished on the OS400 operating system by granting object authority to the user performing the restore command. Following is an example of modifying security privileges in the QGPL and QUSRSYS libraries for user QSECOFR:
GRTOBJAUT OBJ(QGPL/*ALL) OBJTYPE(*ALL) USER(QSECOFR) AUT(*ALL)
GRTOBJAUT OBJ(QUSRSYS/*ALL) OBJTYPE(*ALL) USER(QSECOFR) AUT(*ALL)
Finally it Is important to understand that iSeries backups are not encrypted on the system and backups are compressed post-transmission.