Restic vs Borg for a small-business Linux server

You want encrypted off-site backups for one or a few Linux servers, and many comparisons you find are years old or quote benchmarks that contradict each other. This page compares both projects as they stand in September 2026.

By David Kabel · Updated 2026-09-23 · 13 min read

Release status in September 2026

restic 0.19.1 shipped on 5 July 2026. Its repository format 2, the default since 0.14.0, compresses with zstd, so any comparison saying restic cannot compress is out of date. Borg's stable line is 1.4, currently 1.4.5 from July 2026.

Borg 2 has been in beta since August 2022. The newest, 2.0.0b24, came out on 2 September 2026, and the project README says not to use it for production backups, since a new beta can mean re-creating repositories. When Borg 2 ships, you will have to plan for these changes:

• Repository format. 1.x repositories are not compatible. borg transfer --from-borg1 copies archives into a new one.
• Command syntax. borg init becomes borg repo-create, the repo::archive form goes in favour of -r, and in 2.0.0b24 even prune's --keep-last is spelled --keep, so scripts need rework.
• Storage. Borg 2 adds SFTP, rclone, and S3 or B2 repositories, which closes the gap with restic. Over SSH, new repositories use rest:// URLs served by borg serve --rest. ssh:// remains for reading 1.x repositories.
• Append-only. Borg 2 drops the mode and uses repository permissions such as no-delete instead, set with borg serve --rest --permissions or BORG_REPO_PERMISSIONS.

Restic vs Borg at a glance

The destination decides most of it

Borg 1.4 writes to a local path or over SSH to a machine running borg serve. It has no object storage backend. Without Borg on the far end, its documentation falls back to mounting a remote filesystem such as sshfs. That is fine if you have an SSH target. BorgBase hosts Borg repositories, and now restic ones too, with an append-only mode. A Hetzner Storage Box offers Borg 1.1, 1.2 and 1.4 with 1.2 as the default, so pass --remote-path=borg-1.4 to get 1.4 on the server end.

restic needs nothing installed on the destination: object storage, any SFTP server, its own REST server, or whatever rclone reaches. In our opinion that is the simplest way for a small business to keep a copy at a different provider, in a different failure domain, without running a second machine.

Append-only keeps a hacked server from deleting its history

Borg enforces it per SSH key with a forced command. The backed-up server's key runs borg serve --append-only. A separate admin machine holds a full-access key.

# ~/.ssh/authorized_keys on the Borg server
# Key held by the backed-up server: can add archives, cannot compact them away
command="borg serve --append-only --restrict-to-repository /srv/borg/web1",restrict ssh-ed25519 AAAA... web1
# Key held by a separate admin machine: full access for prune and compact
command="borg serve --restrict-to-repository /srv/borg/web1",restrict ssh-ed25519 AAAA... admin

In 1.x, append-only forbids compaction, not deletion. The append-only key can still run borg prune or borg delete. The archives vanish from the listing but the data stays, and you can roll the repository back as long as borg compact has not run since. In append-only mode, compact does nothing and reports no error. Check the archive list before you compact with the admin key, or the attacker's deletions become permanent.

restic relies on the backend. rest-server and rclone serve restic both take --append-only, and restic's documentation notes that few other backends offer such a mode. On object storage the equivalent is an access key that can write but may delete only restic's lock files, and bucket versioning keeps overwritten objects recoverable. restic's documentation recommends running forget and prune from a separate, well-secured client.

A key with no delete right at all is not enough. In our MinIO test restic could not remove its own lock, so every backup left one behind. The admin host's forget, prune and check then stopped with exit code 11 and "repository is already locked". Allowing s3:DeleteObject only under locks/ fixed that, while forget with the server's key still got Access Denied:

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": ["arn:aws:s3:::web1-backups"] },
    { "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": ["arn:aws:s3:::web1-backups/*"] },
    { "Effect": "Allow", "Action": ["s3:DeleteObject"],
      "Resource": ["arn:aws:s3:::web1-backups/locks/*"] }
  ]
}

The other common recipe, s3:DeleteObject everywhere without s3:DeleteObjectVersion on a versioned bucket, turns deletes into delete markers. On MinIO, leaving the version right out was not enough. The key still removed a version for good until we added an explicit Deny for s3:DeleteObjectVersion. Test your provider before relying on it. For Backblaze B2, see what B2 Object Lock protects with restic. This split of rights is access control and does not make backups immutable. The resticprofile guide covers its downsides and how Veeam's immutable repositories compare.

