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