Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Please, note this thread corresponds to an old software edition - (c)XSIBackup Classic - which has been deprecated. Use our latest software edition: [b](c)XSIBackup-DC[/b] and refer to [url=https://33hops.com/xsibackup-dc-full-manual-home.html]its manual[/url] to [url=https://33hops.com/xsibackup-vmware-esxi-backup.html#prodchart]backup your (c)ESXi VMs[/url] as of 2021

Thank you very much for your feedback.

Using NAS to store VMs is not a very good idea, unless you have FO or 10GB NICs, as you would create a 1GB bottleneck that you would not have if you used local storage.

The glitch every few blocks is probably caused by some buffer filling up.

On the other side, maximum speed is achieved when using SSD as the target of backups. Over IP backups yield better speed than local backups too, as you balance the load of the backup process among two CPUs instead of one.

The lock file is deleted once the process holding the repo finishes. Nonetheless there's something really 'twisted' in your question: how come you be trying to perform a simultaneous replica to a replica folder?, that makes no sense no matter how you look at it.

If you were allowed to do such thing, you would end up with a lot of meaningless data in the worst of the cases, or a mix of files belonging to different VMs if you were somewhat luckier.

A replica job is a 1:1 operation, by definition, it's even implied in the very same argument name "replica" you can't replicate two different things to a third one.

Backup repositories are a different thing. Please, revise basic functional concepts before attempting to use the software.

You may need updating the key, only if it's smaller than 88 bytes, which seems to be the case.

You will find a detailed guide to dealing with snapshot errors here: [b][url=https://33hops.com/esxi-snapshot-errors-and-solutions.html#vmsd-issue](c)ESXi snapshot errors, its solutions and workarounds[/url][/b]

OMG!, we just realized that you aren't backing up to an (c)ESXi server, but some sort of NAS.
How do you expect a VM to be registered in a NAS device?
This is just an imaginary issue.

We aren't saying that using --exclude will cause issues. We are saying that it's not compatible with --options=R, which a different thing.
We can't introduce comparisons with other editions that have nothing to do with the issue. We know how Pro worked, still it's different software.

What we are stating is that we have revised the software and that we are indeed getting an _XSIREP replica with no issue and that we can't reproduce your problem.

So, please, simplify your job to the extreme, remove any unnecessary options and add --options=R at the end of the job from the command line.

We can't reproduce your issue. Our local --replica=cbt VMs are indeed registered and can be switched on.
There are still some limitations that we will waive in next minor releases, like not being able to switch the _XSIREP VM on when you --exclude some disk, as the remains of the disk are still present in the replica .vmx file. We will need to add extra logic to remove those config lines in case of excludes.

Then, there must be some missing configuration parameter. Probably related to CBT configuration.
That isn't really the error. You have some previous text in the output that is pointing to the real issue:

ble-cbt="vm-failed" first

It's a partial message that should read: [b]Run --enable-cbt="vm-failed" first[/b]

Thus, have you enabled CBT? I guess you have, otherwise you would receive a clear warning, nonetheless it looks like something is wrong about it.

To make sure, just remove the [b]=cbt[/b] part from the --replica action and see what happens. If the rest of the data and configuration files are OK in the VM, you should not receive that error any more.

If my above suspicion is right, manually examine the .vmx file and look for the CTK related lines at the end of it. There should be one general line plus one per disk.

ctkEnabled = "TRUE"
scsi0:0.ctkEnabled = "TRUE"
scsi0:1.ctkEnabled = "TRUE"

There should also be a hidden directory tree in your VM root folder [b].xsi/.cbt/[/b], inside this folder there should be one file per disk.

.seq-W702-flat.vmdk
.seq-history-W702-flat.vmdk

Each file should contain the information on the backup targets and the CBT sequence for each one of them.

192.168.33.183:22:/vmfs/volumes/datastore1/W702; 125
78.27.168.186:22:/vmfs/volumes/VMs/W702; 213
78.27.168.186:22:/vmfs/volumes/datastore1/W702; 9
78.27.169.25:22:/vmfs/volumes/datastore1/W702; 1

Pruning is OK, we use it for our VMs, still you need to know how things work to take good decissions and pruning is an intrinsically risky action by definition, there's nothing that can be done to make pruning safer, as it consists in deleting the blocks [b]not in[/b] some set, the only way to know which blocks are to be pruned is to look for them and to delete the ones that can't be found.

What could be a fatal scenario?: your FS gets corrupted and some block name character is lost. If you don't prune, you could still recover that block manually by a partial match in the hash. If you prune, you loose it.

As said, we use pruning and we haven't had an issue so far, still, we keep multiple copies of our data at different levels and we make a full VM replication from time to time. If we were more commercially oriented, we would just not talk about it, yet (c)XSIBackup was conceived to fill some niche of users that do like to openly talk about everything concerning their data, namely: how all sys admins should be.

In an enterprise environment you normally want to keep a historic set of data, as much backwards in time as possible. (c)XSIBackup offers a huge compression ratio that will allow you to keep hundreds of restore points at practically no extra cost in storage, thus: why pruning?, to liberate a ridiculous amount of space?

There may be special cases of enterprises generating a vast amount of temporal data everyday, it's not usual but can happen. In those cases the sys admin will have to choose the best methodology for them.

Thank you for your feedback, I'm sure many users will find it extremely useful. As said, we'll try to add a helper to ease Office365 compatibility in some future version.

The server component is updated automatically on every run.