If you're comparing Borg vs Restic for your Linux backup strategy, you're looking at the two most popular open-source deduplicating backup tools available. Both encrypt your data, both deduplicate it, and both get it safely off the machine it lives on. But they approach the problem with different design philosophies.
Online discussions tend to devolve into tribal loyalty. This article skips that. We'll compare both backup tools on architecture, performance, features, and real-world fit so you can pick the one that actually matches your use case.
Key Takeaways
- Borg is faster (180-220 MB/s vs 120-160 MB/s) and uses less memory — best for large datasets
- Restic has native S3/cloud backends and Windows support — best for mixed-OS, cloud-first setups
- Borg's compression (zstd) saves 30-50% additional storage beyond deduplication; Restic has none
- Borg's FUSE mounting lets you browse backups like a filesystem — Restic requires explicit restore commands
- Both use AES-256 client-side encryption with no recovery mechanism — store your passphrase safely
How Borg and Restic Work: Architecture Overview
Both tools use content-defined chunking to break your files into pieces, hash them, and only store chunks they haven't seen before. That's deduplication, and it's why incremental backups with either tool are fast and space-efficient.
Borg follows a client-server model. You run borg on the machine you're backing up, and it talks to a repository over SSH (or locally). Each repository is tied to a single client by default, since Borg takes an exclusive lock during operations. It comes with built-in FUSE support, so you can mount any backup as a filesystem and browse it like a regular directory.
Restic takes a multi-backend approach. It speaks natively to local storage, SFTP, S3, Backblaze B2, Azure Blob, and Google Cloud Storage. Multiple machines can write to the same repository, and Restic handles concurrent access. There's no FUSE mounting, so restores go through the restic restore command.
Neither tool requires a dedicated backup server. Both work over plain SSH/SFTP, meaning any Linux box with SSH access (or a service like remote-backups.com) can be your backup target.
Performance Comparison
Raw numbers depend heavily on hardware, network, and data type. These ranges represent typical results on modern hardware with mixed file workloads (documents, configs, small binaries):
Performance Benchmarks
| Metric | Borg | Restic |
|---|---|---|
Backup speed (local) | 180-220 MB/s | 120-160 MB/s |
Restore speed | 160-200 MB/s | 140-180 MB/s |
Memory usage | 50-150 MB | 100-200 MB |
Deduplication ratio | 70-85% | 60-80% |
Borg wins on raw throughput and memory efficiency. Part of that comes from its tighter C/Cython codebase. Restic (written in Go) is competitive but uses more memory and pushes fewer bytes per second.
Does this matter? For a homelab with a few hundred gigabytes, probably not. For multi-terabyte datasets backing up over the internet, the speed difference compounds. On memory-constrained systems (small VPS, Raspberry Pi), Borg's lighter footprint gives it a clear edge.
Storage Backend Support
This is where the tools diverge most.
Borg supports:
- Local filesystem
- SSH/SFTP (native)
- Cloud storage via rclone mount (workaround, not native)
Restic supports:
- Local filesystem
- SSH/SFTP
- Amazon S3 (and S3-compatible like MinIO)
- Backblaze B2
- Azure Blob Storage
- Google Cloud Storage
- REST server
If your backup target is an S3 bucket or cloud object store, Restic connects directly without extra tooling. Borg can get there via rclone mount, but it's an additional layer that adds complexity and potential failure points.
For SSH/SFTP-based backup targets, both tools connect directly and perform equally well.
SFTP and SSH Targets
If your backup target is SFTP or SSH-based (like remote-backups.com), both tools connect directly. No cloud adapter or middleware needed.
Feature Comparison
| Feature | Borg | Restic |
|---|---|---|
Compression | LZ4, zlib, LZMA, zstd | |
FUSE mounting | ||
Windows support | WSL only | Full native |
Multi-system repos | ||
Pruning speed | Fast | Slow on large repos |
Append-only mode |
A few of these deserve more context.
Compression is a significant differentiator. Borg supports four compression algorithms: LZ4 (fast, low ratio), zlib (balanced), LZMA (slow, high ratio), and zstd (modern, recommended for most workloads). Restic has no compression at all. It relies entirely on deduplication to save space. For compressible data like logs, text files, and database dumps, Borg's compression can cut storage usage by 40-60% on top of deduplication. That directly translates to lower storage costs.
FUSE mounting is Borg's killer feature for restores. Run borg mount /repo /mnt and you get a browsable filesystem of every backup. Need one config file from last Tuesday? Navigate to it and copy it out. With Restic, you either restore the entire snapshot or use restic dump to extract specific files by path. Functional, but less intuitive.
Multi-system shared repos give Restic an advantage in environments where multiple machines back up to the same storage. Borg's exclusive locking means each machine needs its own repository, which reduces cross-system deduplication. Restic handles concurrent writes to a shared repository, so identical files across your fleet are deduplicated once.
Windows support matters if you have a mixed environment. Restic runs natively on Windows, macOS, and Linux. Borg is Linux/Unix-focused, and Windows support exists only through WSL.
Encryption and Security
Both tools encrypt your data before it leaves the machine:
- AES-256 encryption with authenticated encryption modes
- Client-side encryption, so your backup target never sees plaintext data
- No account or cloud service required. Everything is controlled by your passphrase
- Both have been independently audited and are considered production-ready
Neither tool stores your passphrase. There is no "forgot password" flow, no recovery mechanism, no backdoor.
Passphrase Management
Store your encryption passphrase securely and separately from your backups. Both tools make recovery impossible without it. This is a feature, not a bug. Consider a password manager or a sealed envelope in a safe.
When to Choose Borg
Borg is the stronger choice when:
- Your environment is Linux/Unix only
- Your backup target is SSH or SFTP-based
- You want compression to reduce storage costs
- FUSE mounting matters for quick, intuitive restores
- You're running on memory-constrained systems
- You have large datasets where throughput matters
Example scenario: A Proxmox homelab backing up to remote-backups.com via Borg. Fast incremental backups, zstd compression keeping storage usage low, and FUSE mounting for grabbing individual files when something goes wrong. You can estimate your initial backup time with our seed calculator.
When to Choose Restic
Restic is the stronger choice when:
- You have a mixed OS environment (Windows, macOS, Linux)
- You need native S3 or cloud storage integration
- Multiple machines should share one backup repository
- You prefer simpler scripting with fewer flags
- Your infrastructure is cloud-first with object storage already in place
Example scenario: A dev team with Windows workstations and Linux servers, all backing up to a shared S3-compatible bucket. One repository, cross-system deduplication, no additional tooling required.
Practical Setup Comparison
Both tools follow the same pattern: initialize a repository, then create backups. Here's what that looks like in practice.
Borg:
# Initialize repository
borg init --encryption=repokey ssh://user@backup-server/repo
# Create a backup (archive named with timestamp)
borg create ssh://user@backup-server/repo::backup-{now} /data
# Browse a backup via FUSE
borg mount ssh://user@backup-server/repo /mnt
# Prune old backups
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 ssh://user@backup-server/repoRestic:
# Initialize repository
restic init -r sftp:user@backup-server:/repo
# Create a backup (snapshot with auto-generated ID)
restic backup /data -r sftp:user@backup-server:/repo
# Restore a snapshot
restic restore latest -r sftp:user@backup-server:/repo --target /restore
# Prune old snapshots
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune -r sftp:user@backup-server:/repoBoth are straightforward. Borg uses named archives (you pick the name), Restic uses snapshot IDs (auto-generated hashes). Both support exclude patterns, --one-file-system, dry runs, and progress output.
One operational difference: Restic's forget and prune are separate concepts (though --prune combines them). Borg's prune handles both in one step and tends to run faster, especially on large repositories.
Our Take: Why We Support Borg
At remote-backups.com, we offer native Borg repositories as our primary product. Here's why:
- Compression reduces your storage usage, and your bill. Zstd compression on typical server data saves 30-50% compared to dedup alone.
- FUSE mounting makes restores intuitive. When something breaks at 2 AM, you want to browse, not reconstruct command flags.
- Performance matters for large backups over the internet. Borg's speed advantage means shorter backup windows and less network congestion.
- Memory efficiency means Borg runs comfortably on the same box as your workloads.
That said, we also offer SFTP storage, so if Restic fits your workflow better, it works with our infrastructure too. No lock-in.
Frequently Asked Questions
Conclusion
There's no universal winner in the Borg vs Restic comparison. Both tools are mature, well-maintained, and trusted in production by thousands of users.
Choose Borg if you're Linux-focused, want compression and FUSE mounting, and care about raw performance. Choose Restic if you need native cloud backends, Windows support, or shared multi-system repositories.
If you're still unsure, test both against your actual data. A trial backup to a test repository takes 30 minutes and tells you more than any benchmark. And if you're looking for off-site storage to back up to, start with a free trial and see how it fits.
For more on backup strategy, check out our guide on the 3-2-1 backup rule and how to monitor your backups.



