remote-backups.comremote-backups.com
Contact illustration
Sign In
Don't have an account ?Sign Up

Borg vs Restic: Which Backup Tool Fits Your Linux Server?

  • February 15, 2026
  • 11 min read
Table of Contents
Bennet Gallein
Bennet Gallein
remote-backups.com operator

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%
Ranges based on typical mixed-file workloads on modern hardware.

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:

bash
# 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/repo
Borg workflow

Restic:

bash
# 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:/repo
Restic workflow

Both 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

Borg is generally faster, achieving 180-220 MB/s on local backups compared to Restic's 120-160 MB/s. Borg also uses less memory (50-150 MB vs 100-200 MB). The difference is most noticeable on large datasets or memory-constrained systems.

No. Restic has no built-in compression. It relies entirely on deduplication to reduce storage usage. Borg supports LZ4, zlib, LZMA, and zstd compression, which can reduce storage by an additional 30-50% beyond deduplication alone.

Not natively. Borg supports local filesystems and SSH/SFTP. You can use rclone mount as a workaround for cloud storage, but it adds complexity. Restic has native support for S3, Backblaze B2, Azure Blob, and Google Cloud Storage.

No. Borg uses exclusive locking, so each machine needs its own repository. Restic supports shared repositories where multiple machines can back up to the same repo with cross-system deduplication.

Yes. Both tools use AES-256 client-side encryption. Data is encrypted before it leaves your machine, so the backup server never sees plaintext. Neither tool stores your passphrase. Losing it means losing access to your backups.

Only through WSL (Windows Subsystem for Linux). Restic runs natively on Windows, macOS, and Linux, making it the better choice for mixed-OS environments.

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.