replication and retentions

[gernthefish]

Do the same management classes as the source server have to be set up on the target server before replicating nodes? What happens to the retentions, destinations, etc if they haven't been set up on the target and nodes are replicated? Is there a way to correct this on the target after replication, or is there a way to "redo" the replication?

 

[Trident]

Hi,

There are two modes for replicated data: Similar and dissimilar policies. The storage below can be anything.

As long as you only work on the target system, you can force a re-sync of data from the source . Or you can remove relplication, rename node and start over.

rem replnode node on both systems
ren node node node_old on target
upd node replsta=ena on source
repl node node on source

Once replication is in sync just remove the old node.
del file node_old *

Or you can force various sync's

You can read here:

REPLICATE NODE

Use this command to replicate data in file spaces that belong to one or more client nodes or defined groups of client nodes.

www.ibm.com

Look at forcereconsile.

 

[gernthefish]

Awesome. Great info. If I redo the replication, should I first define all the mgmt classes (and destinations) on the target the same way they are configured on the source? I need to keep the retentions the same.

 

[marclant]

If I redo the replication, should I first define all the mgmt classes (and destinations) on the target the same way they are configured on the source?

No, replication handles that. By default, DISSIMILARPOLICIES is set to OFF, so the policies will be the same (retention is part of policies) on source and target after replication.

And you shouldn't need to reconfigure replication, you just need to run another replication to sync up the policies, assuming DISSIMILARPOLICIES is OFF. If you define or modify policies on the target, replication will overwrite them.

 

[gernthefish]

That's not the result I got. I tested replicating a node without defining the same mgmt classes on the target. When it finished, all the archives on the target were associated with the default mgmt class (not the original classes from the source). I didn't specify anything with regard to DISSIMILARPOLICIES.

 

[marclant]

You should probably check the activity log for a previous replication to see if there were any issues replicating policies.

Also check QUERY REPLSERVER to double-check if Dissimilar Policies is ON or OFF.

 

[marclant]

Was the target empty before you started, or was already data on it? It's possible it will not replicate a policy domain if that domain already exists with different policies. If that's the case, you'd see messages to that effect in the activity log.

 

[Trident]

Hi,

The active policy sets needs to be identical on both systems.

Try this command:

VALIDATE REPLPOLICY

Use this command to 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.

www.ibm.com

 

[marclant]

Hi,

The active policy sets needs to be identical on both systems.

Try this command:

VALIDATE REPLPOLICY

Use this command to 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.

www.ibm.com

You are right, this goes along with what I found in this technote:

Node Domain updated on replication target server

A node is replicated to a target Spectrum Protect server. After the replication is completed, the node's domain is updated to a different domain on the replication target server.

www.ibm.com