Is it sufficient to remove the .xsi folders inside a VM directory to have xsibackup take a full backup to a new repository again?
Reason is we don't prune xsibackup repositories but use new empty ones and back up the old repositories to tape and delete them after a month from disk. If we have to execute --reset-cbt each time we cycle a repository this means the server will have downtime and that could be problematic for some servers.
Last edited by wowbagger (2022-01-05 16:43:08)
Yes, you can do so to force a full resync, still if you want to do it the right way having finer control on what's going on, you should edit the files in:
There is one per disk:
YOUR-VM/.xsi/.cbt/.seq/.seq-YOUR-VM-flat.vmdk YOUR-VM/.xsi/.cbt/.seq/.seq-YOUR-VM_1-flat.vmdk YOUR-VM/.xsi/.cbt/.seq/.seq-YOUR-VM_2-flat.vmdk
The content of one of this files could look like the following
--replica:192.168.120.201:22:/backup/replicas/YOUR-VM; 1 --replica:192.168.10.110:22:/backup/some_other_replicas/repo01/YOUR-VM; 1 --replica:/vmfs/volumes/backup4/repo-test02/YOUR-VM; 5
Each line represents one target:
You can modify the sequence number in any target and (c)XSIBackup will retake the syncronization from that point. If you set it to 1 you will produce a full resync.
On top of that you can pass the sequence number directly from the command line like:
./xsibackup --replica=cbt:1 "VMs(YOUR-VM)" /vmfs/volumes/backup/replicas
Edit carefully and practice before using in a real scenario.
To keep finer control once you have some CBT job running for some time use the alternative command line option or edit the files. Per instance to resync some previously synced blocks if you changed some faulty HD per instance. In any case, if you want to make sure that you completely reset the .cbt feature, deleting the .cbt dir is the best way to ensure you clean any related info.