Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

We'll take this into account, thank you for your feedback.

That's 575.00GB of real data (non zeros) per hour. Not bad, an average of 164.00 MB/s
It could be considerably faster if you used faster disks/controller

[b](c)XSIBackup-DC[/b] can jump over zeros, thus, if you backup a VM which is 4.00TB in size but only contains, let's say 20.00GB, it will be backed up really fast, as zeros will be ignored and from the second pass the 20GB will be traversed at read speed.

If your VM contains 4,6 TB of real data, nothing is going to keep you from having to walk through every byte. Most of the data will most probably not have changed, thus your effective speed on a [b](c)XSIBackup-DC[/b] backup will be close to the read speed you can achieve, as SHA-1 calculations are RAM fast even with a modest Intel CPU. That should yield over 200.00MB/S on enterprise grade HDs and about twice that on enterprise grade SSDs or NVMe, M2, ...

As you say (c)OneDiff can be much faster in this case, but you must not forget some facts: (c)OnedIff depends on the differential snapshot being integrated in the remote VM, that requires some ESXi host to replicate data. Apart from that, the integration of the snapshot may fail depending on the ESXi host conditions, while [b](c)XSIBackup-DC[/b] differential feature is completely independent of the target system. As [b](c)XSIBackup-DC[/b] walks through every byte, you can be sure that the resulting VM will be consistent, no matter what happens with the backup snapshot.

Apart from that, [b](c)XSIBackup-DC[/b] will only be sending data when it detects some block that has changed, thus, although it may take 8 h. to complete, all that it's doing most of the time is to read data.

If you interrupt an XSITools:z backup, you will generate half written block manifests at the YYYYMMDDhhmmss timestamped directory, thus you should remove that folder. When you do that you will leave some orphan blocks (blocks which were only present in the backup that was halted). This is not crucial, as will only occupy some MBs and they will be pruned next time you prune the repository.

To check a repository at any time:

./xsibackup --check-xsitoolsrepo=/path/to/repo

That doesn't mean anything, the snapshot could be failing due to some heavy load during the backup per instance, or some missing software in the guest, like VMWare Tools, or even some faulty service that causes the snapshot request to time out.

You should check the guest's logs more than the ESXi host itself when you have this kind of issue.

If your file names and paths are orthodox in naming, then you are losing packets beyond what TCP can handle.

You may use WinMTR to have an insight into what might be going on:
[url=https://sourceforge.net/projects/winmtr/files/]WinMTR Home Page[/url]

Or use some more classic tool such as ping and/ or tcpdump

A regular ping can offer some insight, pay attention to whether some packet is lost and also wht's the jitter, the difference between the largest and the lowest ping times.

You will need to perform the tests while you are backing up, sometimes it's a poorly written driver that could be causing the problems, nevertheless it could be any network element.

Please, do not name jobs outside its naming scheme 000-999

Depending on the amount of data you are storing, rotating data can take a long time.
You should inspect what's going on in the log before actually killing the process:

tail -f /scratch/XSI/XSIBackup-Pro/var/logs/xsibackup.log

Is that file in a cluster?, is it being open by some other process?
What kind of DS is it residing in?
Something is clearly holding it at the time to backup.
What type of guest OS are you running?.

--prune does indeed work on remote repositories, it is an internal feature though, we will change that message.

Yes, that is for the Free edition too.
What do installation dir and backup point have to do with the crontab?

Yes, they are local options.
Only --backup and --replica arguments need to be licensed to work without restrictions.

Current Pro version does have that feature.
We thought of adding it to the DC binary, nonetheless we want to keep it as compact and fast as possible, so that kind of functionality will probably be added to the GUI, so that the main binary remains small and fast.

Yes, you are right, we'll add it in next main release 1.4.0.0