Backup

Backing up your data when using Db2® Mirror has some additional considerations.

Backup strategy

Primary node backup

Perform full system backups on the primary node. Full system backups will save both replicated and non-replicated data.

Use option 21 from the GO SAVE menu to back up the full system.

Notes:
  1. Save option 21 performs an ENDSBS *ALL; therefore it is considered a planned outage. To allow production work to continue, you must perform a role swap before and after the option 21 backup so the save is run on the secondary node. See Planned outages for more information.
  2. Ensure data area QTEMP/SRMIRCTL does NOT exist prior to starting the GO SAVE 21.
  3. All independent auxiliary storage pools (IASPs) that are registered for database replication must be in AVAILABLE state on the primary node.
  4. Any IASPs that are not registered for database replication that you want to back up must be made AVAILABLE so their IASP data is included in the backup.
  5. IBM® recommends that non-replicated objects with the same library qualified names do not exist on both the primary and secondary nodes.
  6. If a full system FlashCopy® of the primary node exists, the full system backup can be done using that system. Since the save is done on a different system, there are restore considerations, see Restoring objects from the mirrored node in Restoring specific types of information.

Secondary node backup

Since replicated data is backed up on the primary node, only non-replicated data needs to be backed up on the secondary node. To omit the replicated data from the backup of the secondary node, create data area QTEMP/SRMIRCTL before starting the backup: 
CRTDTAARA DTAARA(QTEMP/SRMIRCTL) TYPE(*CHAR) VALUE('1')

After the data area is created, use option 23 from the GO SAVE menu to save all user data.

Notes:
  1. Primary and secondary independent auxiliary storage pools (IASPs) that are registered for database replication must be in AVAILABLE status on the secondary node.
  2. Any IASPs that are not registered for database replication that you want to back up must be made AVAILABLE so the data is included in the backup.
  3. IFS IASPs that were backed up on the primary node should not be made AVAILABLE on the secondary node.
  4. If a full system FlashCopy of the secondary node exists, the full system backup can be done using that system. Since the save is done on a different system, there are restore considerations, see Restoring objects from the mirrored node in Restoring specific types of information.

Locking

Save operations lock objects on a node as described in Save-while-active object locking rules. These locks will restrict operations on replicated objects on both the source node and the target node.

Storage (STG) parameter

The Storage (STG) parameter can be used on save commands to free object storage as part of the save operation. However, the STG parameter is ignored for replicated objects. For more information about freeing storage, see Freeing storage when saving.