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

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

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

@Tristis-Oris indeed seems like thats a bug in xoa that it does not delete the snapshots

@Tristis-Oris migration of a vdi between sr is not supported with cbt enabled. U need to disable cbt first. This is done by xoa. Live migration of vm between hosts is supported as long as the sr stays the same. This is by design on xen

Hi all,

we are trying to deploy a new kubernetes cluster, in the recipe i need to give an ssh key, we generated an ssh key with puttygen and copied the content of the openssh public key field. however this seems to not work. it failes with an error on the deployment of the first control vm after setting the key. What am i doing wrong? what do i need to set in the ssh key field?

cheers Robin

@olivierlambert we are starting to develop the synology version this week. I will ask my developer to contact you or support if he has any questions.

@DustinB thanks all, the agent based backups seem to work the way we need, we removed the older alike backup appliances so fully on xoa backup now. I saw alike is going opensource but almost no activity on the github account, i expect that the product will discontinue as it is allready pretty outdated, nice chance for XOA to fill the gap.

@Rhodderz ok so it’s not only related to v8.3 as we were assuming. Or somerhing else is going on in your env. What happens if u use normal backup without cbt?

@Rhodderz are u also on 8.3?