Hacker News Reader

Comment by homebrewer | Hacker News Reader

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/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.

View on HN

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.

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!

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/

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.

Which is exactly what the borg suggest in their issue.

It's a good strategy and much cheaper than having a VM that can run the server

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/

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.

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.

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?

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).

That's very interesting. Never had noticed anything like that. What kind of workloads are you seeing this with?

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.

We used borg with the very nice people at rsync.net in two startups.

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 - The restic server part is redundant

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?

Reply on news.ycombinator.com