Comment by antoniomika
13 hours ago
This has been replaced with a permissions feature that still provides both delete and overwrite protections. The difference is the underlying store needs to implement it rather than running a server that understands the permission differences. You can read more about this change here: https://github.com/borgbackup/borg/issues/8823#issuecomment-...
This comment needs to be pinned, alongside what the developers say [0] since the change is very misunderstood.
> The "no-delete" permission disallows deleting objects as well as overwriting existing objects.
[0]: https://github.com/borgbackup/borg/pull/8798#issuecomment-29...
Isn't this "no-delete permission" just a made-up mode for testing the borg storage layer while simulating a lack of permissions for deleting and overwriting? In actual deployment, whatever backing store is used must have the access control primitives to implement such a restriction. I don't know how to do this on a posix filesystem, for example. Gemini gave me a convoluted solution that requires the client to change permissions after creating the files.
at first it was implemented to easily test permission restricted storages (can't easily test on all sorts of cloud storages).
it was implemented for "file:" (which is also used for "ssh://" repos) and there are automated tests for how borg behaves on such restricted permissions repos.
after the last beta I also added cli flags to "borg serve", so it now also can be used via .ssh/authorized_keys more easily.
so it can now also be used for practical applications, not just for testing.
not for production yet though, borg2 is still in beta.
help with testing is very welcome though!
Currently, you can either provide the `BORG_REPO_PERMISSIONS` env var to borg [0] or `--permissions` flag to `borg serve` [1]. You can then enforce this as part of your `authorized_keys` command, for example.
[0] https://github.com/borgbackup/borg/blob/3cf8d7cf2f36246ded75...
[1] https://github.com/borgbackup/borg/blob/3cf8d7cf2f36246ded75...
1 reply →
Thanks for that link. That issue somehow didn't come up when I researched the removal of append-only. The only hint I had was the vague "remove remainders of append-only and quota support" in the change log without any further information.
The old append-only mode was a hack that wasn’t very useful in practice anyway, because there were no tools to dissect changes in a repository and the datastructures wouldn’t support that anyway.
Making e.g. snapshots on the backing storage was always the better approach.