<![CDATA[Feedback on immutability]]>Introduced in XO 5.91, we need people to make their own tests and report. You are welcome here!
See https://xen-orchestra.com/blog/xen-orchestra-5-91/ for details

]]>https://xcp-ng.org/forum/topic/8292/feedback-on-immutabilityRSS for NodeSun, 06 Sep 2026 21:14:34 GMTWed, 31 Jan 2024 13:54:23 GMT60<![CDATA[Reply to Feedback on immutability on Wed, 19 Aug 2026 09:02:38 GMT]]>@gsszuber Hi,
Yes indeed, you need to preserve the root of the bucket from Lifecycle. We just had a customer with a similar issue.
Can you help us by giving a small screenshot of the field to filter out the root (or filter in the three folders) please?

]]>https://xcp-ng.org/forum/post/107934https://xcp-ng.org/forum/post/107934Wed, 19 Aug 2026 09:02:38 GMT<![CDATA[Reply to Feedback on immutability on Mon, 17 Aug 2026 19:17:10 GMT]]>We attempted a similar configuration using Wasabi S3 cloud storage as the target. What we discovered is that the Lifecyle Rule we created wiped out metadata.json and encryption.json in the root of the bucket once those files were outside the retention window. It was a global rule and I'm guessing that we need to be more precise and use scoped rules that target just the xo-vm-backups, xo-config-backups, and xo-pool-metadata-backups folders. Does that sound like it would work? I have a ticket open as well on this.

]]>https://xcp-ng.org/forum/post/107869https://xcp-ng.org/forum/post/107869Mon, 17 Aug 2026 19:17:10 GMT<![CDATA[Reply to Feedback on immutability on Wed, 08 Oct 2025 07:17:28 GMT]]>Sadly, Backblaze is often having issues on S3 (timeout, not reliable etc). We are updating our doc to give a "tiering" support.

]]>https://xcp-ng.org/forum/post/98255https://xcp-ng.org/forum/post/98255Wed, 08 Oct 2025 07:17:28 GMT<![CDATA[Reply to Feedback on immutability on Tue, 07 Oct 2025 22:40:44 GMT]]>@olivierlambert
So it looks like the issue is not related to object lock or immutability but rather Backblaze not handling the merge requests very well. Not sure why this isn't impacting the other backup job without object lock, but anyways.... guess we're in the market for a different storage provider.

]]>https://xcp-ng.org/forum/post/98249https://xcp-ng.org/forum/post/98249Tue, 07 Oct 2025 22:40:44 GMT<![CDATA[Reply to Feedback on immutability on Fri, 03 Oct 2025 13:54:25 GMT]]>In theory that should work 🤔 Ping @florent

]]>https://xcp-ng.org/forum/post/98096https://xcp-ng.org/forum/post/98096Fri, 03 Oct 2025 13:54:25 GMT<![CDATA[Reply to Feedback on immutability on Fri, 03 Oct 2025 13:46:34 GMT]]>@olivierlambert
Any updates on this? We're using Backblaze buckets with compliance turned on at the bucket level, but we keep getting failures once the retention period expires and it starts to remove the old backup chains.

