CBT: the thread to centralize your feedback
-
I did some digging on this orphan snapshots. i found this error in the backup logging for these vms
Couldn't deleted snapshot data
error
{"code":"VDI_IN_USE","params":["OpaqueRef:d52c23f7-4008-45e0-9852-6ecb3aeb8567","data_destroy"],"call":{"method":"VDI.data_destroy","params":["OpaqueRef:d52c23f7-4008-45e0-9852-6ecb3aeb8567"]}}
vdiRef
"OpaqueRef:d52c23f7-4008-45e0-9852-6ecb3aeb8567"i do not see them currently on normal vms and also not on second run
-
It worked just fine for me during an overnight unattended backup. I also did a manual backup to watch things.
Couple questions:
- If NBD is used, is there a 100% chance that CBT will also be used, or is it possible to have a NBD backup without CBT?
- Can it be added to the xo-server-backup-reports emails that NBD/CBT was used?
-
This post is deleted! -
It seems the orphan vdi is showing when the data_destoy fails, maybe the vdi is not yet ready? @florent Is this something you can look into? Maybe a retry when it fails?
-
most of backup succed, but few suddenly looks like:
-
From what i have seen if CBT fails for some reason, the chain is broken or the metadata is missing it will fall back on single NDB, most likely a new full.
-
Enabling the new Purge snapshot data when using CBT on Delta backups
results in
cleanVm: incorrect backup size in metadata. But it seems to be successful anyway.
Update: I'm getting this regardless of what "Purge snapshot data when using CBT" is set to. So I'm right now not sure about what causes it.XOsource: commit 96b76. ?
-
[NOBAK] tag is ignored with CBT patch.
before update it works fine. no 2nd disk available for restore.
my share is run out of space)
-
@Tristis-Oris is it any way to remove only 1 disk backup chain, to not wait rotation? i can't just clear everything.
-
@ajpri1998 IIRC:
- CBT will be enabled as soon you use NBD, no other choice (having 2 different code paths was too prone to problems and bugs, without forgetting the initial VHD diff code)
- Sure, we can do that! Telling @Bastien-Nollet about it
-
I started seeing this error this afternoon.
The failed job also happened to run after a monthly backup job that I have setup that does a full backup to some immutable storage that I have but I am not sure if it is related I just wanted to add that information. Below is the log from the failed backup.
2024-07-07T11_00_11.127Z - backup NG.json.txt -
@Delgado I saw those errors when I disabled/enabled CBT on disks or changed the NBD+CBT option in the backup job. If you have more than one job that works on the same VM you need to have the backup options the same.
I think that migrating the VDI to a different SR also changes the CBT setting.
-
@Andrew Thanks for the info! I had a feeling it may have been that one normal backup mode I ran. I'll stick to the deltas.
-
@olivierlambert Having a strange failure now (XO and XOA the same). I'm trying to migrate a VDI (only) to a new SR (same pool) after it has been backed up with CBT enabled. The VM is off (cold). XO disables CBT and requests the migration but the migrate fails and it tries again repeatedly endlessly. If I delete the snapshots then it moves.
-
@Delgado Full/CR/Delta backups should work as long as CBT is left enabled on the guest VDI and other backup jobs don't disable it.
-
@Andrew interesting thanks. I didn't disable nbd + cbt in the delta job or cbt on the disks. I just set up another job as a normal full backup mode.
-
@Andrew hi Andrew, when u migrate a vdi CBT has to be disabled, XO will take care off this. I think the snapshot has to be removed as well. Looks like the code for this is not functional yet.
-
Thanks for the feedback, @florent is back on Tuesday
-
@olivierlambert, I first want to compliment the work that has been done. As a first release, it already seems very stable. I have shared some logs with support to investigate the data_destroy issue and some minor error messages that appeared. We managed to migrate all our backup jobs to CBT over the weekend. It was challenging to coalesce all the snapshots, but it has been completed. The difference in coalesce speed is significant, which is a great improvement for XOA backups. I will monitor the backups and observe how they evolve in the coming weeks.
Please let us know if you need any additional input or if there are any updates regarding the data_destroy issue.
-
Thanks for the feedback @rtjdamen
We will do a full sweep with the feedback in this thread and continue to monitor the situation. Also, we switched our own production on it, so if there's issue we will also be on the first seat
