Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

O.K., we found where the problem is. There are subttle differences between some utility binaries in different ESXi versions. Your ESXi 5.1.0 is not accepting one command, we'll fix it and reach back to you ASAP.

Confirmed, there are some bugs in regards to espace escaping in v 10.2.1. This will be solved in next version 10.2.2, we'll try to launch it ASAP.

[url]https://33hops.com/forum/viewtopic.php?id=151[/url]

Contact support and we'll connect to your system to correct the issue if needed.

The license key should appear after the colon, i.e.:

(c) XSIDiff 1.0.6.1 licensed: 000379C40000000000000000001517bcdfdc

Your XSIDiff is a bit old, it contained a bug that could cause this effect if you have more than one NIC in your system, which is even more frequent than a single NIC. Not all systems were affected, but your issue seems to be exactly that.

Keep your [b]request.key[/b] and [b]license.key[/b] files (they will still be valid) and upgrade to latest XSIBACKUP-PRO version. If you are running a 24x7 server and cannot afford to reboot the ESXi host, which is required, you can also just update the src/xsidiff file with the newer version.

First is first. Your installation is not detecting the license.key file. Have you renamed it to [b]license.key[/b] and placed it in the xsi-dir?

We don't have a schedule to update XSIBackup Free, we might do it in a couple of months or it might take longer.
That bug won't affect but a few users, most SMTP servers will accept a single line feed.

UPDATE:

We said we would, some lines up this post, so we will lauch a new version with that bug fixed.

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.

I'm afraid you just need a reboot.
Due to ESXi OS design AFAIK it's not possible to clean memory from the command line as in Linux systems.

Which log file are you referring to?.
That message is thrown by OpenSSH, it's a known bug that XSIBackup already addressed.
[url]https://33hops.com/forum/viewtopic.php?id=2[/url]

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.

We aren't able to see anything in the screenshot. The error below is an XSIDiff segmentation fault, which is very weird. I would rebuild that VM by cloning its disks via vmkfstools. If I were you I would turn them into thin provisioned disks, AKA sparse files, as they will occupy less space and will allow you to back them up faster too.

Cloning disk to thin format:

vmkfstools -i "/vmfs/volumes/Datastore/examplevm/examplevm.vmdk" "/vmfs/volumes/Datastore 2/newexamplevm/newexamplevm.vmdk" -d thin

I would also make sure that the newly generated disk is an exact multiple of 1M (1048576 bytes), which is the VMFS block size, by extending them to the closest 1M multiple.

vmkfstools -X 80000m /vmfs/volumes/storage1/win2000/win2000.vmdk

Should we consider this to be closed?

Windows Server OSs (and Windows OSs in general) are trickier to backup than *NIXes, I won't delve into the details now, but the most delicate part is quiescing, which XSIBackup does by default. If you can afford to, I would simplify my life and parse the [b]--snapshot=dontquiesce[/b] flag to the Windows machine in a separate backup job, that would ensure it's not quiesced and multiply your chances to take a snapshot without errors.

In case you do need to quiesce the VM, then you'll need to deepen into the matter by checking the event log in search of any flaw in any service (VMWare Tools, VSS, Virtual Disk, etc...) upon which quiescing depends. Most of the times, it's lack of room in the Windows guest that causes trouble, in some other cases some services like Exchange or MS SQL, which have their own shadowing services, might need to be patched or upgraded. Read this post:

[url]https://33hops.com/esxi-snapshot-errors-and-solutions.html[/url]