We tried setting 28 days of retention at the bucket level, 42 in XenOrchestra, and are running a full backup every 2 weeks. I have a ticket open with support but so far a resolution hasn't been found.

]]>https://xcp-ng.org/forum/post/98095https://xcp-ng.org/forum/post/98095Fri, 03 Oct 2025 13:46:34 GMT<![CDATA[Reply to Feedback on immutability on Wed, 25 Jun 2025 15:20:08 GMT]]>So what is the deal with these guy ?

]]>https://xcp-ng.org/forum/post/94388https://xcp-ng.org/forum/post/94388Wed, 25 Jun 2025 15:20:08 GMT<![CDATA[Reply to Feedback on immutability on Mon, 05 May 2025 18:30:20 GMT]]>Thanks for your feedback, we'll discuss internally if there's any other possible approach (and I'm not sure).

]]>https://xcp-ng.org/forum/post/92642https://xcp-ng.org/forum/post/92642Mon, 05 May 2025 18:30:20 GMT<![CDATA[Reply to Feedback on immutability on Mon, 05 May 2025 18:13:12 GMT]]>@vkeven same problem here, we decided not to proceed with this as it would never work with an incremental delta without doing a full every few weeks. We are going to handle this with s3 and synology internal features.

]]>https://xcp-ng.org/forum/post/92640https://xcp-ng.org/forum/post/92640Mon, 05 May 2025 18:13:12 GMT<![CDATA[Reply to Feedback on immutability on Mon, 05 May 2025 17:41:42 GMT]]>@olivierlambert We tried adding compliance( prevent any file manipulation for X period) directly into bucket but XOA could not do his backup job correctly and the logs are full of access denied probably because of file merging or manipulation refused , so how we should do this ?

]]>https://xcp-ng.org/forum/post/92639https://xcp-ng.org/forum/post/92639Mon, 05 May 2025 17:41:42 GMT<![CDATA[Reply to Feedback on immutability on Thu, 24 Apr 2025 08:34:50 GMT]]>Indeed, because if XO is compromised, then it could disable immutability.

]]>https://xcp-ng.org/forum/post/92197https://xcp-ng.org/forum/post/92197Thu, 24 Apr 2025 08:34:50 GMT<![CDATA[Reply to Feedback on immutability on Thu, 24 Apr 2025 07:53:22 GMT]]>@vkeven we don't have ( for now) the feature to create bucket directly from XO. Also I think it is more secure if XO don't know at all the credits of the bucket admin

]]>https://xcp-ng.org/forum/post/92189https://xcp-ng.org/forum/post/92189Thu, 24 Apr 2025 07:53:22 GMT<![CDATA[Reply to Feedback on immutability on Tue, 22 Apr 2025 16:11:20 GMT]]>Where is the doc for these ? edit ok right here https://github.com/vatesfr/xen-orchestra/tree/master/%40xen-orchestra/immutable-backups , with V**m there is an option for immutability when you add the S3 bucket directly so its look like its only a flag sent at bucket creation and using the versionning/compliance feature

]]>https://xcp-ng.org/forum/post/92099https://xcp-ng.org/forum/post/92099Tue, 22 Apr 2025 16:11:20 GMT<![CDATA[Reply to Feedback on immutability on Wed, 19 Feb 2025 18:35:01 GMT]]>@afk the agent is as dumb as possible

also if you encrypt the backup, the agent will need to decrypt the metadata to detect the chains, thus having access to the encryption key, which need getting the encryption key out of XO and transferred to the immutability agent

I think it will be easier to provide more feedback on the immutabiltiy backup, XO has access to the chain , and / or alert when something seems to be strange

]]>https://xcp-ng.org/forum/post/89902https://xcp-ng.org/forum/post/89902Wed, 19 Feb 2025 18:35:01 GMT<![CDATA[Reply to Feedback on immutability on Mon, 10 Feb 2025 15:26:42 GMT]]>@florent said in Feedback on immutability:

@rtjdamen for the immutability to be useful, the full chain must be immutable and must never be out of immutability

the merge process can't lift/ put back the immutability , and increasing synchronization between process will extend the attack surface.

immutability duration must be longer than or equal to 2 time the full backup interval -1
the retention must be strictly longer than the immutability .

for example, if you have a full backup interval of 7 a retention of 14 and immutability duration of 13 , key backup are K, delta are D. Immutable backup are in bold . unprotected chain are striked

KDDDDDDKDDDDDD worst case, only one full chain protected
KDDDDDKDDDDDDK
KDDDDKDDDDDDKD
KDDDKDDDDDDKDD
KDDKDDDDDDKDDD
KDKDDDDDDKDDDD
KKDDDDDDKDDDDD best case almost 2 full chain protected

I have not tried backups in XO yet but I'm really looking forward to test the immutability as we have it configured on all veeam backups at work.

Just to be sure, the XO immutability "agent" only does its immutability check by date right ?
Would it be possible to consider the entire backup chain related to the oldest immutable restore point instead ? This would prevent misconfigurations from the user that result in insecure backup chains.

]]>https://xcp-ng.org/forum/post/89484https://xcp-ng.org/forum/post/89484Mon, 10 Feb 2025 15:26:42 GMT<![CDATA[Reply to Feedback on immutability on Thu, 09 Jan 2025 13:35:55 GMT]]>@rtjdamen said in Feedback on immutability:

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

