Replication Job error Signature.StartReversedSignatureUpdateSession

[FCU_JE]

Case 07608030.

I'm rotating some elements of the original error code below for what little anonymization that gives me.

Code: Select all

Hard disk 1 (96 GB)
Error: Invoke failed. Agent: 'e03be8a6-dfe1-4b81-8d67-ea5ce80f8921', Command: 'Signature.StartReversedSignatureUpdateSession', parameters: {(EString) SignatureName=Scsi.0.0; (EString) TargetItemLink=veeamfs:0:/Scsi.0.0@\\192.0.2.1\Backup\Replicas\Job_1_7ceea7eb-6143-4bfc-ae3b-15e63069f8ac_vm-32780\1970-01-01T000000.vbk; }
Processing finished with errors at 1/1/1970 1:00:00 AM  

Short story is one day I was doing some normal infrastructure password rotates - nothing crazy, basically rotating service account passwords and updating those accordingly in Veeam. The same day when our replication job ran, the above error message occurred in our replication job. The issue came and went. The error would also "migrate" between different VMs in the job. Some times the job would run on its schedule with 0 issues, then it would come back. When the error did occur, it would self-correct everything on retries.

Veeam support hypothesized it had to do with our proxies not being beefy enough which I disagreed with as the bottleneck is by *far* the network link between the source + destination site.

The solution in my case? Do nothing. Absolutely nothing. After a couple weeks the issue just self resolved on its own. This weekend the replication job ran fine every time without this error.

I'm only making this forum post because when I first found this issue, I found basically no results online for this behavior. I hope this helps someone else in the future...just wait it out I guess??

[david.domask]

Hi FCU_JE,

Thank you for sharing the case number and the details on the issue. It's unfortunate that a root cause wasn't found, but based on the above I have a pretty good guess it's about the Replica metadata being hosted on an SMB share.

The replica digests process (step 5) as described by Support is accurate -- data is transferred to a VBK file which contains metadata to reduce the amount of data transferred during incremental runs. While I cannot prove this based just on the case notes and the above, I suspect there was an intermittent issue with the connection to the share and likely it self-resolved.

While it's not inherently wrong to keep it on an SMB share, in general we advise against SMB shares as they're quite sensitive to connection drops; an intermittent network issue would explain why the issue seemed to jump around from machine to machine during the backup as it's not about a specific machine, but just the timing of when the issue arose. I could similarly see other issues like Firewall potentially being a factor, but with SMB usually the simplest answer is just a network issue.

Please do open another support case if the issue reappears and refer to this post -- it should be fairly easy to catch in the datamover agent logs if it was indeed a networking issue, but hopefully the issue does not reappear.

[FCU_JE]

I will preface that getting off this SMB share is something I'm working to prioritize. In this case though the SMB share/repo and the source backup proxy are in the same rack, VLAN, and subnet so I'm highly skeptical it's a networking issue. Not impossible, but there's zero logs to indicate any such networking issues.

The VBR server *is* in the DR site (across the network link from the above proxy/repo) so if there is network contention, I'd expect it to be between VBR in its role as "orchestrator" and its subordinate member servers/proxies/etc.

[david.domask]

Appreciable, and to be clear, I am of course making pretty generous assumptions, and only a review of the logs will tell the full story (though you might catch something in the SMB event logs), but regardless, if the issue reappears, please open a new case and update this thread with the new case number.