I'm new to XSIBackupPro - and got problems.
2 identical machines with DELL-ESXi-6.0U3-5050593-A00 installed, one running fine for months, the second new, running fine for some days. Dedicated (onboard-)NICs for VMkernel each.
XSIBACKUP-PRO 10.2.1 installed on both, they can SSH each other with no problem.
ssh -V shows "OpenSSH_7.3p1, OpenSSL 1.0.2j-fips 26 Sep 2016" (same on both machines, as expected)
But - running a command like
"/vmfs/volumes/datastore1/xsi-dir/xsibackup" --backup-point="192.168.100.16:22:/vmfs/volumes/datastore1/backup" --backup-type=custom --backup-vms="VM1,VM2,VM3" --backup-prog=onediff --backup-room=1200 --debug-info=yes --mail-from=*** --mail-to=*** --smtp-srv=*** --smtp-port=25 --smtp-usr=*** --smtp-pwd=***
does a backup - not too fast (vSphere WebClient shows around 200 MBit/s) - and in the end there seems to be a valid backup - but what is worrying me, are these entries in the logs:
[ Thu Jan 4 17:12:45 UTC 2018 ] ERROR (CLXSIDF1), details [Tschonn-VPC7] error: XSIDiff error, details: kex protocol error: type 7 seq 677110
kex protocol error: type 7 seq 1354425
kex protocol error: type 7 seq 2034312
kex protocol error: type 7 seq 2721475
kex protocol error: type 7 seq 3406309
kex protocol error: type 7 seq 4092443
kex protocol error: type 7 seq 4776557
kex protocol error: type 7 seq 5456368
And an additional question: Is the speed normal? Machines are Xeon 3440, 32GB RAM, GBit-Network, little load, Storage working fine (accessing the VMs runs as expected for a GB-Connection)
Thanks in advance and sorry for my bad english.
Which log file are you referring to?.
That message is thrown by OpenSSH, it's a known bug that XSIBackup already addressed.
In regards to the speed, it will depend on many facts, OneDiff will send only differential data, once it has done so it will integrate that data with the corresponding underlying -flat.vmdk file, so, the speed your NICs offer, the type of network, the volume of differential data, etc... will affect speed figures.
We warn all over our website about using manufacturers' custom builds in general. We have detected some of those versions to contain serious bugs, or to plainly go "their own way", be careful.
Sorry for having been inprecise: The "log" I'm referring to is the ".ERRxxxxxxxxxxxxxxxxx"-file in /xsi-dir.
The "kex protocol error"-lines were also included in the mail sent to me by the xsibackup script.
Of course I did some reading in the forum and found the mentioned forum-thread and understood that the bug is already addressed ("From XSIBackup 9.1.9 and up") before writing here, but: I am using current version 10.2.1 of xsibackup, so I was upset seeing the "key protocol error".
However, the backups are working and the following differential backups (using OneDiff) don't show up any more errors, I'm happy about it.
Regarding the speed: once the first copy is done, the following OneDiff-backups are running fast, another thing I'm happy about.
Just for being sure: There is no need for me to update ESXi, OpenSSL/OpenSSH or something else on my ESXi-Boxes?
Thank you very much
Don't worry, nobody is perfect. Well, addressing the issue means just changing the KEX (key exchange) order and trapping the kex protocol error, so that it does not generate application level errors, which is failing in your case. If you can provide the detailed log, we can try to find where that error was generated to trap it in a more convenient way.
Of course, the first copy is full, while the subsequent ones are differential. If you were getting 200 mb/s on the first OneDiff copy, then you must have broken some record, as that speed is closer to the HD limits.
You don't need to, just send us some more detailed information.
Regarding the "record": Not 200 mb(ytes)/s, bit 200 MBit/s (Network transfer) ... that's far from the HD limits ;-)
Detailed log: The mentioned .ERR-file is already overwritten, sorry, but I will forward the then mail that was sent to me by the script.
The "kex"-error never rised again till now.
But i've got an vague suspicion: In the beginning bot ESXi-boxes were multi-homed. The had two vmkernel-Networks, 192.168.66.0 and 192.168.100.0, both connected to (different) switches. And I found out that ESXi can't handle this. I saw the box trying to send packets bound to an adress in 192.168.100.0/24 over its interface 192.168.66.x ... so I deleted the second vmkernel-Network on both machines. Maybe the error was due to this?