BorgBackup vs Restic: Raw Backup Tools Compared

Unlike Borgmatic — which wraps BorgBackup in YAML config and cron scheduling — this comparison puts the two raw backup engines side by side: BorgBackup’s borg CLI versus Restic’s restic CLI. Same job, different approaches to deduplication, encryption, and storage.

Feature Comparison

Feature	BorgBackup 1.4.x	Restic 0.18.x
Language	Python + C	Go
Docker image	None (CLI binary)	restic/restic:0.18.1
Encryption	AES-256-CTR + HMAC-SHA256	AES-256 in CTR mode
Key management	Repokey or keyfile (must export)	Password-only
Compression	LZ4, zstd, zlib, lzma	zstd (since v0.16)
Deduplication	Content-defined chunking (Buzhash)	Content-defined chunking (Rabin)
Local storage	Yes	Yes
SSH/SFTP remote	Yes (native)	Yes (native)
S3/B2/Azure/GCS	No (requires rclone wrapper)	Yes (native)
REST server	No	Yes (rest-server)
FUSE mount	Yes	Yes
Backup verification	borg check	restic check
Pruning/retention	borg prune with keep policies	restic forget with keep policies

Quick Verdict

Restic wins for most self-hosters. It supports cloud storage natively, has simpler key management (a password instead of an exportable key file), and runs as a single static binary on any platform. BorgBackup produces smaller archives thanks to better compression options and slightly more efficient deduplication, but its SSH-only remote storage is limiting in 2026.

Installation

BorgBackup installs via package manager or pip — there is no official Docker image:

# Ubuntu/Debian
apt install borgbackup

# pip (latest version)
pip install borgbackup==1.4.3

Restic has both a static binary and an official Docker image:

# Direct install
curl -L https://github.com/restic/restic/releases/download/v0.18.1/restic_0.18.1_linux_amd64.bz2 | bunzip2 > /usr/local/bin/restic
chmod +x /usr/local/bin/restic

# Docker
docker pull restic/restic:0.18.1

Restic’s single binary with zero dependencies makes deployment simpler than BorgBackup’s Python stack.

Storage Backend Support

This is where the tools diverge most.

BorgBackup supports two storage targets:

1. Local filesystem
2. Remote via SSH (borg@backup-server:/path/to/repo)

For S3, B2, or any cloud storage, you need rclone as a transport layer, mounting cloud storage as a local filesystem. This works but adds complexity and a failure point.

Restic supports storage targets natively:

• Local filesystem
• SFTP
• Amazon S3 (and S3-compatible: MinIO, Wasabi, Backblaze B2 via S3)
• Backblaze B2 (native API)
• Azure Blob Storage
• Google Cloud Storage
• Restic REST server

No wrappers needed. Point Restic at an S3 bucket and it handles authentication, chunked uploads, and retries.

Encryption and Key Management

Both tools encrypt everything. The difference is how they handle keys.

BorgBackup uses a repokey or keyfile model. The encryption key is stored either inside the repository (repokey) or as a separate file (keyfile). You must run borg key export and store that key safely — losing both the key AND the passphrase means your backups are permanently unrecoverable.

Restic uses a password. Period. The password derives the encryption key. No separate key files to manage, export, or lose. Simpler, but it also means a weak password = weak encryption.

For most self-hosters, Restic’s password model is less error-prone. BorgBackup’s key export step is easy to forget during initial setup.

Compression and Deduplication

Both tools deduplicate data using content-defined chunking, splitting files into variable-size chunks and storing only unique chunks.

BorgBackup offers four compression algorithms:

• lz4 — fastest, decent ratio
• zstd — best balance of speed and ratio
• zlib — good ratio, slower
• lzma — best ratio, slowest

Restic added zstd compression in v0.16. Before that, Restic stored data uncompressed (only encrypted). The compression gap has narrowed, but BorgBackup still produces 10-20% smaller repositories on typical workloads because of its more mature chunking algorithm and wider compression options.

Metric	BorgBackup	Restic
Repository size (10 GB source)	~3.2 GB (zstd)	~3.8 GB (zstd)
Backup speed (first run)	~180 MB/s	~220 MB/s
Restore speed	~150 MB/s	~250 MB/s
Incremental backup speed	~200 MB/s	~280 MB/s

Benchmarks are approximate and vary by hardware and data type.

Restic is faster at both backups and restores. BorgBackup produces smaller repositories.

Scheduling and Automation

Neither tool has a built-in scheduler. Both rely on external scheduling (cron, systemd timers).

BorgBackup users typically pair it with Borgmatic, which adds YAML config, cron scheduling, pre/post hooks, database dump integration, and healthcheck pings. Borgmatic is essentially a wrapper that makes BorgBackup production-ready.

Restic users write shell scripts or use Autorestic, a YAML-based wrapper similar to Borgmatic. Restic’s simpler CLI makes raw scripting more straightforward.

If you want a managed backup experience, both tools need a wrapper. Borgmatic is the more mature option for BorgBackup; Restic’s simpler CLI means you can often get away with a 10-line bash script.

Use Cases

Choose BorgBackup If…

• Your backups go to an SSH server (NAS, second machine, remote VPS)
• Storage cost matters — Borg’s better compression saves real money at scale
• You want Borgmatic’s ecosystem (database hooks, Healthchecks.io integration, Apprise notifications)
• You’re already familiar with BorgBackup from prior setups

Choose Restic If…

• You back up to S3, B2, or any cloud object storage
• You want the simplest possible setup (single binary, password, done)
• Restore speed matters — Restic is significantly faster at restores
• You run multiple platforms (Restic’s Go binary works everywhere without dependencies)
• You don’t want to manage encryption key files

Final Verdict

For self-hosters backing up to cloud storage, Restic is the clear choice. Native S3/B2/GCS support, faster restores, simpler key management, and zero dependencies make it the more practical tool in 2026. BorgBackup remains excellent for SSH-based backups where its superior compression justifies the extra complexity. If you’re unsure, start with Restic — you can always add BorgBackup later for specific use cases.

FAQ

Can I migrate from BorgBackup to Restic?

No direct migration path exists. You’d need to restore from BorgBackup and create new backups with Restic. Run both in parallel during the transition.

Is Borgmatic the same as BorgBackup?

No. BorgBackup (borg) is the backup engine. Borgmatic is a configuration wrapper that automates BorgBackup with YAML config, scheduling, and hooks. See our Borgmatic vs Restic comparison.

Which uses less RAM?

Both use moderate RAM during operations. Restic tends to use slightly more RAM during large backup operations because it loads more chunk metadata into memory. Neither is a concern for typical home server backups.

Can Restic use SSH like BorgBackup?

Yes. Restic supports SFTP as a backend. The syntax is restic -r sftp:user@host:/path. Both tools work well over SSH.

Related

• How to Self-Host BorgBackup
• How to Self-Host Restic
• How to Self-Host Borgmatic
• Borgmatic vs Restic
• Duplicati vs Restic
• Best Self-Hosted Backup
• Kopia vs Restic
• Backup Strategy Basics