Hi All,

are there other users running 8.3 combined with CBT backups? we keep running into vdi's that stay connected to the control domain, we are investigating these with Vates as it looks like the problem is within xapi of tapdisk it would be helpfull to understand if there are others running into the same issue.

As far as i understand from vates it looks like the problem we face is somewhere within Xapi but we need more logging to understand it better. If anyone has this running with the same issues or without please let us know so we can compare.

Cheers!

Hi All,

First of all best wished to you all for 2025! I have just deployed the latest build to do some testing on the one remaining issue we have with cbt backups, we were still facing full backups on some vms, this is expected to happen because cbt is not activated fast enough on some vdi’s, i will update this post once it completed some test runs to let u know if this build resolves it (there is a fix inside this build that should fix it).

Robin

@andyh no cbt should be disabled, u can’t migrate an cbt enabled vdi.

You need to remove all snapshots before migration and disable cbt. Storage migration is not supported when cbt is invalid. I believe xoa should do this automatically however.

@florent ok thanks, but how does this work for a job with multiple retentions? if i have a job with 3 schedules and retentions set for this job, how does the sequence handle this, in other words as the retention is set on the schedule level and i disable 1 of 3 schedules, how does the sequence know what retention it should keep?

@Andrew we see the same behavior here, no strange backup issues so far!

Hi all, i can confirm the vdi_in_use error is resolved by https://github.com/vatesfr/xen-orchestra/pull/7960 we no longer see issues there.

Only remaining issue we see is the “ can’t create a stream from a metadata vdi fall back to base”

fbeauchamp opened this pull request 3 Sept 2024, 16:15 in vatesfr/xen-orchestra

closed feat(backups/CBT): retry data_destroy when error is VDI_IN USE #7960

@olivierlambert i have changed it to V3 and it feels like it is performing normally now. i need to do some more testing but it seems the synology does handle the read/writes better on V3 then V4.

@olivierlambert yes i will check this out as well. The mirror job itself seems to perform well, i changed the nfs to V3 as a first test for now, i read there is more overhead on V4, maybe this will improve things a bit. I will share the results!

@manilx nope, but i have talked with a dev about it and they are looking to make it a setting somewhere, don’t know the status of that. Good to see this works for you!

@julien-f and the stream error?

@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.

@Andrew need to do some more testing but second run does clean them out, keep u all posted on the results over the weekend!

All tests with 2 vms were so far succesfull, no issues found in our lab. Good job guys!

@olivierlambert in then end that will be the best, but i am inpressed with the experience of there team on Xen and XCP as well, i think they are a good addition to the allready complete list, to be honest so far there backup tool is doing better then the ones allready on the list.

@olivierlambert ok, is there a way we can keep an eye on this devepment? shall i open a feature request on this with support or what is the best way to proceed?

@olivierlambert, yes, but the snapshot doesn't need to remain till the next job is running. This distinction significantly impacts space requirements. You don't back up all your VMs simultaneously.

So far this seems to work well. we will test this and inform if there is any issue with it. On behalf of my customer i would like to thank you for the quick response!

@taghjichte not shure if i understand correctly but xoa is not intended to run on vmware, not shure if it does but u need to test, i think u can try connecting to your vmware endpoint by using xoa on you xcp side. Unstable will be a problem i guess, slow is just making it to take more time, however these two combined might be a problem, also it depens on how bug your vm is. U can give it a try off course. I think export it on vcenter to ova manual copy and import on xoa side will be more safe and reliable.

@DonZalmrol good to hear! Another good migration solved!