restic vs BorgBackup: which backup tool should you use?

restic and BorgBackup are established open-source backup tools for Linux and other supported platforms. Both offer self-contained command-line releases, client-side authenticated encryption, content-defined deduplication, snapshot retention, repository checks, and selective restore. Their overlapping feature lists can hide a more consequential difference: the storage and trust model each tool expects.

restic supports several object-storage services and S3-compatible endpoints, as well as SFTP, REST-server, and local repositories. Object storage does not need a restic process on the storage side. That is useful when the desired recovery boundary is a bucket rather than another managed server.

Borg's usual remote model is a Borg process reached over SSH. Native object-storage repositories are not part of that model, so using a bucket requires an additional bridge, service, or different repository design. That extra dependency should be evaluated as part of recovery rather than treated as a Borg feature.

Both tools deduplicate and compress data, but there is no honest universal winner for speed or repository size. Results change with file sizes, churn, compression settings, client CPU and memory, latency, cache state, and the storage backend. A benchmark that ignores restore and maintenance work is incomplete.

Test a representative data set against the actual target. Measure the first backup, a normal incremental, repository maintenance, and a cold restore. Also record temporary disk use and memory on the smallest server you operate. Those numbers are more useful than a benchmark from another workload.

Borg can configure a remote repository in append-only mode so a client is not permitted to permanently remove previously committed backup data. Borg's documentation also makes the remaining boundary clear: an administrator of the repository server can still delete it, so server access and independent copies still matter.

A restic client that holds ordinary read-write repository credentials can apply retention and remove data. Object-storage versioning or protected copies can add recovery options, but retention and immutable-storage rules must be designed together. Whichever engine you choose, document which identity can delete every copy.

Both restore individual files or whole archives or snapshots, and both can mount repository contents for browsing on supported systems. Recovery still depends on the client binary, repository location, access credentials, encryption material, and enough target capacity.

For restic object storage, no backup daemon from the lost source host is required. For remote Borg, the recovery plan needs a reachable Borg repository service over SSH or direct access to a recovered repository copy. Test recovery from a clean environment so hidden SSH configuration, cache files, or existing sessions do not mask a missing dependency.

Both are excellent engines. The choice usually comes down to where the backups live.

Both are backup engines rather than complete fleet operations systems. They are commonly paired with cron, systemd timers, wrappers, or separate orchestration. Cross-server ownership, stale-run detection, alert routing, database-aware preparation, and restore evidence remain operating responsibilities.

Rested provides that operating layer around restic: schedules, database-aware sources, run history, failure visibility, and guided recovery across enrolled servers while the user controls the storage and recovery key. Teams that prefer Borg need to assemble or choose an equivalent layer for their own environment.