Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

You are not offering crucial details, such as the (c)ESXi version or wether you added some snapshot.
Nonetheless you will find some clues in [url=https://communities.vmware.com/t5/ESXi-Discussions/Unable-to-combine-Snapshot-file-with-Flat-file/td-p/1735027]this post[/url]:

Continuum's is probably the best advice you can get.

Next version will include the improvement.

(c)XSIBackup repositories need two sources of information to be consistent:

1/ The data directory where the blocks with the data are stored in a hyerarchy of SHA-1 hashes
2/ The disks' manifests (.map files) stored in the timestamped folders where the VM folders are created containing these manifest files.

When you perform a backup you start adding blocks to the data folder. Once each disk backup ends, the corresponding manifest is copied over to the VM folder.

If you interrupt a backup via Ctr+C per instance, you are going to have new blocks. Some of them will be associated to a manifest file, should the disk copy be completed, some others will be orphan blocks without any manifest file.

Asuming the simplest case, namely: a one .vmdk disk VM. If you interrupt the backup in the middle of the only -flat.vmdk file copy process. You are going to leave orphan blocks in the data folder. The timestamped folder is usually removed automatically. Doing the same with the copied blocks would require a lot of time and would make Ctr+C'ing some backup job a really annoying experience.

These blocks can't be matched to any VM, as they are the blocks that are new to that restore point. They will remain in the data folder and will be overwritten in case they are found again in some subsequent backup cycle.

They won't be an issue, still they will occuppy some space. This space will be minimal, as the increment of data from one backup cycle to the next is usually limited and most of them will be again present in subsequent backups, maybe a few MB could be regained by pruning them, still it's not worth doing it.

In fact we haven't even provided a mechanism to prune orphan blocks. Maybe in the future, although this is not a priority. The reason for this type of pruning not being a priority to us can be deduced from the exposed above: only some minimal space will be regained, if some at all, while pruning this data would require traversing all blocks in the FS to check whether they are present in the .blocklog file or not. Approximately about the same time a prune process requires, given that the most time consuming task would be the stat() system call itself for every block in the repo.

One possibility to avoid leaving these orphan blocks would be to copy the blocks to a temp hyerarchy to then rename them to their final positions. We have evaluated this possibility since the beginning, still it could take quite a bit to rename them to their final destination folder. We'll keep this in mind and eventually incorporate it as an improvement if we find the average amount of time required to rename the blocks is worth the benefit.

To those of you getting sick thinking about those orphan blocks there, we just remind you that engineering is about results, not perfect beauty. When beauty can be achieved it's a bonus, still it's not the aim of the project. If you can't still get those blocks out of your mind, we would suggest that you start a career in mathematics ;-)

[quote]
However, XSIBackup-DC ignores this warning, does not raise any error and successfully completes the backup without any further issues.
[/quote]
As said, conservative by design.

[quote]
Unfortunately, this behavior is not kept the same way for the second issue: Sometimes, the destination system does not correctly report back the amount of available space. This second issue, while resulting in the same situation of not being capable of predicting whether the backup will fail or not, is treated differently:
[/quote]
Of course it's treated differently, it has nothing to do with lack of space. This error is telling you the remote command to retrieve the available space failed.

[quote]
I do not know what design constraints are behind this decision, but from a user experience the same result is treated differently.
[/quote]
You are comparing two different situations that have nothing to do between them.

There is indeed a bug when combining _XSIREP + REGEXP + --options=O that we will fix in short in version 1.5.1.5.
When using the VM name + --options=O the VM selection mask is working for us in every case.

Was that the exact sequence of events?
We have tried to reproduce this behaviour, still we couldn't.
We know it's perfectly possible that such a bug could be present, still it might depend on the (c)ESXi version.
Please, let us know as much details as you can.

Yes, this is a limitation, we'll address this in future versions.

Independent disks can't be backed up. (c)XSIBackup does exclude them from the .vmx file.
For every reason that you find to keep the independent disk in the .vmx file we will find three not to do it.
Nonetheless, as you state, it's very easy to just add it again should you need to do so.

You can't do that.
--options=R only works with CBT as of version 1.5.1.4.
You aren't stating whether you are using CBT.
You can't use CBT on a _XSIREP VM.

You are making wrong assumptions on the functioning, not only of (c)XSIBackup but also on (c)ESXi itself.
CBT information is kept by host. If you replicate a VM from one host to another, your get a replica of the original VM and just that.
You are making the wrong assumption that the CBT state of that VM at host A will be transmitted to host B, which is not the case.

You just can't do what you pretend to do. CBT information is kept at the host level. When you backup some VM you backup just the VM, not the CTK information associated to it.

Please provide the backup job and full output.
You have 11 errors, those are quite a few. You should have them before the last one.

As a rule of thumb prepend strace to any job to have a full detailed output at the system call level and check the remote error log at /var/log/xsi if backing up or replicating over IP.

The simplest and most effective way to multiply your backup speed is to use CBT:

[b][url=https://33hops.com/xsibackup-dc-full-manual-home.html#cbt]--backup=cbt[/url][/b]
[b][url=https://33hops.com/xsibackup-dc-full-manual-home.html#cbt]--replica=cbt[/url][/b]