IBM Support

Synchronization of source and target replication server after role change

Question & Answer


Question

Is it possible to switch the roles of the source and target replication servers, resync them and then switch them back to the original roles?

Tip: The information in this technote is for version 7. For instructions about IBM Spectrum Protect 8, see Synchronization of source and target replication servers after role reversal.

Cause

It would be helpful to get both Tivoli Storage Manager servers back in sync after the primary Tivoli Storage Manager server goes down for an extended time and the administrator wants to store data on the target replication server meanwhile.
Then, when the primary (source) server returns to service, replicate the data stored on the target replication server back to the (old) source replication server and make this server the (old=new) source server again.

Answer

Notes:
a.) A problem has been discovered when synchronizing the target server to the source server. Active files on the source server can be set to inactive when the target server synchronizes the files that were stored while the source server was unavailable. Avoid using these steps until the fix for IC92876 is available in Tivoli Storage Manager 6.3.5 (or above) and 7.1.0 (or above, though we really recommend to be at 7.1.1.100 as the minimum V7.1 level).

b.) Starting with Tivoli Storage Manager Version 7.1.1, there is a more advanced possibility available to recover damaged files from a replication server. See "Recovering damaged files from a replication server" in the IBM Documentation (URL below).



########################################################################################

In the following example are:
PRODSRV: The production (source) Tivoli Storage Manager server for backup of node NODE1
DRSRV: The target replication server, in the case, that the source server (PRODSRV) is alive
NODE1: The Tivoli Storage Manager client node
  1. With PRODSRV unavailable, update the node on the DRSRV server to allow it to accept backup data for NODE1 by issuing REMOVE REPLNODE NODE1. This sets NODE1 as a non-replicating node.
  2. Switch the client node NODE1 to point to DRSRV.
  3. All store operations for NODE1 are now directed to the DRSRV server. Because NODE1 is configured as a normal, non-replicated node, data can be stored.
  4. At some point, PRODSRV comes back online.
  5. Update the node definition for node NODE1 on PRODSRV to be a non-replicating node; REMOVE REPLNODE NODE1.
  6. Setup replication again to synchronize the servers by updating the node on the DRSRV server with REPLSTATE=ENABLED, REPLMODE=SYNCSEND. Then, update the node definition on the PRODSRV server with REPLSTATE=ENABLED, REPLMODE=SYNCRECEIVE. This will synchronize the inventories of both Tivoli Storage Manager servers during the next replication.
  7. Be sure to set the replication rule to ALL_DATA. The reason for this is that we want to send all data stored on DRSRV for NODE1 back to PRODSRV; even though not all data was being replicated originally.

    For example, if on PRODSRV, the filespace /FS1 contains backup, archive and, space-managed data belonging to NODE1. The backup and archive replication rules are set to ALL_DATA and its space-managed rules are set to NONE. That means all backup and archive data in /FS1 is replicated to DRSRV (this assumes that the node and system-wide replication rules are set to their default) while no space-managed data is sent. When DRSERVER is in the failover mode it receives backup, archive and space managed data from NODE1. This data must be replicated in order to ensure that no data are lost. If the space-managed replication rule is set to NONE for /FS1 on DRSRV as it was on PRODSRV, then no space-managed data would be synchronized (replicated from DRSRV to PRODSRV). Finally, when PRODSRV resumes responsibility as the source server, the space-managed data that was stored on DRSRV and not replicated is lost. In this example, because the space-managed replication rule on PRODSRV is set to NONE, when replication occurs the space-managed data on DRSRV is deleted and gone forever.
  8. On DRSRV set the default replication server by issuing the following command: SET REPLSERVER PRODSRV

    There should already be a server definition for PRODSRV since it was needed for replication previously.
  9. Perform replication of NODE1 on the DRSRV server to sync up the servers. Once, the replication completes the node definition on the target server will be set to REPLMODE=SEND and the node definition on the PRODSRV server with REPLMODE=RECEIVE.
  10. Now update both node definitions to be non-replicating nodes by issuing REMOVE REPLNODE NODE1
  11. We now need to set up NODE1 so that the PRODSRV is the source server and DRSRV is the target server again. Synchronize the nodes by updating the node on the DRSRV server with REPLSTATE=ENABLED, REPLMODE=SYNCRECEIVE. Then, update the node definition on the PRODSRV server with REPLSTATE=ENABLED, REPLMODE=SYNCSEND.
  12. Perform replication of NODE1 on the PRODSRV server. Once, the replication completes the node definition on the PRODSRV server will be set to REPLMODE=SEND and the node definition on the DRSRV server with REPLMODE=RECEIVE.

At this point, the two servers are in the original configuration and PRODSRV has the data stored to DRSRV while it was down.

[{"Product":{"code":"SSGSG7","label":"Tivoli Storage Manager"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Server","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"6.3;6.4;7.1","Edition":"","Line of Business":{"code":"LOB26","label":"Storage"}}]

Document Information

Modified date:
08 December 2021

UID

swg21628618

Page Feedback