An attacker who can add snapshots can also add fake ones. Under a --keep-weekly style policy they displace your real ones, and the next routine forget deletes the good snapshots. restic's documentation recommends --keep-within for append-only repositories.

# On the admin host only. The backed-up server's key cannot delete.
export RESTIC_REPOSITORY=s3:https://s3.example.com/web1-backups
restic forget --keep-within 90d --prune
restic check --read-data-subset=5%

Neither mode protects confidentiality. restic's threat model says an attacker on an append-only host can capture the password and decrypt past and future backups, and Borg's append-only mode still allows reading.

Keys and passwords

restic always encrypts and keeps the master key in the repository, wrapped once per password. restic key add creates a second password you can store offline. Lose every password and the data is gone.

Borg fixes the mode at borg init: repokey keeps the encrypted key in the repository, keyfile keeps it in the client's home directory. You always need key and passphrase together, so export the key with borg key export and store it away from both repository and server. Keyfile mode is the risk on a server that later dies. The backups survive, but the key goes with the server.

Pruning and what it costs

restic's forget removes snapshots and prune reclaims space by deleting unused pack files and repacking partly used ones, which means downloading and re-uploading them. By default prune tolerates 5% unused data to limit that work. A backup started while prune holds its exclusive lock fails at once with exit code 11 unless you give it --retry-lock. On a versioned bucket each repack also leaves old versions behind, which is why a restic repository on Backblaze B2 keeps growing.

Since Borg 1.2, borg prune only marks data as deleted and borg compact frees it, by default in segments where at least 10% would be saved. Compact needs no key in 1.x, so it can run on the backup server.

Performance, without borrowed benchmarks

Neither project publishes a head-to-head benchmark, and third-party numbers disagree because they test different data, destinations and settings. restic's documentation says it uses all available CPU cores by default. Borg 1.x does its work in a single thread. Its 1.4 documentation does not spell that out, but in our sandbox a Borg backup never used more than one core's worth of CPU time. Borg does document that its chunks and files indexes live in RAM and grow with the repository. restic publishes no equivalent sizing guide. If speed matters, time a first backup and a full restore of your own data with each.

Wrappers: borgmatic and resticprofile

Run either tool through a wrapper, not a hand-written cron line. borgmatic 2.1.8 from September 2026 has built-in hooks to dump PostgreSQL, MySQL, MariaDB, MongoDB and SQLite, snapshot ZFS, Btrfs and LVM, and report to Healthchecks, ntfy and others. On a database server that is the strongest practical argument for Borg.

resticprofile 0.33.1 from April 2026 adds profiles, systemd or cron schedules, retention and check runs, HTTP hooks and Prometheus output. For databases you run the dump as a pre-backup command or use restic's backup --stdin-from-command, which creates no snapshot if the dump fails. The resticprofile production guide covers the setup.

Kopia and rustic, briefly

Kopia 0.23.1 from June 2026 is closer to restic. It writes to S3-compatible storage, B2, Azure, Google Cloud Storage, SFTP and WebDAV, documents S3 Object Lock for ransomware protection, and ships an official GUI. rustic 0.11.4 from August 2026 is a Rust reimplementation that reads and writes restic's repository format. Its own README calls restic the more mature project.

Picking one by situation

Wardio runs restic

We use restic, driven by resticprofile, on every server we manage. Backups go to S3-compatible object storage in a different failure domain from the server. Borg 1.4 has no object storage backend, so the destination made the choice, not speed. With an SSH target, Borg with an append-only key would be a sound option. Either way, test a restore before you rely on it.

Gotchas

