EV9.0.3 - Inter Site Move Vault issue : process blocked at step 4 "Waiting for destination backup"

[JVL]

Hello,

After several successfull Move vault from end to end, I have many processes blocked at the "awaiting destination backup" stage (step 4).

The context is :

• Intersite migration
• Source and target servers are version 9.0.3
• There was an issue several days with the backup on the target server which could explain the first freeze.
• Now the target server is correctly backed up (usage.asp to confirm and no error in status) for few days and both servers were rebooted or services restarted.
• the first 3 steps of the process are still working fine (certainly not a right issue)

Is there's a way to force the move process to jump to step 5 (verification) as we are sure of the backup ?

More general question : do you know where to find the info regarding the move vault in progress elsewhere than just in the text file we could find in folder \Enterprise Vault\Reports\Move Archive ? is there's a DB table ? where are stored the info related to the sequencing of the process ?  I would have all about the "dark side" of the Move vault process.

This is production issue with a large amount of concerned vault to move.

Any help will be welcome. Thanks.

[Tmarques]

Take a look at the following document https://docs.google.com/viewer?a=v&q=cache:fRXGSGkDFgIJ:www.symantec.com/business/support/resources/...

In on page 27 there are Appendix B – EvMoveArchiveTask.exe.config Settings

Which should help.

[Tmarques]

In particular check out the following setting in the document on page 30.

WaitforBackupMode

Whether to wait for backup of copied items.

0: always wait

1: as per destination archive's Vault Store safety copy setting

2: never wait

Default value 0

[JesusWept3]

The tables you want to look at are SubTask for the actual submitted move archive then ArchiveMove and ArchiveMoveHistory in the directory database

[JVL]

Thank you for the info to both of you.

I've done few unsuccessfull tests with the following config file on the source server and restarted services several times:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>

    <generatePublisherEvidence enabled="false"/>
<AllowedNoOfCopyBackupCycles value="5" />
<LogLevel value="Failures" />
<LogPrivacyEnabled value="True" />
<MaxLogSizeKB value="1024" />
<ProcessorThreadsCount value="2" />
<ReportVersions value="3" />
<RescheduleIntervalInMins value="5" />
<SkipDuplicateItems value="1" />
<WaitforBackupMode value="2" />

  </runtime>
</configuration>

the move archive processes are still blocked at step 4. Any advice ?

The config file should be set only on the source server not on the target I guess (?)

An envisaged workaround : If I delete the raw of a particular Move Archive in the SubTask table will it be considered as a new operation and so with the parameter <SkipDuplicateItems value="1" /> this should ignore duplicates and move forward ?
 

[Chris_Warren]

To make sure the EVMoveArchiveTask.exe.config is in the right format, I suggest utilizing the Example version of the config (just copy and rename) that's in the \Enterprise Vault\ install directory. 

As to your question - If you delete the job it will remove the Subtask entry.  When you recreate the job, you would want to make sure you point to the same destination archive that was used previously (do not set it to go to a new archive).

The SkipDuplicateItems setting works like this:

- By default, when performing a move to a destination, EV will utilize the same Transactions as on the source.  If the destination Archive has these same transactions, Move Archive should automatically skip these under the logic that they have already been moved.

- If Move archive detects that the transactions are in the destination Vault Store, but NOT in the destination Archive, it will consider this as a TID Clash and fail.  The SkipDuplicateItems value bypasses this function and will skip those items as well.

As a note, if you remove the job and recreate it, ensure that the source archive is not in a Closed state.  Closed Archives will no be present in the list for valid archives to be moved.

I hope this helps!