Help recovering target replicated de-duped file store please

[manofmilk]

Hi,

We have a pair TSM 7.1.3 servers 'A' (production) and 'B' (offsite). Both systems have a single, de-duped, file pool and there is replication in just one direction, from A to B.
Owing to a problem with the RAID controller on the offsite server, B, we have lost some of the volumes in the file pool and we suspect corruption in others.
How can we re-replicate already replicated data from server A to replace the data missing from the 'destroyed' and 'damaged' volumes on server 'B' - the replicate node with recover damaged seems to only be valid for repairing the replica source (server A) but it is the target (server B) that has the problems.

With much thanks.

 

[marclant]

You cau use the FORCERECONCILE option of the REPLICATE NODE command:

FORCEREConcile
Specifies whether to compare all files on the source replication server with files on the target replication server and to synchronize the differences between them. Prior to Tivoli Storage Manager V7.1.1, this behavior was the default for replication processing. When Tivoli Storage Manager V7.1.1 or later, is installed on the source and target replication servers, a reconcile is automatically completed during initial replication. After initial replication, you might use this parameter for the following reasons:

• To synchronize files on the source and target replication servers if they are different.
• To replicate inactive files that were skipped after you change your replication rules from ACTIVE_DATA to ALL_DATA.
• To delete inactive files from the target replication server when you change your replication rules from ALL_DATA to ACTIVE_DATA.
• To ensure that you replicate only active data when you are using the ACTIVE_DATA replication rule so that the target replication server has active files only.
• To resynchronize the files so that the target replication server has the same files as the source replication server if you have previously or are currently using the policies on the target replication server to manage replicated files.
• To resynchronize the files on the source and target replication servers if the database is regressed to an earlier point-in-time using a method other than the DSMSERV RESTORE DB command.
• To rebind files to the new management class on the target replication server if this management class did not exist when the files were replicated. You must be using the policies that are defined on the target replication server to manage replicated files.

Remember: When the ACTIVE_DATA rule is assigned, a reconcile is completed only for active files on the source replication server.

This parameter is optional. You can specify one of the following values:

No
Specifies that replication processing does not force a reconcile to compare all files on the source replication server with files on the target replication server. Instead, replication processing tracks file changes on the source replication server since the last replication and synchronizes these changes on the target replication server. NO is the default value.
Yes
Specifies that replication processing forces a reconcile to compare all files on the source replication server with files on the target replication server and synchronizes the files on the target replication server with the source replication server.

source: https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.3/srv.reference/r_cmd_node_replicate.html

 

[llib]

You cau use the FORCERECONCILE option of the REPLICATE NODE command:
source: https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.3/srv.reference/r_cmd_node_replicate.html

If I understand the issue, what is suspected is data corruption. If so, metadata are fine, and forcereconcile only works with differences in metadata(so far as I can read it).
Would this not be dedupe, I would think before focereconcile, some things have to be done:
-Audit volumes
or
-delete volumes(note - this is something that needs to be thought through in advance with FILE volumes in some cases - e.g. if you care about performance and thus are using pre-formated volumes, you'll need to preformat them again).
i.e., either you confirm whether there is corruption or not, and where is, you deal with it *somehow* to remove it from inventory and then forcereconcile should help, or you outright resync everything (after deleting everything).
I am not sure if there are any specifics due to dedupe.

 

[marclant]

-delete volumes(note - this is something that needs to be thought through in advance with FILE volumes in some cases - e.g. if you care about performance and thus are using pre-formated volumes, you'll need to preformat them again).

Be careful with deleting volumes with dedup data, there is more to it than that.

 

[llib]

Be careful with deleting volumes with dedup data, there is more to it than that.

This
"If you issue the DELETE VOLUME command for a volume in a storage pool that is set up for data deduplication, the server destroys any object that is referencing data on that volume."
or something else?
If it's that, then if data are corrupt, all the references have to be deleted, otherwise they won't replicate again.
But to be on safe side, maybe first audit few volumes to assess the problem, then decide if it makes sense to go on, maybe try move data, or if all the data may be screwed up and complete resync is necessary.