Use FlashCopy to take a snapshot of your IASP
BRMS saves write to BRMS media. A BRMS system can only perform saves to BRMS media that it owns. Each save generates data, referred to here as save history. Media may contain save history for multiple saves. The save history for each save on media is owned by a BRMS system. It is possible that each save history may be owned by different systems and also be different than the system that owns the media itself. The following discussion involves save history and save history owners, it does not involve the owner of the media itself.
The existing BRMS function of receiving save history remains unchanged. That function meets the needs of many customers, but in large BRMS network groups excessive amounts of undesired network traffic and database records are sent to all of the BRMS systems receiving save history. For example, a cluster may consist of three systems: Production, High Availability (HA) and a Backup. The save history from a Backup system is only relevant to the Production and High Availability systems, but it is being synchronized and stored on all the systems in the BRMS network group. This is significant when there can be a hundred or more systems in the BRMS network group.
The new function described herein allows the BRMS system generating the save history (i.e. performing the backups) to determine which systems will receive the save history, and whether the systems should own the save history. Thus, the Backup system of a cluster can specify which system will receive the save history for a specific IASP. In addition to selecting the target system, if the option to change the save history owner is implemented, it will appear as if the target system performed the backup. In other words, if the backup of library LIBA on IASP 33 (named "IASP01") was performed on the Backup system, when it is synchronized to the Production and HA systems with a change in ownership, the Production and HA systems can view the backup of library LIBA on iASP01 as if it occurred locally. STRRCYBRM ACTION(*RESTORE)
will display the library, and if the IASP is available and has LIBA on it, the recovery report will show recovery steps for LIBA in IASP01.
Library-level save history can be synchronized to specific systems and the system owner of the synchronized data can be changed to make it appear as if the backup occurred on the target system. The following green screen interfaces can be used to setup the system synchronization environment:
NOTE: This setup only needs to be done once on the system that is performing the backup.
Use the following to reference the parameters in the commands listed below:
IMPORTANT: All entries need to be in upper-case characters
To add a specific system sync, change the system name to make it look like the backup was done by this system and synchronize the reference date/time:
CALL QBRM/Q1AOLD PARM('HSTUPDSYNC' '*ADD' 'SYSTEM' 'NETWORK ID' 'IASPNAME' '*CHGSYSNAM')
To add a specific system sync, keep the name of who did the backup and synchronize the reference date/time:
CALL QBRM/Q1AOLD PARM('HSTUPDSYNC' '*ADD' 'SYSTEM' 'NETWORK ID' 'IASPNAME ' '*NORMAL')
To remove a specific system:
CALL QBRM/Q1AOLD PARM('HSTUPDSYNC' '*REMOVE' 'SYSTEM' 'NETWORK ID' 'IASPNAME ' )
To remove all systems:
CALL QBRM/Q1AOLD PARM('HSTUPDSYNC' '*REMOVE' '*ALL')
To display what is currently setup:
CALL QBRM/Q1AOLD PARM('HSTUPDSYNC' '*DISPLAY')
Specific System Synchronization support for *SYSBAS
With the increased use of High Availability (HA) strategies and replication software being utilized in IBM i system environments, the BRMS recovery report needs be able to combine two systems backups into a single recovery report. The goal of this combined recovery report is to prevent replicated data from being saved multiple times, yet still being available for recovery from any system. To achieve this, the Specific System Synchronization support for IASP is being enhanced to additionally include support for *SYSBAS available in versions 7.3 and later with the following PTFs:
7.5 SI78291
7.4 SI78290
7.3 SI78289
To activate this behavior, run the following command on the target HA system:
CALL QBRM/Q1AOLD ('HSTUPDSYNC' '*ADD' 'Source_HA_System_Name' 'Source_HA_Network_ID' '*SYSBAS' '*CHGSYSNAM')
IMPORTANT: All entries need to be in upper-case characters
Once activated, history for non-system related backups on the Target HA System will be synced to the new owning system (the Source HA System) with the system name changed to make it appear that the backup was run on the new owning system.
The following backup history will NOT be synced:
*SAVSYS
*SAVCFG
*SAVSECDTA
System libraries (Library names that start with 'Q')
Libraries that start with # that are system libraries:
#CGULIB, #COBLIB, #DFULIB, #DSULIB, #RPGLIB, #SDALIB, #SEULIB
Recovery reports run on the Source HA system will now combine all backups run on the Source HA System and all non-system backups from the Target HA System.
To disable this behavior, run one of the following commands on the target HA system.
To stop all syncing of history to the Source HA System:
CALL QBRM/Q1AOLD ('HSTUPDSYNC' '*REMOVE' 'Source_HA_System_Name' 'Source_HA_Network_ID' '*SYSBAS')
To continue syncing history, but without changing the owning system of the history:
CALL QBRM/Q1AOLD ('HSTUPDSYNC' '*ADD' 'Source_HA_System_Name' 'Source_HA_Network_ID' '*SYSBAS' '*NORMAL')
NOTES: