Originally, I started with a CBT-based replication of a VM that is properly registered as _XSIREP VM by using options --replica=cbt and --options=R.
However, for some VMs, I disabled CBT and changed the options to --replica and --options=R. I deleted the previously generated _XSIREP VM and cleaned up everything related to CBT. I still would like to get the replicated VM registered, but without CBT.
Unfortunately, --options=R does not show any effect, although the replication takes place on the same ESXi host. I can successfully replicate the VM, but the replicated VM is not registered. I neither find an output concerning a failed registration in the regular log file nor in the error log.
Is it planned behavior that --options=R only works in conjunction with --replica=cbt or is this a result of a strange setup on my side that requires further investigation?
Yes, the --options=R flag was thought to play along with CBT feature, it will not work with regular replicas.
We probably should extend this feature and will do so in the future.
What should I do in the meantime? I moved from XSIBackup Classic to XSIBackup-DC and try to reconstruct a similar setup where a registered replicated VM is backed up to a deduplicated repo. I have large independent disks that are not replicated, so I am not sure whether it is safe to turn on CTK also for these disks, although they are never replicated or otherwise incrementally backed up. (Their content is backed up via other means.)
Or will you add --options=R also for --replica within the next couple of weeks?
It won't take long for that to be available to regular replicas. Turning CBT on for VMs with independent disks is not an issue, they will just be skipped.
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.
That feature will be added before 1.5.2
--enable-cbt and --reset-cbt make no distinction between disk types. It enables CBT for all disks.
When a disk is not readable it is skipped, having CBT enabled or not for that disk makes no difference, the disk is skipped, everything else is ignored.
Performance overhead of CBT is negligible.
In any case, it's easy: do it and see if it does what you want.
I do not worry about a potential performance overhead of CBT. My issue is that all changes are tracked in a ctk file until the next performed backup. But if I enable ctk for a disk that is never backed up (at least not by means of CBT), I wonder what happens with the ctk file for this disk on the long run. Any thoughts?
As per your words:
I wonder about performance/disk usage if I enable CTK
As said: performance/disk usage is negligible.
In any case, you just have to tweak CBT to your needs manually, it's a trivial task.
The .vmx file holds one general line enabling CBT:
ctkEnabled = "TRUE"
Plus another one per disk:
scsix:x.ctkEnabled = "TRUE"
Just comment out or delete the disks for which you don't want CBT enabled.
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?
Yes, when using CBT a check is performed on all disks.
Enable CTK in general, then exclude disks or simply allow (c)XSIBackup to skip non accessible disks like persistent ones or RDM devices.