Feedback on immutability
-
When working on this later on it maybe worth checking out lru-cache to see if inflight can be replaced. Due to inflight not being supported and leaks memory.
-
@olivierlambert any update on this item?
-
@olivierlambert Hi Olivier, it is pretty quite on this subject for a while now, any news or updates to expect?
-
Hi,
Immutability is still possible via your S3 provider or via the Linux script we provided. It's still in the backlog to see how to get it integrated with 3rd party providers.
-
@olivierlambert is this something we can help develop? what language is it currenlty being written? maybe i can ask our developer to have a look an contribute.
-
The question is: what's the exact target to get immutability on?
-
@olivierlambert in general i believe creating it inside synology would be good for us but i can imagine an universal kind of solution would be the best.
-
It's not possible to have an universal solution, I mean we did a Linux solution, but as you can see each system is different (TrueNAS and such). So we should start with what people need/ask first
-
@olivierlambert agree on that, nas in general is a good solution for backup repos, we work with synology for years but i can imagine others have different solutions. We worked with nakivo prior to XOA and they supported several nas based versions, all app based, i can check with them on this if u like.
First goal for me would be to get it working on synology. -
I'm fine to target Synology first, so we need a dedicated resource to know how to build Syno app, because we have no idea.
-
@olivierlambert said in Feedback on immutability:
I'm fine to target Synology first, so we need a dedicated resource to know how to build Syno app, because we have no idea.
If you later target TrueNAS bear in mind that TrueNAS Enterprise has immutable Snapshots support.
Also TrueNAS Scale is based on Debian Linux and with the most recent update it's using Docker containers for its apps functionality.
-
@olivierlambert i will discuss with my 2 developers to see if this is something we can do internally or if we need to involve someone else. Who is doing this within vates? Can we discuss them directly?
-
That's still @florent and you know he's pretty busy ATM
However, you should have the immutability script available around to adapt it for Syno, it shouldn't be really hard and since it's fully self-contained, I don't see any risk to work on this Happy to review any contribution!edit: source code is here: https://github.com/vatesfr/xen-orchestra/tree/master/%40xen-orchestra/immutable-backups
-
@olivierlambert haha, let's not disturb @florent with this indeed, i will ask my dev to see what we can do with it and if we can adapt it to one of our syno boxes!
-
Also interested and willing to test on Synology support for this feature.
-
@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.
-
@olivierlambert we have managed to get this working on a synology box. However i have some question regarding the first setup.
- 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?
- someone with root access does still have the option to change the files is this a good idea?
- 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.
-
Thanks for the feedback!
Those are questions for @florent
-
@rtjdamen great work
- the immutability duration is per repository, to limit the attack surface to the bare minimum
- nothing can really be software protected against the root user. This is where physical device writable only once win
- 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
-
@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.
