Borg vs Restic: which backup tool fits you?

What both tools actually do

Borg and Restic both split files into content-defined chunks, so unchanged data is never re-uploaded even across different files or later snapshots — that's where the deduplication comes from. Every chunk is encrypted client-side before it leaves your machine, so the remote never sees plaintext or holds the key. Snapshots reference chunks rather than copying them, and a prune or forget operation removes chunks no longer referenced by any snapshot you've chosen to keep.

Both trace back to the same lineage: Borg forked from Attic in 2015 to fix its performance and reliability issues; Restic was written from scratch and released the following year with object storage as a design goal from day one, not an add-on. That origin still shows — it's why Borg's SSH path feels the most polished, and why Restic's backend list keeps growing.

Where they differ

Both projects are actively maintained, GPL/BSD-licensed, and free to use. Neither vendor-locks you: repository formats are documented and both have independent re-implementations.

Where each one wins

Append-only, for both

Both tools support write-once repositories against ransomware, just through different mechanisms. Borg needs borg serve --append-only running behind a restricted SSH key that can add snapshots but never delete them — pruning happens with a separate, more privileged key that stays off the production host. Restic, against an S3-compatible bucket, relies on the bucket's Object Lock or retention-mode setting instead of a client flag — the immutability lives in the storage layer, not in anything the client can be tricked into bypassing.

Which should a beginner pick

If the only thing you have right now is SSH access to a single remote, start with Borg and its Vorta GUI — you'll have a working, well-compressed backup running in about twenty minutes. If you already use, or plan to add, S3-compatible object storage — including most managed vault services — start with Restic: the same command works whether the bucket sits at a vault, at a hyperscaler, or on a machine at a friend's house. Either way, turn on append-only from day one. Retrofitting it later means re-keying every client that writes to the repository, which is a worse afternoon than picking the right tool up front.

Both, supported here

backups.hosting doesn't pick a side. Borg repositories run append-only over SSH, with a separate prune key that never leaves our side of the connection. Restic targets our S3-compatible buckets directly, with Object Lock enforcing the same immutability window at the storage layer instead of a client flag. Pick whichever matches the access you already have — or run both against separate vaults. Retention windows of 14, 30, or 90 days either way, with a real monthly restore test included, not a checkbox.

Restoring a single file, either way

Day-to-day, most restores aren't "rebuild the server" — they're "someone deleted one file three days ago." Both tools make that a two-command job: list the snapshot to confirm the file is actually in it, then extract just that path.

Neither command touches anything else in the repository, and neither requires downtime on the host you're restoring to — a genuine advantage of chunk-addressed backups over a plain tarball, which has to be unpacked in full to reach one file inside it.

Frequently asked