Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Those tests are valid for your hardware and the amount of data used to perform the test, which don't correspond to the I/O figures of an average server in production.

Since ESXi caches as much data as it can in RAM, real usage figures for real situations don't differ that much, in fact, most of the times don't differ at all.

You are publishing figures obtained in one extreme of a Gaussian distribution to explain the whole distribution.

The registering loop does not happen because the _XSIBAK VM is not registered when using that flag.

We could have designed things that way, but then there would be some different drawbacks, like having to go through all the VMs to find a restore point in time.

You can overcome your apparent limitation by using the find command, a one liner will suffice.

1/ You can't just OneDiff from ESXi version 6.7 to 5.1, unless you are hosting in ESXi 6.7 a hardware version way below the current as per the ESXi 6.7 version that is compatible with ESxi 5.1. In any case that is a really bad idea.

2/ OK, no problem, everything is local, you don't need to take into account how different versions may interact.

3/ XSIDiff is useless in a local environment, use Vmkfstools instead

4/ OpenSSH versions in 5.1 and 6.7 are very distant in time. KEX algorithms and cyphers have been deprecated in the meanwhile. It's not impossible to copy data from one to another, but you will need to comprehend how those two openSSH versions work toghether and make the appropiate tweaks, it might even not be possible at all to do what you want.

5/ That scenario should not be a problem.

Try to keep ESXi versions as compatible as possible, being the most compatible the exact same version and build number and the least the most distant in time.

Well you can configure whatever you like as the repository folder name, but the advantage of deduplication is achieved only when backing up to the same repository.

It will be included in next Free version, but current Free version is older than the command itself.

We have never seen this behaviour, but given the fact that you seem to be using a Windows 2003 VM, which is quite an outdated OS, you should investigate whether the version of VMWare tools you are using is conveniently updated.

OneDiff is used by thousands of people around the globe with optimum results.
VMWare warns about long chains of snapshots being kept in production VMs, but a single snapshot should not hurt performance.
Maybe your test was too short, we don't get the same results. When you have one active snapshot in a VM, the VM kernel saves data to the snapshot instead of to the base disks, which does not affect throughput much. It is the moment of coalescing snapshot data with the base disks that may cause a big load, especially on long chains of snapshots.

XSIDiff is a binary used by OneDiff but it's not a differential tool.

We want sysadmins as users, people willing to have control on the environment they manage and looking for a tool that allows them to increase their level of control by allowing backup and syncronization of VMs.

It's not risky at all to arrange VM names and paths, it's just a 5 min operation with zero risk. When you move VMs around or convert them using third party tools, this tools may: create complicated names and paths, misalign your resulting disks in regards to the VMFS block size, etc...

By ignoring those key facts, you are leaving the door open for chaos. Big problems are rarely a one cause issue, but a coalesce of different circumstances that previously passed inadverted.

Thank you for your support

First problem you have to solve is with snapshot management. Snapshots cannot be deleted. That's an ESXi inner mechanism, so finding why it fails is your main concern.

You have this error on your log: [b]Skipping invalid VM '20'[/b]. Its is indicating that your host's registry is not in good condition and that could lead to all sort of errors, including problems with snapshots.

You need to fix your host before actually trying to use XSIBackup

You can't use parenthesis or any other special character in the VM names nor paths, it's in big red letters at the beggining of the Man Page: [url=https://33hops.com/xsibackup-help-man-page.html](c)XSIBackup Classic Man Page[/url]

You are publishing on the XSIBackup-Free forum. Free version does not have a restore feature.
You are most probably trying to use a [b]-flat.vmdk[/b] file as a descriptor.
We highly recommend that you keep a reliable copy of your data before actually doing anything else, you are most probably making wrong assumptions, and that can be dangerous.
You don't boot a VM on a -flat.vmdk file but on the file descriptor. Please start reading here:

[url=https://communities.vmware.com/thread/448472]DiskLib_Check() failed for source disk The system cannot find the file specified (25)[/url]
[url=https://www.vmware.com/support/ws55/doc/ws_learning_files_in_a_vm.html]What Files Make Up a Virtual Machine?[/url]

I would first focus on the most obvious error: [b]XSITools error: failed to update the block count[/b]
This indicates that the number of blocks could not be updated on the remote host. Any other additional more thorough test is not important compared to this error as they are value added additional checks.

Contact support with your exact build number so that we reproduce your exact environment.
Never forget XSIBackup constraints in regards to especial characters in paths.

Rsync is used to send the auxiliary files, that doesn't make any difference in speed, the bulk of the data is in the [b]-flat.vmdk[/b] files.
In your case you are using [b](c)XSITools[/b], which is our propietary deduplication engine, and it looks like you are using it over IP to backup to a remote host. In case of [b](c)XSItools[/b], the binary transfer agent is [b]dd[/b] over SSH, so the data is optionally compressed and directly tunnelled.