BorgBackup vs Restic

Last reviewed Aug 24, 2026 · 643 words

These are the two serious answers to command-line backup done right, and they agree on everything important: client-side encryption, content-defined deduplication (so daily backups of a 500 GB dataset cost megabytes, not gigabytes), incremental-forever snapshots, and a decade of production trust. The differences are architectural, and the honest tiebreaker is almost boring: where are you backing up to?

Backends: restic's breadth vs Borg's depth

restic speaks to local disks, SFTP, S3 and everything S3-compatible, Backblaze B2, Azure, Google Cloud Storage, its own REST server — and, through rclone, effectively any storage that exists. If your off-site copy lives in object storage (the cheapest honest off-site there is, at B2's ~$6/TB-month), restic is the native choice. Borg's repository must live on a filesystem — local disk, or a remote reached over SSH, ideally with borg installed server-side for speed. That constraint bought depth: Borg repositories support append-only mode, a genuinely stronger ransomware posture (a compromised client can add backups but not delete history), and borg mount exposes any archive as a FUSE filesystem for browsing a backup like a folder. The hosted ecosystem reflects the split — BorgBase and rsync.net cater to Borg's SSH model, while restic pairs with any object-storage bill.

Operational texture

Both are single-purpose CLIs you drive from cron or systemd timers; neither ships a scheduler, and the wrappers fix that — borgmatic for Borg, resticprofile or plain scripts for restic — turning "backup, prune, check, notify" into one declarative config. restic is a true single static binary (Go), trivially identical everywhere; Borg is Python, distributed as packages or a bundled binary. Compression: Borg has offered zstd for years; restic added it in 0.14, closing its old gap — repository sizes now land close enough that neither wins on disk. Memory is the one resource note: restic's pruning historically wanted more RAM on very large repos, much improved in recent versions but still worth knowing on a Pi-class box. Speed differences are workload-dependent and small; both saturate a home uplink long before they saturate a CPU.

Restores are where the models feel different: Borg's mount makes "grab that one file from last Tuesday" a file-browser task; restic answers with restic mount too, plus fast restore --include paths — call it a wash today, with Borg's mount the more battle-worn.

The rule that outranks the tool choice

Either tool, misused identically, fails identically: an untested backup is a hypothesis, and prune settings that keep too little are discovered during the restore. Schedule check runs (both verify repository integrity), do a quarterly test restore, and keep the 3-2-1 structure — the tool guards against disk death and ransomware only if a copy lives off-site with credentials the client can't destroy (append-only for Borg; object-lock/immutability or separated keys for restic). What you back up matters more than how: the docker-compose patterns post covers snapshotting live databases before either tool ships them.

Decision table

What I'd do

My split, and a common one: restic to Backblaze B2 for the off-site copy (cheap, immutable buckets available), Borg to the NAS over SSH in append-only mode for the fast local restore tier. If you're picking just one: restic, purely because object storage is where most people's off-site should live in 2026. But nobody ever regretted either — regret in backups comes exclusively from the test restore you didn't do.