Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Not possible in Free version.
You can always edit the code yourself, of course, just as long as you comply with the license terms and do not redistribute the changes.

We have checked the fast XSITools block check function and it is working O.K. for us. Please, contact support so that we can offer alternatives to narrow your problem down. In any case it looks like it's something affecting just you by now.

XSIBackup free has no limits at all, on top of that it should be much faster than your Nakivo described scenario. The only caveat is that XSIBackup-Free will allow you to:

1 - Perform full backups with [b]Vmkfstools[/b] (--backup-prog=Vmkfstools). No recovery points.
2 - Perform differential backups with [b]Onediff[/b]. Similar to [b]CBT[/b] but no recovery points, al backups are consolidated to the destination VM.
3 - Use [b][https://33hops.com/xsitools-vmfs-deduplication.html]XSItools[/url][/b], it's differential with recovery points, but you have no restore module, it's a Pro feature.

Your best bet would be using [b][https://33hops.com/xsibackup-pro-onediff.html]Onediff[/url][/b] combined with [b][https://33hops.com/xsinas-deduplication-backup-device.html]XSINAS[/url][/b], our free deduplication appliance. That way you could take advantage of OneDiff feature along with the compression offered by deduplication, still no differential feature.

--backup-prog=Xsidiff is not differential, --backup-prog=Onediff is indeed differential, as well as --backup-prog=Xsitools:z and --backup-prog=Rsync

You are most probably using XSITools. That is a deduplication engine that is offered as a write-only feature. You should not use it if you just use the Free version and you are not thinking about buying the Pro.

You can't use a VM stored in a deduplicated repository directly, you need to restore it.

Use [b]--backup-prog=vmkfstools[/b] to generate plain VM copies that you can use directly.

We would need more info. The best you can do is to avoid the fast check, which actually just compares sizes and perform a full check on the repo. That will take longer, but will throw more information.

--certify-backup=yes, instead of --certify-backup=fast

The text [b]1: bad number[/b] is a shell error, some amount is being compared to something that's not a number, but that in turn comes from somewhere else, so the full log is neccessary to offer more advice. Please, contact support to provide the details of your case.

A bad block issue is something very rare and is usually related to hardware flaws. In your case, it seems to be a secondary error.

NFS4 is broken in ESXi shell, use NFS3. NFS4 is useless for backups.

Your df binary functionality seems to be broken. Reboot and if the problem persists, reinstall ESXi. Avoid low end flash devices and USB drives as the boot device.

[b]vmkfstools[/b] does indeed create thin VMs. The problem is that for this to be possible the underlying file system must support sparse files. VMFS5 does, as well as VMFS6. Regarding NFS, the same happens, you won't be able to retain the sparsness of your files if you backup to an NFS share which underlying file system does not support the feature.

In regards to your Windows file properties screenshot, its showing a sparse file. You are probably being puzzled by what a sparse file is and what to expect seeing when you use certain visual tools.

In a sparse file, the nominal size of the file as seen by the file system is its full size. The only difference is that it's empty space is filled with nulls and some file systems are able to use this to just allocate space for the non-null blocks and thus use space more efficiently.

You probably noticed that vmkfstools didn't copy all data. You can visually notice it, as it jumps over zeroed or nulled zones and the percentage progress jumps along with it, taking a lot less time than expected.

[url=https://en.wikipedia.org/wiki/Sparse_file]What are sparse files?[/url]

Thank you for your feedback, I'm sure that other users will appreciate it..

That seemed more like your ESXi host was caching some path info

If you used a proper naming convention, you would not need to change regular expressions all the time. Your problem is that you are trying to accomplish an exigent goal with a poor design.

Just rename your VMs so that they reflect the DS they are sitting at in their name and use a regular expression.

That "Still waiting..." is out of place. I don't know if you are aware of the fact that you are requesting others to offer you some advice for free. So, don't be that picky when it comes to ask for help that you are not entitled to receive.