Configuring node replication for IBM

Spectrum Protect by using the command line

se replication to recover data at a disaster recovery site and to maintain the same level of files on the
source and target servers. You can manage replication at the node level. You can also protect data at
the storage-pool level.

Steps
To configure node replication by using the command line, complete the following steps:
1. Run the SET SERVERPASSWORD command on both servers. Specify a different password for
each server and make a note of each password for future reference. For example, if the source
replication server is named IBMSERVER1, you can specify the password K_-rL*b^#DtzNTA#dM^Y
by issuing the following command:
Protect: IBMSERVER1>set serverpassword K_-rL*b^#DtzNTA#dM^Y
If the target replication server is named IBMSERVER2, you can specify the password
aEUBaUHpHauAaQVa2RkT by issuing the following command:
Protect: IBMSERVER2>set serverpassword aEUBaUHpHauAaQVa2RkT
2. To establish communication between the source and target replication servers, complete the
following steps:
a) Define the destination of the target replication server to the source replication server by running
the DEFINE SERVER command on the source server:
define server target_server_name hladdress=ipaddress_target_server
lladdress=1500 ssl=yes serverpassword=target_server_password
Tip: The LLADDRESS parameter in the example has a value of 1500, however, you can specify in
the range of values 1 - 32767.
The following example shows the target replication server, IBMSERVER2, defined to the source
replication server:
define server "IBMSERVER2" hla=10.12.5.80 lla=1500 ssl=yes
serverpassword="aEUBaUHpHauAaQVa2RkT"
b) Define the source replication server to the target replication server by running the DEFINE
SERVER command on the target replication server:
define server source_server_name hladdress=ipaddress_target_server
lladdress=1500 ssl=yes serverpassword=source_server_password
Tip: The LLADDRESS parameter in the example has a value of 1500, however, you can specify in
the range of values 1 - 32767.
The following example shows the source replication server, IBMSERVER1, defined to the target
replication server:
define server "IBMSERVER1" hla=10.12.5.86 lla=1500 serverpassword="K_-rL*b^#DtzNTA#dM^Y"

3. To verify connectivity between the source replication server and the target replication server, issue
the PING SERVER command. 
a) For example, to verify connectivity to the target replication server, IBMSERVER2, issue the
following command from the source replication server:
ping server IBMSERVER2
b) To verify connectivity to the source replication server, IBMSERVER1, issue the following
command from the target replication server:
ping server IBMSERVER1
Tip: For disaster recovery purposes, it is useful to test that a server is active at a disaster recovery site
by using the PING SERVER command.
 
4. Set the name of the target replication server, IBMSERVER2, by issuing the SET
REPLSERVER command on the source replication server. For example, issue the following
command:
set replserver IBMSERVER2

5. Enable storage pool protection by completing the following steps:

a) Update the storage pool on the source replication server, STGPOOL_SRC, to specify the name of
the storage pool on the target replication server, STGPOOL_TGT, by issuing the following command:
update stgpool stgpool_src protectstgpool=stgpool_tgt
b) Protect the storage pool on the source replication server by issuing the PROTECT
STGPOOL command:
protect stgpool stgpool_src type=replserver
Tips: 
 You must use container storage pools with the PROTECT STGPOOL command.
 To view the progress of the storage pool protection, issue the QUERY PROCESS command.
6. After storage pool protection is complete, complete the following steps:
a) Compare the policies for client nodes on the source replication server with the same policies on the
target replication server where the client node data is being replicated. To display the differences
between the policies on the source replication server and the policies on the target replication server,
IBMSERVER2, issue the VALIDATE REPLPOLICY command on the source replication server:
validate replpolicy IBMSERVER2
Tip: To validate a replication policy, at least one node must be registered.

b). You can set policies on the target replication server that manage the replicated client-node data
differently than on the source server. For example, you can maintain a different number of versions of
files on the source and the target servers. Enable policies on the target replication server,
IBMSERVER2, to manage replicated client-node data by issuing the SET
DISSIMILARPOLICIES on the source replication server:
set dissimilarpolicies IBMSERVER2 on
Tip: To manage replication for a group of nodes, use the DEFINE NODEGROUP command and
assign client nodes to the group by using the DEFINE NODEGROUPMEMBER command. By
using node groups, you get the following benefits:
 Prioritize different sets of data that belongs to all client nodes.
 Add and remove nodes from replication easily (instead of updating schedules).
 The output in the activity logs is easier to follow. 

7. You must update the node, NODE1, to specify that the client node data is ready to be replicated.
Otherwise, the node is not replicated even when it is explicitly listed in the replication command.
Issue the following command:
update node node1 replstate=enabled
Tip: As a best practice, specify the REPLSTATE parameter when you create a node. 

8. Based on your data protection requirements and your environment, schedule replication to occur
once a day before database backup and expire inventory. Ensure that you run storage pool protection
just before you replicate client nodes. As a best practice, schedule storage pool protection up to four
times daily.
a). Use the DEFINE SCRIPT command to schedule replication. With IBM Spectrum Protect, sample
scripts are provided in the scripts.smp file. For information about scripts,
see https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.9/srv.admin/c_
srv_auto_script.html.
define script DAILY_REPL "/*Run daily node replication*/"
b). Issue the UPDATE SCRIPT command to add storage pool protection and to specify the
WAIT=YES parameter, which ensures the command processes in the foreground:
update script DAILY_REPL "protect stgpool stgpool_src wait=yes"
c). Update the script to specify the maximum number of sessions that can run for replication is 40, and
also specify the WAIT=YES parameter:
update script DAILY_REPL "replicate node * maxsessions=40 wait=yes"

9. Schedule the script to run and specify the parameters for when to run the script and their duration.
On the source replication server, issue the following command:
define schedule DAILY_REPL type=admin cmd='run DAILY_REPL' active=no
desc='Replication' startdate=today starttime=08:00:00 dur=15 duru=minutes per=1 peru=day
Tip: Depending on your backup schedule, you might need to run storage pool protection more than
once per day. For more information about the DEFINE SCHEDULE command,
see https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.9/srv.reference/r_cmd_schedule_a
dmin_define.html.

10. Investigate any related errors in the activity log. You can view the replication progress by issuing
the QUERY PROCESS command. For more information about the

PROTECT STG :

==================

There is no BACKUP STGPOOL command for directory-container pools, the PROTECT STGPOOL
command is used instead. This command uses replication to copy the container data to a target
server. You need to combine this command with the REPLICATE NODE command to fully protect
your backup data.
The PROTECT STGPOOL command should be run before the REPLICATE NODE command, as it
can repair any damaged extents in the data and will make replication run faster.

If a container is damaged, you can use the AUDIT CONTAINER command to recover or remove data.
The REPAIR STGPOOL command can be used to recover damaged data extents from a replication
pair.