When your VPS crashes at 3 AM or a bad update bricks your production server, the only thing standing between you and disaster is your backup strategy. BorgBackup vs. Restic is one of the most debated comparisons in the sysadmin community, and choosing the right tool can mean the difference between a 10-minute recovery and a multi-day catastrophe. Both are open-source, deduplicating backup programs trusted by thousands of DevOps engineers, but they take fundamentally different approaches to data protection, encryption, and storage.
This guide cuts through the marketing and gives you a real, hands-on comparison of BorgBackup and Restic for VPS environments in 2026. You'll learn how each tool handles deduplication, encryption, performance, and restore scenarios so you can pick the one that actually saves your bacon when things go sideways.
BorgBackup and Restic at a Glance
Both BorgBackup (often called just "Borg") and Restic are modern, incremental backup tools that support client-side encryption, compression, and deduplication. They are designed for the realities of backing up Linux servers where bandwidth, disk space, and security all matter.
- BorgBackup is a deduplicating archiver written in Python with C extensions. It runs locally and connects to remote repositories over SSH, making it ideal for VPS-to-VPS or VPS-to-dedicated-server setups.
- Restic is a security-focused backup program written in Go. It is a single static binary that supports a wide range of backends natively, including S3, B2, SFTP, and even REST servers.
Both projects are mature, actively maintained, and have stood the test of time. The difference lies in their architecture and philosophy, which directly affects how they perform on a VPS.
Deduplication and Storage Efficiency
Storage efficiency is often the first metric VPS operators care about, especially when paying for offsite storage by the gigabyte. Both tools deduplicate data, but they use very different methods.
How Borg Handles Deduplication
Borg uses a fixed-size chunking approach combined with a chunk ID store. It splits files into variable-size chunks (using a content-defined chunking algorithm) and stores each unique chunk only once. Borg's segment files group chunks together for efficient I/O, and it maintains a local cache to speed up subsequent backups.
The result is excellent deduplication ratios, especially for workloads with lots of repeated data, such as databases, mail servers, or application logs. On a typical VPS, you can expect Borg to reduce backup size by 60–80% on the first full backup, with even smaller incrementals thereafter.
How Restic Handles Deduplication
Restic uses a simpler approach based on the structure of the source data. It reads files in fixed-size blobs (typically 1–2 MB), hashes them, and stores only new blobs. This approach is predictable and easy to reason about, but it can be less efficient when files change frequently in small ways.
However, Restic's pack files bundle multiple blobs together, reducing the number of S3 PUT requests and improving performance on object storage backends. If you pay per request on S3 or B2, this can translate into real cost savings.
Encryption and Security
Both Borg and Restic treat security as a first-class concern. Data is encrypted client-side before it ever leaves your VPS, meaning the storage provider never sees plaintext data.
- Borg uses AES-256-CTR with HMAC-SHA256 for authenticated encryption. It supports several modes: repokey (key stored in repository config), keyfile (key stored separately), and others. The repository format is well-audited and considered cryptographically sound.
- Restic uses AES-256 in counter mode with Poly1305 for authenticated encryption (chacha20-poly1305 is also available). Keys are derived from a password using scrypt, and the entire repository is authenticated against tampering.
From a security standpoint, both tools are excellent. Restic has a slight edge in its default key derivation and modern crypto choices, while Borg's key management options are more flexible for teams that need granular access control.
Backend Support and Flexibility
Where you store your backups matters just as much as how you back them up. A VPS backup tool that locks you into a single storage provider is a liability in the long run.
Borg Backup Destinations
Borg was originally designed for local and SSH-accessible remote storage. It works exceptionally well with:
- Local disks and mounted filesystems
- Remote servers over SSH
- Any service that presents as a local filesystem (with some caveats for S3 mounts via s3fs or similar)
To use Borg with S3, B2, or other object storage, you typically need to mount the bucket as a filesystem, which adds complexity and a potential failure point.
Restic Native Backends
Restic was built with cloud-native storage in mind. It has first-class support for:
- S3 (AWS S3, MinIO, Wasabi, Backblaze B2 via S3 API)
- Backblaze B2 (native API)
- Azure Blob Storage
- Google Cloud Storage
- SFTP for VPS-to-VPS backups
- Local filesystem
- REST server (restic's own server mode)
If your backup target is object storage, Restic is significantly easier to set up and operate. There is no need for FUSE mounts or filesystem hacks.
Performance on a VPS
Performance is where Borg has historically dominated. Its local cache and C-optimized chunking make it fast, especially for large, redundant datasets. In benchmark tests on typical VPS workloads, Borg often runs 2–3x faster than Restic for the initial backup.
However, Restic's performance has improved dramatically over the years. The Go implementation is highly concurrent, and the --pack-size and worker flags allow tuning for specific environments. On a modern VPS with NVMe storage and fast networking, the performance gap is much smaller than it used to be.
Restore Speed
Restore speed is critical when you are recovering from a disaster. Borg's design allows very fast restores, especially when the local cache is populated. Restic's restore performance is generally good, but can be slower when reading many small files from S3 over high latency links.
For VPS users, both tools can typically restore a full system in minutes, but Borg has a noticeable edge on local or SSH-connected repositories.
Pruning and Retention
Long-term backup strategies require pruning old backups to control storage costs. Both tools support retention policies, but they differ in flexibility.
Borg Prune
Borg's borg prune command supports second, minute, hourly, daily, weekly, monthly, and yearly retention. It is powerful and well-documented, allowing you to build sophisticated retention schemes. However, the syntax can be intimidating for newcomers.
Restic Forget and Prune
Restic separates the logical deletion (restic forget) from the physical cleanup (restic prune). This two-step approach gives you more control and is easier to understand. The --keep-within and --keep-daily/weekly/monthly/yearly options are intuitive and well-documented.
For most VPS users, Restic's retention model is easier to learn and reason about, while Borg's is more flexible for complex compliance scenarios.
Operational Considerations
Day-to-day operational concerns often determine which tool survives a year of production use.
Check and Repair
- Borg offers borg check and borg repair for verifying repository integrity. The repair command can fix many common issues caused by interrupted backups or disk errors.
- Restic offers restic check that verifies the integrity of the repository. It does not have a built-in repair mode, but its structure makes data corruption easier to detect early.
Both tools take data integrity seriously, but Borg's repair capability is a real advantage for long-term archival where bit rot is a concern.
Mounting Backups as Filesystem
Both Borg and Restic support mounting backups as a read-only FUSE filesystem, allowing you to browse and copy individual files without a full restore. This is invaluable for quickly recovering a single file or configuration.
- Borg's borg mount is mature and widely used in production.
- Restic's restic mount works well but can be slower when browsing large repositories over S3.
Which One Should You Choose for Your VPS?
The honest answer is that both tools are excellent, and the right choice depends on your specific situation.
Choose BorgBackup if:
- You back up to a remote server over SSH or a local disk
- Maximum backup and restore speed is critical
- You need fine-grained retention policies with multiple daily, weekly, and monthly tiers
- You want the ability to repair repositories after corruption
- Your dataset is large and has high redundancy (databases, mail spools, etc.)
Choose Restic if:
- You back up directly to S3, B2, Azure, or GCS without FUSE mounts
- You want a single static binary with zero dependencies
- Ease of setup and simple retention rules matter more than raw speed
- You run on multiple platforms or want the same tool across Linux, macOS, and Windows
- You value Restic's clear separation between forget and prune operations
Real-World VPS Backup Strategy in 2026
Regardless of which tool you pick, a solid VPS backup strategy in 2026 should follow a few proven principles:
- Follow the 3-2-1 rule — keep at least 3 copies of your data, on 2 different media, with 1 copy offsite.
- Test restores regularly — an untested backup is not a backup. Schedule monthly restore drills to a sandbox VPS.
- Encrypt everything — both Borg and Restic do this by default, but never disable it.
- Monitor backup jobs — use healthchecks.io or a similar service to alert you when a backup fails or is missed.
- Document the restore procedure — when disaster strikes, you do not want to read documentation for the first time.
For a typical small-to-medium VPS in 2026, my recommendation is straightforward: use Restic if you are backing up to cloud object storage, and use Borg if you are backing up to a remote server or local disk. Both are battle-tested, both are reliable, and both will save your bacon when you need them.
Conclusion
Choosing between BorgBackup and Restic for your VPS in 2026 comes down to your storage target and operational preferences. BorgBackup offers superior speed, powerful retention policies, and the ability to repair damaged repositories, making it the go-to choice for SSH-based and local backups. Restic shines with native cloud backend support, a single static binary, and a simpler operational model that is perfect for S3, B2, and other object storage services. Both tools are open-source, actively maintained, and cryptographically sound. Whichever you choose, pair it with a tested restore procedure and proper monitoring to ensure that when disaster strikes, your backups actually save your bacon.
FAQ
Is BorgBackup faster than Restic for VPS backups?
Yes, in most benchmarks BorgBackup is faster than Restic, especially for the initial full backup. Borg's C-optimized chunking and local cache give it a significant performance advantage on local and SSH-connected storage. On object storage backends, the gap is smaller because network latency dominates.
Can Restic back up to S3 or Backblaze B2 directly?
Yes, Restic has native support for S3-compatible storage including AWS S3, Backblaze B2, Wasabi, and MinIO, as well as the native B2 API. You do not need to mount the bucket as a filesystem. You just provide credentials and the bucket name, and Restic handles the rest.
Does BorgBackup support cloud storage like S3?
BorgBackup does not natively support S3 or other object storage APIs. To use Borg with S3, you typically need to mount the bucket using a FUSE filesystem such as s3fs or goofys. This works but adds complexity and an extra failure point compared to Restic's native backend support.
Which tool has better encryption, Borg or Restic?
Both BorgBackup and Restic use strong, authenticated encryption. Borg uses AES-256-CTR with HMAC-SHA256, while Restic uses AES-256 with Poly1305 (or ChaCha20-Poly1305) and scrypt for key derivation. Both are considered cryptographically sound, and the differences are mostly academic. Choose based on operational needs rather than encryption strength.
Can I use Borg and Restic together on the same VPS?
Yes, you can use both tools on the same VPS for different purposes. For example, use Borg for fast local or SSH backups and Restic for offsite cloud backups. Many sysadmins run both to take advantage of Borg's speed for local restores and Restic's flexibility for cloud storage. Just make sure their schedules do not overlap in a way that causes excessive I/O on the VPS.
How do Borg and Restic handle repository corruption?
BorgBackup has a built-in borg repair command that can fix many types of repository corruption, including damaged segment files and manifest issues. Restic has a restic check command for verification but does not include a repair mode. Both tools detect corruption early, but Borg has a clear edge when you need to recover from a damaged repository.
Updated: 2026-06-23 | Subject to change.