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

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

@olivierlambert for now we will go with Nakivo as we allready have a good experience with them, i will explore te agent based backups there to see if they can help to improve the backups of these vms. thanks again for the prompt response!

@olivierlambert thank u for the quick reply, i was also thinking about agent based backups, do u have any experience with a good tool for this? We prefer working with opensource tooling but if it's a paid tool i also have no problems with it. Maybe u know how some other customers deal with this kind of backups!

Hi,

I need some advice, We have several windows based fileservers running as a vm, most of the time they have a disksize of 2tb. These fileservers server FSlogix profile disks, these files are under heavy io. This io makes it difficult to do proper backups. Since we migrated to XCP-NG we did this backups with CBT based backups on Alike Backup. As they are no longer supporting there product we cannot rely on there support. The appliance used for this backups is giving more and more problems and restores are also not always working as required. We need to switch to a different solution for this.

Currently CBT backups in XOA are almost rocksolid, but still we see some issues now and then what causes a new full, for this kind of vms this does take almost a day to create a new full and it requires a lot of backup storage (no deduplication). So that is not ideal.

Is anyone having the same sort of problem and how did u solve it? What backup solutions could help us out? Anyone have experience with CBT in XOA with vms this big?

Another problem of the high io is the coalesce process for these backups, vms this size take a long time to coalesce and with cbt enabled with purge data it needs to freeze the vm for some time, as the io load is high it does not always manage to coalesce the disk and runs into a timeout.

Hope anyone could give me some advise on this!

@flakpyro we are still on 8.2 sor maybe there is some difference there.

@flakpyro are u running the latest xcp-ng version 8.2 or 8.3?

@flakpyro i have just tested live migration and offline on our end, both kept the cbt alive. Tested on both iscsi and nfs.

@flakpyro is there any difference in migrating with the vm powered on or powered off?

@flakpyro both scenarios

@flakpyro i can't reproduce this on our end, after migration within pool on the same storage pool the cbt is preserved. When i migrate to a different storage pool the cbt is reset.