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

Applies to

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

Issue

• A backup with SC 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.

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 update could not be started by then, the SnapMirror or SnapVault update fails
• 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

• Generally, increase the total number of times SnapCenter will retry the update as time between retry attempts
• Locate the SMCoreServiceHost.exe.config file, which resides in %ProgramFiles%\NetApp\SMCore
  Note: for Plug-In host related backups, this needs to change on the Plug-In hosts, not on the SC Server host
• Open the config file in a text editor, and go to the end of the file, just above </AppSettings>
• Insert the following  lines:

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

• Make sure no operations from SC are running on the Plug-In hosts or the SC Server (check the Monitor in the SC UI)
• Restart the SnapCenter SMCore service on the SC host
• Restart the SnapCenter SMCore service on the plug-in hosts
• For the Exchange UTM/Log combined volume, the workaround would be to split up the UTM location to another LUN, which changes the processing from creating transaction log hardlinks to copying them to the other location instead, lengthening the log part of the backup in the process.

Additional Information

• For older SCV (up to 4.1.1) and the Linux Plug-ins, the SnapVault or SnapMirror update always runs in SMCore on the SnapCenter Server.
• For the Windows Plug-ins, the SnapVault or SnapMirror update runs in SMCore on the Plug-In host itself, while the weekly clean-up runs on the SC Server.
  • Note: The settings that need to be added into SMCore, cannot be changed from Powershell using Set-SmConfigSettings
• The Exchange Plug-in defect described above is, due to the way the processes split up in the backup design, not fixable in software.

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