you can't have a immutable forever backup without having a infinite length, and an infinite

It may be possible only if we release the constraints.
The immutable script could release the immutability , merge the disks, but that means : the immutability will be lifted from time to time, and the responsibilities of the immutability script will be greater, and we'll need a way to track the vhd to merge and transmit the information to the immutability script

]]>https://xcp-ng.org/forum/post/87939https://xcp-ng.org/forum/post/87939Thu, 09 Jan 2025 13:35:55 GMT<![CDATA[Reply to Feedback on immutability on Thu, 09 Jan 2025 12:47:36 GMT]]>@florent so this does mean it will never work when a forever incremental is used?

]]>https://xcp-ng.org/forum/post/87935https://xcp-ng.org/forum/post/87935Thu, 09 Jan 2025 12:47:36 GMT<![CDATA[Reply to Feedback on immutability on Thu, 09 Jan 2025 09:47:15 GMT]]>@rtjdamen for the immutability to be useful, the full chain must be immutable and must never be out of immutability

the merge process can't lift/ put back the immutability , and increasing synchronization between process will extend the attack surface.

immutability duration must be longer than or equal to 2 time the full backup interval -1
the retention must be strictly longer than the immutability .

for example, if you have a full backup interval of 7 a retention of 14 and immutability duration of 13 , key backup are K, delta are D. Immutable backup are in bold . unprotected chain are striked

KDDDDDDKDDDDDD worst case, only one full chain protected
KDDDDDKDDDDDDK
KDDDDKDDDDDDKD
KDDDKDDDDDDKDD
KDDKDDDDDDKDDD
KDKDDDDDDKDDDD
KKDDDDDDKDDDDD best case almost 2 full chain protected

]]>https://xcp-ng.org/forum/post/87925https://xcp-ng.org/forum/post/87925Thu, 09 Jan 2025 09:47:15 GMT<![CDATA[Reply to Feedback on immutability on Wed, 08 Jan 2025 14:06:49 GMT]]>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?

]]>https://xcp-ng.org/forum/post/87874https://xcp-ng.org/forum/post/87874Wed, 08 Jan 2025 14:06:49 GMT<![CDATA[Reply to Feedback on immutability on Mon, 16 Dec 2024 08:11:57 GMT]]>@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?

]]>https://xcp-ng.org/forum/post/86956https://xcp-ng.org/forum/post/86956Mon, 16 Dec 2024 08:11:57 GMT<![CDATA[Reply to Feedback on immutability on Tue, 10 Dec 2024 20:36:51 GMT]]>@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.

]]>https://xcp-ng.org/forum/post/86736https://xcp-ng.org/forum/post/86736Tue, 10 Dec 2024 20:36:51 GMT<![CDATA[Reply to Feedback on immutability on Tue, 10 Dec 2024 16:24:33 GMT]]>@rtjdamen great work

  1. the immutability duration is per repository, to limit the attack surface to the bare minimum
  2. nothing can really be software protected against the root user. This is where physical device writable only once win
  3. it should ignore the cache.json.gz , but the json file containing the backup metadata are protected along the disk data. Same for the pool metadata/xo config

An additional note : to ensure that an incremental backup is really protected during n days, you must have

  • a full backup interval smaller than n
  • a retention greater than 2n - 1
    That way an attacker won't be able to modify the base disk used for restore
]]>https://xcp-ng.org/forum/post/86715https://xcp-ng.org/forum/post/86715Tue, 10 Dec 2024 16:24:33 GMT<![CDATA[Reply to Feedback on immutability on Tue, 10 Dec 2024 13:25:09 GMT]]>Thanks for the feedback!

Those are questions for @florent 🙂

]]>https://xcp-ng.org/forum/post/86696https://xcp-ng.org/forum/post/86696Tue, 10 Dec 2024 13:25:09 GMT<![CDATA[Reply to Feedback on immutability on Tue, 10 Dec 2024 11:56:51 GMT]]>@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.

]]>https://xcp-ng.org/forum/post/86689https://xcp-ng.org/forum/post/86689Tue, 10 Dec 2024 11:56:51 GMT