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-...
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.
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.
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.
I also use nginx with HTTPS + HTTP authentication in front of it, with a separate username/password combination for each server. This makes rest-server completely inaccessible to the rest of the internet and you don't have to trust it to be properly protected against being hammered by malicious traffic.
Been using this for about five years, it saved my bacon a few times, no problems so far.
We just started deploying this on rsync.net servers - which is to say, we maintain an arguments allowlist for every binary you can execute here and we never allowed 'rclone serve' ... but now we do, IFF it is accompanied by --stdio.
I use restic+rclone+b2 with an api key that can't hard delete files. This gives me dirt-cheap effectively append-only object storage with automatic deletion of soft deleted backups after X days.
While at it, what do you think about Kopia [1]? It seems to use architectural decisions similar to Restic and Borg, but appears to be much faster in certain cases by exploiting parallel access. It's v0.20 though.
After this time I must have tried Kopia (via KopiaUI) at least a dozen time and every single time I have never been able to figure out in one glance how it works. A brief idea I have is that you pick a folder and pick where to backup/snapshot it to. There is no (or at least an easy and intuitive) way to have a local backup setup of a set of folder, exclusions, inclusions, a config where you can decide the frequency, retention etc. I did try hard to find that out but nothing. I think it's their deliberate design choice and that's fine - but at least from usability perspective it's anything that is even in the direction of backup tools like restic/backrest, borg/vorta etc.
Borg is a fork of Attic, not restic. Restic is also written in Go while Attic/Borg is in Python.
For me the reason to use Borg over Restic has always been that it was _much_ faster due to using a server-side daemon that could filter/compress things. The downside being you can’t use something like S3 as storage (but services like Borgbase or Hetzner Storage Boxes support Borg).
That’s probably changed with the server backend, but with the same downside.
restic’s rest-server append-only mode unfortunately doesn’t prevent data deletion under normal usage. More here: https://restic.readthedocs.io/en/stable/060_forget.html#secu.... Their workaround is pretty weak, in my opinion: a compromised client can still delete all your historic backups, and you’re on a tight timeline to notice and fix it before they can delete the rest of your backups, too.
That article says that a compromised client can not delete your historic backups, however, a compromised client could create enough garbage backups that an automatic job by an non-compromised administration account could delete them due to retention policies.
I'm not sure what exactly you expect that would be different?
Here's a very actively developed GUI https://github.com/garethgeorge/backrest - imho it has come the farthest and is the easiest in terms of use and ease. I have tried too many other restic CLIs/GUIs and settled on this.
My current approach is restic, but I'd prefer to have asymmetric passwords, essentially the backup machine only having write access (while maintaining deduplication). This way if the backup machine were compromised, and therefore the password it needs to write, the backup repo itself would still be secure since it would use a different password for reading.
It seems the suggested solution is to use server credentials that lack delete permissions (and use credentials that have delete for compacting the repo), but does that protect against a compromised client simply overriding files without deleting them?
No. Delete and overwrite are different. You need overwrite protection in addition to delete protection. The solution will vary depending on the storage system and the use case. (The comment in the PR is not an exhaustive description of potential solutions)
There used to be append-only, they've removed it and suggest using a credential that has no 'delete' permission. The question asked here is whether this would protect against data being overwritten instead of deleted.
- borg 1.x style “append-only” was removed, because it heavily depended on how the 1.x storage worked (it was a transactional log, always only appending PUT/DEL/COMMIT entries to segment files - except when compacting segments [then it also deleted segment files after appending their non-deleted entries to new segments])
- borg 2 storage (based on borgstore) does not work like that anymore (for good reasons), there is no “appending”. thus “—append-only” would be a misnomer.
- master branch (future borg 2 beta) has “borg serve —permissions=…” (and BORG_PERMISSIONS env var) so one can restrict permissions: “all”, “no-delete”, “write-only”, “read-only” offer more functionality than “append only” ever had. “no-delete” disallows data deleting as well as data overwriting.
- restricting permissions in a store on a server requires server/store side enforced permission control. “borg serve” implements that (using the borgstore posixfs backend), but it could be also implemented by configuring a different kind of store accordingly (like some cloud storage). it’s hard to test that with all sorts of cloud storage providers though, so implementing it in the much easier to automatically test posixfs was also a motivation to add the permissions code.
FYI for those using restic, you can use rest-server to achieve a server-side-enforced append-only setup. The purpose is to protect against ransomware and other malicious client-side operations.
For low-latency storage (like file: and maybe ssh:) it already works quite nicely, but there might be a lot to do still for high-latency storage (like cloud stuff).
I use rsync.net for borg backups. They create daily ZFS snapshots that are read-only to the user, specifically for ransomware protection.
But this was a good reminder I should probably figure out some good way to monitor my borg repo for unintended changes. Having snapshots to roll back to is only useful if a problem is detected in time.
Readit News
> The "no-delete" permission disallows deleting objects as well as overwriting existing objects.
[0]: https://github.com/borgbackup/borg/pull/8798#issuecomment-29...
Making e.g. snapshots on the backing storage was always the better approach.
https://github.com/restic/restic
https://github.com/restic/rest-server
which has to be started with --append-only. I use this systemd unit:
I also use nginx with HTTPS + HTTP authentication in front of it, with a separate username/password combination for each server. This makes rest-server completely inaccessible to the rest of the internet and you don't have to trust it to be properly protected against being hammered by malicious traffic.Been using this for about five years, it saved my bacon a few times, no problems so far.
I've been doing this on rsync.net since at least February; works great!
[1]: https://kopia.io/docs/
I had the impression that in the beginning Borg started as a fork of Restic to add missing features, but Restic was the more mature project.
Is there still anything Borg has that Restic lacks?
For me the reason to use Borg over Restic has always been that it was _much_ faster due to using a server-side daemon that could filter/compress things. The downside being you can’t use something like S3 as storage (but services like Borgbase or Hetzner Storage Boxes support Borg).
That’s probably changed with the server backend, but with the same downside.
I am very much in the market for a replacement (looking at Rustic for example).
Deleted Comment
I'm not sure what exactly you expect that would be different?
rustic currently is in beta state and misses regression tests. It is not recommended to use it for production backups, yet.
Is this what append-only achieved for Borg?
Deleted Comment
There used to be append-only, they've removed it and suggest using a credential that has no 'delete' permission. The question asked here is whether this would protect against data being overwritten instead of deleted.
TL;DR: don't panic, all is good. :-)
Longer version:
- borg 1.x style “append-only” was removed, because it heavily depended on how the 1.x storage worked (it was a transactional log, always only appending PUT/DEL/COMMIT entries to segment files - except when compacting segments [then it also deleted segment files after appending their non-deleted entries to new segments])
- borg 2 storage (based on borgstore) does not work like that anymore (for good reasons), there is no “appending”. thus “—append-only” would be a misnomer.
- master branch (future borg 2 beta) has “borg serve —permissions=…” (and BORG_PERMISSIONS env var) so one can restrict permissions: “all”, “no-delete”, “write-only”, “read-only” offer more functionality than “append only” ever had. “no-delete” disallows data deleting as well as data overwriting.
- restricting permissions in a store on a server requires server/store side enforced permission control. “borg serve” implements that (using the borgstore posixfs backend), but it could be also implemented by configuring a different kind of store accordingly (like some cloud storage). it’s hard to test that with all sorts of cloud storage providers though, so implementing it in the much easier to automatically test posixfs was also a motivation to add the permissions code.
Links:
- docs: https://github.com/borgbackup/borg/pull/8906/files
- code: https://github.com/borgbackup/borg/pull/8893/files
- code: https://github.com/borgbackup/borg/pull/8844/files
- code: https://github.com/borgbackup/borg/pull/8837/files
Please upvote, so people don't get confused.
Anyone knows when will it come out of beta?
For low-latency storage (like file: and maybe ssh:) it already works quite nicely, but there might be a lot to do still for high-latency storage (like cloud stuff).
But this was a good reminder I should probably figure out some good way to monitor my borg repo for unintended changes. Having snapshots to roll back to is only useful if a problem is detected in time.