7 ms·

For anyone looking to migrate off borg because of this, append-only is available in restic, but only with the rest-server backend: https://github.com/restic/re

For anyone looking to migrate off borg because of this, append-only is available in restic, but only with the rest-server backend: https://github.com/restic/restic https://github.com/restic/restic https://github.com/restic/rest-server https://github.com/restic/rest-server which has to be started with --append-only. I use this systemd unit: [Unit] After=network-online.target [Install] WantedBy=multi-user.target [Service] ExecStart=/usr/local/bin/rest-server --path /mnt/backups --append-only --private-repos WorkingDirectory=/mnt/backups User=restic Restart=on-failure ProtectSystem=strict ReadWritePaths=/mnt/backups 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.

champtar 1y ago
If you want to use some object storage instead of local disk, rclone can be a restic server: https://rclone.org/commands/rclone_serve_restic/ https://rclone.org/commands/rclone_serve_restic/
rsync 1y ago
You can achieve append-only without exposing a rest server provided that 'rclone' can be called on the remote end: rclone serve restic --stdio You add something like this to ~/.ssh/authorized_keys: restrict,command="rclone serve restic --stdio --append-only backups/my-restic-repo" ssh-rsa ... ... and then run a command like this: ssh user@rsync.net rclone serve restic --stdio ... 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.
- zacwest 1y ago
  You then use `restic` telling it to use rclone like... restic ... --option=rclone.program="ssh -i <identity> user@host" --repo=rclone: which has it use the rclone backend over ssh. I've been doing this on rsync.net since at least February; works great!
snickerdoodle12 1y ago
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.
- fl0id 1y ago
  Which is exactly what the borg suggest in their issue.
  - snickerdoodle12 1y ago
    It's a good strategy and much cheaper than having a VM that can run the server
cvalka 1y ago
[flagged]
- Too 1y ago
  Care to explain more?
- champtar 1y ago
  https://github.com/rustic-rs/rustic?tab=readme-ov-file#stability https://github.com/rustic-rs/rustic?tab=readme-ov-file#stabi... rustic currently is in beta state and misses regression tests. It is not recommended to use it for production backups, yet.
- shelled 1y ago
  Here's a very actively developed GUI https://github.com/garethgeorge/backrest 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.
deleted 1y ago
[deleted]
twhb 1y ago
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#security-considerations-in-append-only-mode 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.
- unsnap_biceps 1y ago
  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?
mike-cardwell 1y ago
You say "only with the restic backend" but you can do it with a simple Nginx backend too https://www.grepular.com/Nginx_Restic_Backend https://www.grepular.com/Nginx_Restic_Backend - The restic server part is redundant
JeremyNT 1y ago
I'm curious if there is any reason to use Borg these days. 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?
- remram 1y ago
  My number one problem with Restic is the memory usage. On some of my workloads, Restic consumes dozens of gigabytes of memory during backup. I am very much in the market for a replacement (looking at Rustic for example).
  - nadir_ishiguro 1y ago
    That's very interesting. Never had noticed anything like that. What kind of workloads are you seeing this with?
- lutoma 1y ago
  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.
  - KingOfCoders 1y ago
    We used borg with the very nice people at rsync.net in two startups.
nine_k 1y ago
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. [1]: https://kopia.io/docs/ https://kopia.io/docs/
- shelled 1y ago
  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.
  - nine_k 1y ago
    Having dug into Kopia config today, I realized that much of this is controlled by a policy, or several policies. The fun part is that the policies live in the repository, there's no obvious way to have it as local files. It makes sense, I suppose, if you have a bunch of similar machines (e.g. workstations) that must follow the same policy, and put their backups to the same repository.

champtar 1y ago

If you want to use some object storage instead of local disk, rclone can be a restic server: https://rclone.org/commands/rclone_serve_restic/ https://rclone.org/commands/rclone_serve_restic/

rsync 1y ago

You can achieve append-only without exposing a rest server provided that 'rclone' can be called on the remote end: rclone serve restic --stdio You add something like this to ~/.ssh/authorized_keys: restrict,command="rclone serve restic --stdio --append-only backups/my-restic-repo" ssh-rsa ... ... and then run a command like this: ssh user@rsync.net rclone serve restic --stdio ... 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.

zacwest 1y ago
You then use `restic` telling it to use rclone like... restic ... --option=rclone.program="ssh -i <identity> user@host" --repo=rclone: which has it use the rclone backend over ssh. I've been doing this on rsync.net since at least February; works great!

snickerdoodle12 1y ago

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.

fl0id 1y ago
Which is exactly what the borg suggest in their issue.
- snickerdoodle12 1y ago
  It's a good strategy and much cheaper than having a VM that can run the server

cvalka 1y ago

[flagged]

Too 1y ago
Care to explain more?
champtar 1y ago
https://github.com/rustic-rs/rustic?tab=readme-ov-file#stability https://github.com/rustic-rs/rustic?tab=readme-ov-file#stabi... rustic currently is in beta state and misses regression tests. It is not recommended to use it for production backups, yet.
shelled 1y ago
Here's a very actively developed GUI https://github.com/garethgeorge/backrest 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.

deleted 1y ago

[deleted]

twhb 1y ago

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#security-considerations-in-append-only-mode 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.

unsnap_biceps 1y ago
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?

mike-cardwell 1y ago

You say "only with the restic backend" but you can do it with a simple Nginx backend too https://www.grepular.com/Nginx_Restic_Backend https://www.grepular.com/Nginx_Restic_Backend - The restic server part is redundant

JeremyNT 1y ago

I'm curious if there is any reason to use Borg these days. 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?

remram 1y ago
My number one problem with Restic is the memory usage. On some of my workloads, Restic consumes dozens of gigabytes of memory during backup. I am very much in the market for a replacement (looking at Rustic for example).
- nadir_ishiguro 1y ago
  That's very interesting. Never had noticed anything like that. What kind of workloads are you seeing this with?
lutoma 1y ago
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.
- KingOfCoders 1y ago
  We used borg with the very nice people at rsync.net in two startups.

nine_k 1y ago

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. [1]: https://kopia.io/docs/ https://kopia.io/docs/

shelled 1y ago
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.
- nine_k 1y ago
  Having dug into Kopia config today, I realized that much of this is controlled by a policy, or several policies. The fun part is that the policies live in the repository, there's no obvious way to have it as local files. It makes sense, I suppose, if you have a bunch of similar machines (e.g. workstations) that must follow the same policy, and put their backups to the same repository.