Synchronization of source and target replication servers after role reversal

If a source replication server fails or becomes temporarily unavailable, you might have to reverse the server roles and temporarily configure the target replication server as the source replication server. Later, when the original source replication server is back online, you can restore the original roles. Then, you can replicate all data from the target replication server to the source replication server and synchronize the data on both servers. If you configure multi-target replication by using replication storage rules, you have an additional option to help ensure data availability and recovery if the source replication server fails. When you replicate data to two target replication servers, you can convert one of the target replication servers to a source replication server. The data from the newly established source replication server can then be replicated to another target replication server by using replication storage rules to help provide uninterrupted data protection.

Example for reversing server roles in a single-target replication environment

The following values are used in this example:

NODE1 is the client node.
PRODSRV is the source replication server to which data from the client node, NODE1, is backed up.
DRSRV is the target replication server.

The PRODSRV server becomes unavailable. The system administrator, Elizabeth, updates the node definition on the DRSRV server to revoke PRODSRV server's role as the target of backup data for NODE1. She follows the instructions in REMOVE REPLNODE (Remove a client node from replication) and issues the following command on the DRSRV server:
```
remove replnode node1 server=prodsrv
```
By setting NODE1 as a non-replicating node, DRSRV can now be used as a source replication server for backing up the client data.
Elizabeth configures NODE1 to back up data to the DRSRV server. To achieve this, she must update the appropriate client options file.

Elizabeth reconfigures the appropriate client options file by following the instructions in Creating and modifying the client system-options file and Creating and modifying the client options file.

All backup operations for NODE1 are now directed to the DRSRV server.

After some time, the PRODSRV server comes back online. Elizabeth intends to restore the original storage setup.
She updates the node definition for NODE1 on the DRSRV server to be a non-replicating node. She issues the following command on the PRODSRV server:
```
remove replnode node1 server=drsrv
```
To start the process of synchronizing the servers, Elizabeth follows the instructions in UPDATE NODE (Update node attributes) and issues the following commands.
She issues the following command on the DRSRV server:
```
update node node1 replstate=enabled replmode=syncsend
```
She issues the following command on the PRODSRV server:
```
update node node1 replstate=enabled replmode=syncreceive
```
After these commands are run, the inventories of both IBM Spectrum Protect servers will be synchronized during the next replication operation.
To replicate all data from the DRSRV server to the PRODSRV server, Elizabeth defines a replication storage rule. She follows the instructions in DEFINE STGRULE (Define a storage rule for replicating data) and issues the following command on the DRSRV server:
```
define stgrule repl_role_reversal prodsrv actiontype=replicate
```
By issuing the command, she establishes the PRODSRV server as the default target replication server for the DRSRV server.
To synchronize the servers, Elizabeth follows the instructions in START STGRULE (Start a replication rule) and issues the START STGRULE command to replicate the data.
She issues the following command on the DRSRV server:
```
start stgrule repl_role_reversal
```
After the replication operation, the node definition on the DRSRV server is set to REPLMODE=SEND. The node definition on the PRODSRV server is set to REPLMODE=RECEIVE.
Elizabeth waits for the replication operation to be completed successfully before proceeding to the next step. Waiting for completion of the replication operation is mandatory.
Elizabeth updates the node definitions on the PRODSRV and DRSRV servers to set them as non-replicating nodes.
She issues the following command on the DRSRV server:
```
remove replnode node1 server=prodsrv
```
She issues the following command on PRODSRV server:
```
remove replnode node1 server=drsrv
```
Elizabeth configures the NODE1 node to set PRODSRV as the source replication server and DRSRV as the target replication server. She synchronizes the nodes on both servers by issuing the following commands.
She issues the following command on the PRODSRV server:
```
update node node1 replstate=enabled replmode=syncsend
```
She issues the following command on the DRSRV server:
```
update node node1 replstate=enabled replmode=syncreceive
```
Elizabeth configures the NODE1 node to back up data to the PRODSRV server by updating the appropriate client options file.

She follows the instructions in Creating and modifying the client system-options file and Creating and modifying the client options file.

All backup operations for the NODE1 node are now directed to the PRODSRV server.
Elizabeth defines a replication storage rule to configure replication of data from the NODE1 node on the PRODSRV server to the DRSRV server.
She issues the following command on the PRODSRV server:
```
define stgrule repl_drsrv drsrv actiontype=replicate
```
She runs the replication storage rule, REPL_DRSRV. After the replication operation is completed successfully, the node definition on the PRODSRV server is set to REPLMODE=SEND and the node definition on the DRSRV server is set to REPLMODE=RECEIVE.

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