You are not logged in.
I manually started a backup-job (rsync over ip), only one VM.
The system found the license-key for XSIDiff 18.104.22.168 on both machines.
It looks like, that the job automaticly switched to use the XSIDiff instead of "pure" rsync.
In the report e-mail I get the following error code (in app. 200 lines)
ERROR CLXSIDF1, details: [WSE2016] error: XSIDiff error, details: rekeyed outbound cipher rekeyed inbound cipher
both machines use:
VMware ESXi 6.7.0 build-13981272
it worked fine with:
VMware ESXi 6.7.0 build-10302608
A RAID Controller (DELL PERC H310) was added on both systems
What can I do?
That is an OpenSSH error that has to do with the SSH tunnel keying
Contact support, there's always a chance that it's a combination of OpenSSH versions that causes it but it looks more like some issue with your job.
I have the same problem using XSIBACKUP-PRO 11.2.10 in XSI6.7.0 Update 2 (Build 13006603):
ERROR CLXSIDF1, details: [Active Directory] error: XSIDiff error, details: rekeyed outbound cipher rekeyed inbound cipher
How to solve this? Thanks.
That is just an informational message from part of the SSH tunnel.
- Is it affecting your backups?, apart from the error itself, which should be thrown as a mere warning, probably not even that. We will fix this ASAP.
- Is your VM big, does it take a lot of time for the backup to complete?
Same here:Esxi 6.7.0 Update 3 (Build 14320388)
Last error raised for the above VM:
ERROR CLXSIDF1, details: [win7-spice] error: XSIDiff error, details: rekeyed outbound cipher rekeyed inbound cipher
marked KO! in the email
the backup was interrupted in the middle of the VM file and did not finish, it appends not all the VM, only 2 of 4 has this error.
Update to latest version 11.2.19, that will help the issue.
But do you know the reason?
Well, given the fact that we launched a fix, it'd be difficult to achieve the fix by chance.
Yes, of course we know: the OpenSSH binary has become extremely verbose in latest versions printing to STDOUT irrelevant information such as rekeying, FIPS mode on, etc.... We don't know why OpenSSH development responsibles have decided to do so or whether it is some unintentional pseudobug or some wicked approach.
We have fixed it by intercepting irrelevant information in the SSH tunnel and ignoring it. Messages to be ignored are kept in the conf/err-imsgs file.
any chance to provide this 'fix' also to free version ?