Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

I tried the setup of enabling CTK for selected disks only with an earlier version of XSIBackup-DC 1.5.x.x. Of course, I made sure that CTK was enabled for all those disks that formed part of the CBT-based replication with options --replica=cbt and --options=R, i.e. CTK was disabled only for disks excluded from backup/replication.

But the result was that XSIBackup-DC seemed to check whether CTK was enabled for all disks of the VM, irrespective of being part of the backup or not. Therefore, --replica=cbt did not work when having CTK disabled for the disks excluded from replication. Did you change the behavior for the present version of XSIBackup-DC so that the CTK enable check is indeed only performed on those disks which have been selected for backup/replication?

Is there a release version number in sight where VM registration via --options=R is also vailable when simply replicating without using CBT, when replicating by option --replica?

As mentioned in reply #3 above, I avoid CBT for particular VMs because they have large independent disks that are excluded from backup/replication. From your reply #4 I understood that you had no concerns to turn on CBT for such a VM, as the independent disks will be skipped.

I still have concerns when doing so: I understood from the CBT feature implemented in XSIBackup-DC that, as a pre-requisite, CTK needs to be enabled for all disks of the respective VM, even for disks that are excluded from backup/replication. This leads me to two dicussion points:

1. Is it really required to enable CTK also for disks that are excluded from backup/replication in order to use CBT in XSIBackup-DC? I have no idea why this limitation needs to be applied. Probably I have a wrong understanding of CTK/CBT or there is a limitation in XSIBackup-DC that is not really necessary and should be optimized: By a check whether CTK is enabled for the VM plus only for all those disks that are included in the backup, i.e. there is no need to enable CTK for disks that are skipped.

2. I understood that CTK tracks all changes applied to a disk since the last backup. I wonder about performance/disk usage if I enable CTK on a very large independent disk that is never backed up. Will the CTK file increase and increase? In fact, I am scared about turning on a feature used for tracking changes over usually limited time intervals if this time interval here is in fact unlimited.

I would assume that it implies a risk in performing hot backups if the memory state is not saved. But probably I did not fully understand the way how the hot backup/replication is performed. Therefore, I would appreciate if you could shed some light onto hot backups in conjunction with not considering the memory state.

Good to know that non memory snapshots are taken by xsibackup. Am I right that --backup-how=hot is equivalent to restoring the disk state at the point of the backup/replica, but the memory state is lost, like when switching of the VM without shutdown? However, this should have no impact on cold and warm backups, as the VM is shut down, thereby having no memory state at all.

The same also applies to --reset-cbt were the VM is also started even if it was turned off before.

Thanks for clarification. Just to make sure: When I run --replica as hot backup without shutting down the VM during replication, I assume that .vmsn contains the memory state of the machine. Therefore, the old .vmsn files are not of any use as I cannot revert the VM to a previous state, but the last .vmsn is essential if I want to continue right after the point of having performed the replication. Therefore, I can delete all "old" .vmsn files in the replicated VM directory, but should keep the last .vmsn file. Is this correct?

I run replica cbt with hot backup, so I assume it would be good to keep always the latest .vmsn file so that the replicated VM contains also the active state information. Is my understanding correct that in such a replicated VM only keeping the last .vmsn file makes sense? I wonder why all previous .vmsn files and all previous quiesce manifest .xml files are kept when there is already the next cbt cycle?

According to my understanding, the replicated VM does not allow to roll back to a previous CBT cycle. For this purpose, I would need to deduplicate backup the replicated VMs. Then I can access any CBT cycle. Is my understanding correct?

For the purpose of using the replicated (and registered) VM, I assume that none of quiesce manifest .xml file is necessary - they are only relevant for analysis. Is my understanding correct?

I got the point that a backup destination specified on a remote host having no ESXi functionality cannot lead to a registration of a replicated VM. However, in my setup, the backup destination is also accessible as an NFS drive at the ESXi host.

Of course, I continued in the present case by replacing the remote destination by a local path which results in storing the replicated VM on the same location as previously, but with the ability of being registered afterwards. Now I wonder whether there is a way of optimizing this setup.

I would prefer transferring the VM data via the remote path with xsibackup remotely executed on the NAS. And then, once the data are over there, I would like to register the replicated VM, but of course over the local path. Would this be somehow possible, e.g. bei running --options=R separately or whatever?

Or would this be a new feature request resulting in an option to specify the local path?