Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Fixed in 1.6.0.3

A wrong data type in a printf statement would cause a SEGFAULT in command with increased verbosity only.
This bug was solved in 1.6.0.2.

Sorry about the delay.

Well, we would need to know the context. That notice may very well just mean what it says. You will get that on a stopped VM per instance. Or maybe for some reason the -ctk.vmdk files are not being updated. Contact support if you believe you face some kind of trouble.

UPDATE:

We have conducted a number of tests and we were able to reproduce your reported behaviour to some extent. We are working on it and will post back here when we are done and know exactly what is going on.

To make sure that you copy all your data we suggest that you do a full checksum based backup by removing the cbt flag.

UPDATE:

Your reported behaviour can occur if you keep a snapshot on the VM being CBT backed up. This may be a bug in 1.6.0.1, as when using CBT ©XSIBackup should delete any previously existing snapshot. We'll delve on the issue and eventually release a fix as 1.6.0.2.

In any case, if that is your case (you have some snapshot), the notice is correct and the new data is being saved to the snapshot file, thus we still have to determine whether this should be considered a bug and ©XSIBackup should delete any previously existing snapshot, or on the contrary could be considered just normal behaviour, as your data would be commited to the base disks and copied by CBT once you commit that snapshot to the base disks.

On top of that, the snapshot containing the new data would be copied along with the rest of the VM files, thus you would indeed be backing up everything you need.

CONCLUSION:

In the end, after some through inspection, we didn't detect any anomalous behaviour. Below we dissect the matter up so that you can make your own assesment. Of course this does not exclude the possibility of some more complex issue on your side, still we have very limited information from your part.

We'll stick to --replica action which is what you reported. In this case all snapshots are indeed deleted when the =cbt flag is used, this is working fine as per our tests. Thus, if you are still getting "The CBT sequence has not changed since last backup" message, the possibilities are:

1/ The VM is off. Too obvious, but has to be on the list.
2/ The VM didn't change indeed. This is rare, as at least some logs will be updated every few minutes, but can happen in some OSs. We have been able to corroborate that in some CentOS 6 VMs, the -ctk.vmdk files aren't updated even after taking a new backup snapshot during a rather long period of time.
3/ The -ctk.vmdk files were imported/moved with the VM from a different host but the --reset-cbt argument wasn't run.
4/ The CBT feature isn't working right in the ESXi host.

UPDATE:

According to (c)VMWare, Community Supported VIBs will no longer be allowed in (c)ESXi 8.0
[url]https://kb.vmware.com/s/article/76276[/url]

We have applied for a (c)VMWare partnership in order to be able to sign an eventual (c)XSIBackup VIB that would run in (c)ESXi 8.0
Nonetheless, this step fully depends on (c)VMWare's willingness to do so. From (c)ESXi 8.0 only software certified by (c)VMWare will run in their hypervisor OS (c)ESXi

Could be, still, we will revise the logic.

Well, restoring does not require much memory, unlike some other actions such as --prune or --repair. Something must be causing the SEGFAULT though. Still you may want, first of all, increase the memory pool by adding the following argument: --memory-size=4096, which will increase the default (c)XSIBackup memory pool size from 800MB to 4GB, just in case you are running out of memory for some reason.

Secondly increase verbosity, or even better, use the --debug-print argument at the end of the job which will increase verbosity and add some extra debug messages.

./xsibackup \
--restore \
/vmfs/volumes/nfs_typhon_xsi_olympus/xsi_repos/2021_DC/20221204020530/vlpr-mongodb01.prd.saas.dpp.company.network \
/vmfs/volumes/ssdvol/restored/ \
--memory-size=4096

If that doesn't offer you any hint, you can visually inspect the -flat.vmdk.map file. Download a copy and open it with Excel if you will. It must contain two columns: hash and block size.

Of course, you will get the highest level of debug resolution by running the restore job prepending strace to the --restore command. If you need to do so post the last part of the strace output, the last 20-30 lines before the SEGFAULT.

strace \
./xsibackup \
--restore \
/vmfs/volumes/nfs_typhon_xsi_olympus/xsi_repos/2021_DC/20221204020530/vlpr-mongodb01.prd.saas.dpp.company.network \
/vmfs/volumes/ssdvol/restored/ \
--memory-size=4096 \
--debug-print

You performed a --check on the backup, thus it seems to be right, still a basic check just tests that the blocks exist. You can use --check=full iinstead, which will not only check that the block file exists, but will on top of it uncompress the block and make sure that the actual SHA-1 hash of the file coincides with the stored one.

BTW: please define "pretty big"

Just as long as you don't delete the contents of the virtual disk you can just share it. Version 2.1 contains just some fixes, the rest is the same as in previous one.

Not enough info to give you an answer. We do not know the (c)ESXi version, the (c)XSIBackup version, the backup job nor the output (apart from the error itself).

Sure. Just remember that the --backup-room figure is given in GB and to leave some security margin to not fill your disk up.

Variables will be added to custom subjects in release 1.6.0.0

Preview versions can be unstable and still contain some bugs. We just published 1.6.0.0 RC008 which is much more stable.

Thank you for your feedback. Please make your clients contact us at support<AT>33hops.com and we will revise the captcha issue.

UPDATE:
There was indeed one error in one of our servers, the other two were working fine. You should be able to use the contact form normally now.