©XSIBackup-Free: Free Backup Software for ©VMWare ©ESXi

Forum ©XSIBackup: ©VMWare ©ESXi Backup Software


You are not logged in.

#1 2021-09-26 15:19:18

herrep
Member
From: Munich
Registered: 2019-07-08
Posts: 106

XSIBackup-DC 1.5.1.1: Further hints on --backup-cbt

Hi,

My way of backing up the VMs is to first create a replica of the VMs by using --replica=cbt and --options:R to receive replicated _XSIREP VMs that are registered at the ESXi host.

Now I want to continue and make a deduplicated backup from the replicated _XSIREP VMs. Up to now, I used the --backup functionality.

However, I noticed that starting with XSIBackup-DC 1.5.1.0 there is also CBT support for backup, i.e. --backup=cbt. I searched the manual to find some more background information and impact on particularly using --backup=cbt instead of --backup, but I could only find detailed information in conjunction with --replica=cbt.

I would like to clarify the prerequisites for moving from --backup to --backup=cbt:

Is it sufficient to --enable-cbt on the _XSIREP VMs and to start backup with a fresh repository when switching to --backup=cbt?

I would create a new repo each month, e.g. like this:

REPODATE=`date +%Y%m`
"<path>/XSIBackup-DC/xsibackup" \
--backup=cbt \
"VMs(^_XSIREP$)" \
"root@<nas>:22:<volume>/backup/repo-$REPODATE" \
--compression=yes \
--config-backup \
--backup-how=cold \
--remote-path="/usr/bin/xsibackup"

Is this setup recommendable? Particular drawbacks?

Best regards,
Peter

Offline

#2 2021-09-27 08:39:52

admin
Administrator
Registered: 2017-04-21
Posts: 2,055

Re: XSIBackup-DC 1.5.1.1: Further hints on --backup-cbt

This kind of set up is very convenient, we in fact recommend to replicate + backup to avoid the load on the production servers as much as possible, although (c)XSIBackup is an extremely light software in terms of footprint on the resources.

The only drawbackup would be the very same CTB subsystem failing, which has happenned in the past. Thus some full replica + backup from time to time is never a bad idea. As per your job, a new repository would be created each month, this would force by itself a full backup each first day of each new month.

Offline

#3 2021-09-27 09:54:07

herrep
Member
From: Munich
Registered: 2019-07-08
Posts: 106

Re: XSIBackup-DC 1.5.1.1: Further hints on --backup-cbt

Unfortunately, the above-posted backup job does not work.

Prior to --backup=cbt, I have executed --enable-cbt on each _XSIREP VM. The following problems occur, for which I created separate posts to discuss them individually:

a) "VMs(^_XSIREP$)" cannot detect any of my VMs ending with _XSIREP,
b) When I replace the above VMs regexp by a long list of VMs, xsibackup reports that --enable-cbt has to be executed first (although I have done this), and
c) When I use a remote path working correctly with --replica=cbt, under --back=cbt the missing repo directory could not be created.

So further guidance is needed as how to backup as suggested above.

Offline

#4 2021-09-29 14:58:09

admin
Administrator
Registered: 2017-04-21
Posts: 2,055

Re: XSIBackup-DC 1.5.1.1: Further hints on --backup-cbt

a) _XSIREP VMs are filtered out. You would need to rename them or wait until we create a switch to override this behaviour. We'll do it in next release 1.5.1.2. We'll most probably just waive the filtering when using REGEXP.

b) We'll check this and eventually fix any bugs.

c) We'll check this and eventually fix any bugs.

The above described recommended procedure, namely: create a replica and then backup the replica, is something we recommend since years ago from the times of our former solution (c)XSIBackup-Classic. The reasons are obvious and have alredy been explained many times.

Nonetheless, as you start to add variables to the equation, you must take care not to fall into any logical pitfall. Per instance: you must take into account that the original CBT information will not be valid in a newly registered VM cloned from the original one. In fact the cbt flag will automatically strip any CBT/CTK related information from the target VM.

Thus, if you want to in turn use CBT from the cloned VM, you will have to reenable CBT in it, still it will only be valid until the following CBT cycle is completed, as the CBT information will be again stripped from it.

As a result of the above dialectical discourse, you will easily deduce that you can't chain CBT due to the fact that CBT is accounted at a host level, thus any CTK files cloned from other host will be invalid.

Conclusion:

Replicate using CBT and backup without it. Given the fact that your replica is out of the production host, that shouldn't matter much.

Offline

#5 2021-09-29 15:32:50

herrep
Member
From: Munich
Registered: 2019-07-08
Posts: 106

Re: XSIBackup-DC 1.5.1.1: Further hints on --backup-cbt

Thanks a lot for this clarification!

Offline

#6 2021-09-30 17:54:09

admin
Administrator
Registered: 2017-04-21
Posts: 2,055

Re: XSIBackup-DC 1.5.1.1: Further hints on --backup-cbt

c/ We have checked this point and we can't reproduce your issue, dirs are created as needed.
b/ In regards to this other point, when some VM doesn't have CBT enabled in a list of them, a warning is raised when backing up the VM and a regular backup is performed.

Please always post the full job and the output when requesting support for this kind of things. If you are concerned that some private information might be leaked along with your output, please contact our support department for a more direct and private asessment.

Offline

Board footer