• Compact through the append-only key reports success. With the backed-up server's key, borg prune and borg delete emptied the archive list and exited 0. borg compact then also exited 0 with no output, and the repository stayed the same size on disk. Only the archive list shows the damage, so read it from the admin machine before any compact. Until then, removing the segment files written after the last good entry in the repository's transactions file brought every archive back.
• Clients refuse a rolled-back repository. After that rollback, the backed-up server's next borg create failed with "Cache, or information obtained from the security directory is newer than repository" (exit 2). borg delete --cache-only alone did not fix it. Deleting ~/.config/borg/security/REPOID/manifest-timestamp as well did, as Borg's rollback notes say. Plan that step for every client of the repository.
• A lost keyfile locks you out. In a keyfile repository, removing ~/.config/borg/keys made borg list fail with "No key file for repository ... found" even with the right passphrase. borg key import of a copy made earlier with borg key export restored access at once. Export the key when you create the repository and store it off the server.
• A no-delete S3 key strands restic's locks. Every backup printed "error while unlocking: ... Access Denied" yet exited 0. The admin host's forget --prune and check then failed with exit 11, even once the locks were hours old, until it ran restic unlock. While the locks were under 30 minutes old, unlock removed nothing. A forget run with the server's key also left an exclusive lock that failed the next backup until the admin ran restic unlock --remove-all. Allow deletes under locks/ as shown above.
• Write access still allows overwrites. The locks-only key above replaced a snapshot file with an ordinary upload, and the admin's restic check reported "repository contains errors". Bucket versioning had kept the original, and copying that version back made the check pass. Keep versioning on for restic buckets, and do not let a lifecycle rule expire old versions sooner than you would notice an attack.
• Borg 2 refuses ssh:// for new repositories. 2.0.0b24 stopped with "ssh:// is no longer supported for current repositories; use rest:// instead", and borg serve --append-only is an unrecognised argument. A forced command of borg serve --rest --backend FILE:/srv/borg2/web1 --permissions no-delete with a rest://host//srv/borg2/web1 URL worked. Backups ran, and the server refused borg delete with PermissionDenied. Expect to rewrite this page's Borg 1.x key setup for Borg 2.

How this was tested. On 23 September 2026 we ran restic 0.19.1 in Debian 13.7 (trixie) containers under Docker on an Ubuntu 24.04 host, against a local repository, SFTP on OpenSSH 10.0p2, rest-server 0.14.0 with and without --append-only, rclone v1.75.1 through serve restic and the rclone backend, and MinIO RELEASE.2025-09-07T16-13-09Z as S3-compatible storage with restricted keys. Borg 1.4.5 and 2.0.0b24, installed with pip on Python 3.13.5, wrote to local repositories and over SSH through the forced commands above, and Borg 2 also to SFTP, MinIO and rclone. borgmatic 2.1.8 was installed only to list its hooks. We did not test live Backblaze B2, Azure, Google Cloud Storage, Swift or AWS S3 accounts, a Hetzner Storage Box, BorgBase, Windows, sshfs, or Kopia, rustic or resticprofile beyond their release records and source. AWS IAM may treat s3:DeleteObjectVersion differently from MinIO. We publish no speed figures.

Sources

1. restic releases, restic project on GitHub, 0.19.1 of 5 July 2026
2. restic changelog, restic project, 0.19.0 and 0.19.1 entries
3. Preparing a new repository, restic 0.19.1 documentation
4. Backing up, restic 0.19.1 documentation
5. Working with repositories, restic 0.19.1 documentation
6. Tuning parameters, restic 0.19.1 documentation
7. Removing backup snapshots, restic 0.19.1 documentation
8. Encryption and References (design and threat model), restic 0.19.1 documentation
9. rest-server README, restic project on GitHub
10. rclone serve restic, rclone documentation
11. Borg releases, BorgBackup project on GitHub, 1.4.5 and 2.0.0b24
12. Borg 2 README and Borg 2 upgrade notes and change log, BorgBackup project
13. borg serve (Borg 2 development documentation), BorgBackup project
14. Borg documentation, BorgBackup 1.4.5, including Quick start, General and Miscellaneous help (compression)
15. borg init, borg compact and borg serve, BorgBackup 1.4.5 documentation
16. Additional notes: append-only mode and rollback, BorgBackup 1.4.5 documentation
17. Storage Box: SSH, rsync and BorgBackup, Hetzner documentation
18. BorgBase, BorgBase
19. borgmatic documentation and borgmatic on PyPI, 2.1.8 of September 2026
20. resticprofile, creativeprojects on GitHub, 0.33.1 of 15 April 2026
21. Kopia features, Ransomware protection, Repository Server and releases, Kopia project
22. rustic README, rustic-rs on GitHub, and rustic-rs on crates.io, 0.11.4 of 18 August 2026