Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

That's how the software works.
If you scatter disks among different datastores, you will have to set their paths again in case you restore them.
How would you expect it to work?: have a backup software that scatters backups in different backup directories?

Sometimes ESXi can fail to detect [b]open-vm-tools[/b], which is the package that should be installed in RHEL/CentOS/Fedora and other  Linux distros.

[url=https://github.com/vmware/open-vm-tools/issues/275]Open-VM-Tools Issues at Github[/url]

You need to make sure the service is not only installed but also running.

When is this error raised?, at the beginning of the job transfer phase?, in the middle of a job?. Please do post all log or contact support to send it if you don't want to publish that data here.

The message is clear, the remote host is killing the SSH tunnel, now the next step is finding why. To find out the ultimate cause you should set OpenSSL debugging in the server, so that a more verbose error is thrown by the OpenSSL binary. It could be due to some timeout having been reached, some disk or tmp folder getting full, etc...

Yes, key is checked once at the beginning of the job.

Well, it's true that you can achieve the same result using either of the two syntaxes: local or over IP.
Choosing what to use is left to you based on the knowledge of your set up. If you are in a LAN, you can attach your volume as an NFS datastore, nonetheless you will be adding some little latency to each I/O operation, which is not negligible.

On top of that, you will be using the same CPU to calculate hashes compress the data chunks and record them on the NFS share, while when you use (c)XSIBackup in a client/server mode you are balancing/ splitting the load on the CPU between the two servers.

As an extreme example, you could mount an NFS DS over a WAN, you won't get good results though, that's obvious. On the other side, using a client/server topology over a WAN will offer optimum results. What to do is up to you, in any case we believe choices are clear in every case.

Where is job 002 sitting?
You don't need to use --on-success & --on-error to chain backups, you can also just chain jobs via standard shell constructs:

001 && 002 || 002

Current [b](c)XSIBackup-DC[/b] version 1.4.2.1 is capable of doing everything Pro edition does much faster & much more efficiently, except one thing: [b](c)Onediff[/b]

[b][url=https://33hops.com/xsibackup-pro-onediff.html](c)Onediff[/url][/b] is an instant differential feature which is specially useful when having to backup huge VMs in a short period of time. It stores the changed blocks to a snapshot and that snapshot is sent to the remote end and integrated with the previously sent base data.

- Keeping a permanent snapshot can reduce performance, this isn't a big issue as per the current working figures hardware can achieve though.

- Onediff differential snapshot has to be integrated to the remote VM, thus, you need to keep a mirrored VM to be able to merge the differential data and that VM has to be compatible with the original VM, not only in terms of compatibility between HW versions, but also in regards to VMFS versions.

Until we finish to develop an instant differential feature for DC edition, which will be much better than (c)Onediff, we can offer Pro + DC at reduced prices, just [b][url=https://33hops.com/contact-form.html]contact us[/url][/b] to get your deal.

[b](c)XSIBackup-DC 1.4.2.1[/b] manages this automatically by detecting whether ESXi main version is equal or greater than 7 and deleting all snapshots previous to performing a backup or replica, only if the VM is on.

Please, be aware of this (c)ESXi >= 7 limitation imposed by (c)VMWare design.

The error is stating the certification SHA-1 check failed. Free version does not include backup certification as a feature, thus you should remove [b]--certify-backup[/b] argument if you are running Free version.

You are describing a generic issue that might not have anything to do with (c)XSIBackup. The job may fire twice if your crond service is loaded twice, this can happen in (c)ESXi, or if you have set up a wrong cron schedule. Please remember to set hour and minute at a minimum and don't leave an asterisk in the minute column or you will provoke issues as what you describe.

To make sure that only one instance of crond is running you can use the below code snippet. Please read the full post below to have a better idea of how the crond service works and how to troubleshoot it.

for p in $(ps -c | grep -v grep | grep 'busybox crond' | awk '{print $1}'); \
do kill -9 $p; \
done; \
/usr/lib/vmware/busybox/bin/busybox crond; \
ps -c | grep -v grep | grep 'busybox crond'

[url=https://33hops.com/xsibackup-cron-troubleshooting.html](c)XSIBackup Cron Troubleshooting[/url]