SnapCenter SnapMirror or SnapVault update fails with "Another transfer is already in progress"

Applies to

• SnapCenter Server (SC)
• SnapCenter Plug-in for Microsoft SQL Server (SCSQL)
• SnapCenter Plug-in for Exchange (SCE)
• ONTAP 9

Issue

• Backup job ends in a Warning, showing that the SnapMirror or SnapVault update request ended with the following message:
  • ErrorCode (-1), ErrorMessage (Snapmirror update failed with SDError (102) - SnapMirror update operation failed.
Failed to update the SnapMirror relationship. Another transfer is in progress.
  • SnapVault update failed for the relationship [<SOURCE_PATH> ==> <DESTINATION_PATH>] with error: Snapmirror update failed with SDError (102) - SnapMirror update operation failed.
Failed to update the SnapMirror relationship.
The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: Another transfer is in progress.
• SNAPMIRROR-AUDIT-LOG-TXT.GZ on ONTAP also indicates Another transfer is in progress.

ManualUpdate[<TIMESTAMP>]:<RELATIONSHIP_ID> Operation-Uuid=<UUID> Group=none Operation-Cookie=0 action=Start source=<SOURCE_PATH> destination=<DESTINATION_PATH>
ManualUpdate[<TIMESTAMP>]:<RELATIONSHIP_ID> Operation-Uuid=<UUID> Group=none Operation-Cookie=0 action=End source=<SOURCE_PATH> destination=<DESTINATION_PATH> status=Failure message=Another transfer is in progress.

Cause

• The backup that created the Snapshot on the volume ran while a previous backup was still updating the SnapMirror or SnapVault relationship.
  With default settings, after 8 update attempts in 8 seconds, it runs a sub-job which will attempt to run the update 9 more times with a 1 minute pause in between each attempt. If the previous transfer has not finished by then, the backup fails out the mirror or vault udpate, and will not register the snapshot.
• The destination has setup an update schedule in ONTAP that conflicts with the backup timing, causing extra updates.
• Two different backups, where resources share the same volume, are run in overlap or simulteneously from different hosts.
• For the Exchange Plug-in, if the Transaction logs and the UTM location share the same LUN/Volume, the update is started twice, and the second one will fail like this, as is explained in Product defect 1223643.

Solution

If overlap happens, the attempts to retry can be extended to allow for a longer time before giving up on the updates:

1. Increase the total number of times SC will retry the transfer.
2. Locate the SMCoreServiceHost.exe.config file, which resides in %Program Files%\NetApp\SnapCenter\SMCore
   Note: for Plug-In host related backups, this needs to change on the Plug-In hosts, not on the SC Server host
3. Open the config file in a text editor, and go to the end of the file, just above </AppSettings>
4. Insert the following  lines:

<add key="SnapshotCheckRetry" value="300" />
<add key="SnapshotCheckTimeout" value="300000" />
<add key="SnapmirrorRetry" value="300" />
<add key="SnapmirrorTimeout" value="300000" />

5. The above entries mean that SC checks 300 times every 5 minutes (300000 milliseconds). The values can be adjusted accordingly.
6. Make sure no operations from SC are running on the Plug-In hosts or the SC Server (check the Monitor in the SC UI)
7. Restart the SnapCenter SMCore service on the SC host
8. Restart the SnapCenter SMCore service on the plug-in hosts

Notes:

• Do not schedule mirror (specifically vault) updates ONTAP side when SnapCenter is supposed to handle them.
• Do not use the same volume with LUNs divided between between two or more hosts, and not mapped to all of them (i.e. non-shared LUNs).

Additional Information

Parent topic: Resolution guide for SnapMirror/SnapVault issues in SnapCenter