IASP FlashCopy

Use FlashCopy to take a snapshot of your IASP

• Recovering and Printing Reports in an iASP Flash Copy Environment

Specific System Synchronization

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:

• Parm 1: HSTUPDSYNC  (NOTE: This is required)
• Parm 2 - Action
  • *ADD
  • *REMOVE
  • *DISPLAY
• Parm 3 - *ALL or System name of the system you want BRMS to give ownership to
  • Not required if Parm 2 is *REMOVE
  • *ALL is only valid is Parm 2 is *REMOVE
• Parm 4 - System network ID of the system your want BRMS to give ownership too.
  • Not required if Parm 2 is *REMOVE or *DISPLAY
• Parm 5 - IASP name that is saved
  • Not required if Parm 2 is *REMOVE or *DISPLAY
• Parm 6 - *CHGSYSNAM - Required
  • Not required if Parm 2 is *REMOVE or *DISPLAY

IMPORTANT: All entries need to be in upper-case characters

Examples

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: 

1. Only libraries and IFS data backed up from an IASP can have it's ownership changed prior to the June 2022 PTFs mentioned above. Items saved from *SYSBAS are not supported until the June 2022 PTFs are applied.
2. Data backed up to save files or TSM will not be synchronized.
3. Object level detail is not synchronized and will only be available on the system that did the backup.
   • The following commands will not list any data
     • WRKOBJBRM
     • WRKMEDIBRM Option 9
     • WRKLNKBRM DIR(/MYDIR1)
   • Use the FROMSYS() parameter on the above commands to view/restore individual objects or use WRKMEDBRM VOL(xxxxxx)
4. Works with reports created via Start Recovery using BRM (STRRCYBRM) and Start Maintenance for BRM (STRMNTBRM)
5. Volume ownership will remain with the system that did the original backup
6. If using this option, STRRCYBRM ASPDEV(XXXXXXXX *ALL) - where XXXXXXX is the flash copy system - will no longer work. *LCL needs to be specified for this parameter.
7. If planning on duplicating the volumes with DUPMEDBRM ,
   • The volume(s) need to be duplicated on the system that did the backup or,
   • Duplicate history ownership will be lost if remote duplicates are done.
8. When using STRRCYBRM OPTION(*ASPDEV) ASPDEV((XXXXXXX IASPNAME)), the libraries have to exist in the IASP of the system where the command is being run.
9. Saves to BRMS save files are not synchronized between systems
10. If the target LPAR is at a higher release than the source LPAR, *ALLUSR cannot be used. Individual or generic library names would have to be used.
    • If LIB(*NONSYS), LIB(*ALLUSR), or LIB(*IBM) is specified, only the current release can be the target release.