Hacker News new | past | comments | ask | show | jobs | submit login

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.






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?


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.


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


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 [email protected] 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/

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

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.

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.

Use rustic instead of restic!

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.


Care to explain more?



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: