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 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?

@taghjichte is there a reason why u do not use the buildin feature of xoa for migration? For us this worked on all our vms.

@flakpyro good that the root cause is found, hope it is something that can be fixed by the xoa team.

I can confirm that the cbt backups are running as smooth as they did on vmware! Good job all!

@florent so this does mean it will never work when a forever incremental is used?

We are further testing with immutability and have encountered a question that came to mind. Suppose you run a 14-day backup, merging your oldest delta into the full backup every day. If you're doing forever incremental, the oldest file will keep being modified. This means that either this file becomes immutable for another 14 days after each merge, or it remains editable after 14 days, rendering immutability ineffective. How do you handle this in your setup?

@olivierlambert my pleasure, good to be a part of it.

Good news, this bug seems to be resolved!

Hope we can fix the migration bug as well!

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

@flakpyro very strange issue indeed, we can’t reproduce the problem on our end. So as @olivierlambert mentioned before it has to be something specific. The new developments make it indeed more difficult to understand, but i believe there is a logical explanation to this.

@florent Goodmorning,

We have prepared the script here https://github.com/Virtual-Computing-bv/Xen-Orchestra-Immutability-SYNOLOGY

Would it be possible for you to do a check on this script to see if u have any comments?

@florent thanks for the feedback, so if i understand correct, currenlty there can only be one retention be used, if u use a retention of 14 days and 30 days mixed, u can only set immutablity for 13 days, otherwise you would run into issues with merge?

maybe this is something we can think a better solution for in future versions. we will implement your comments into the script and test it on our lab. If it's working we will share the code.

@olivierlambert we have managed to get this working on a synology box. However i have some question regarding the first setup.

1. the file is locked for x days (let's say 14 days), it will then work for a backup of 14 day retention, what to do if u have different retentions per job? there is no way for the repository to know this. what theorie do you have for this?
2. someone with root access does still have the option to change the files is this a good idea?
3. this immutability is also for meta files in the repo, is this not an issues? in other words the repository meta files can's be changed for 14 days as well.

Hope u can give me some answers so we can proceed working on this feature.