When managing complex IT infrastructure, backup strategy is one of the most critical decisions. It’s not just about saving data; it’s about ensuring operational continuity in case of disaster. In a data center environment, with hundreds of VMs, databases, and configurations, choosing the right tool can make the difference between a quick recovery and a prolonged outage.
I decided to put two of the most popular open-source backup tools to the test: Restic and BorgBackup. The goal was to understand their performance on a significant dataset, simulating a real-world scenario. I prepared an environment with approximately 2TB of heterogeneous data, including virtual disks, database backups, and configuration files, to replicate the challenges of enterprise backups. This test focused not only on initial backup speed but also on deduplication efficiency, incremental backup speed, and, crucially, restore reliability. The results highlighted specific strengths and weaknesses for each, which can guide selection based on actual infrastructure needs. Read also: Proxmox Replication: Slow WAN, Low RPO
Tested on: Debian 12 · Restic 0.16.2 · BorgBackup 1.2.7 · August 2026
Prerequisites / Test Environment
For the test, I used a dedicated server with the following specifications:
- Operating System: Debian 12 (Bookworm)
- CPU: Intel Xeon E3-1270 v6 (4 Cores, 8 Threads)
- RAM: 64GB DDR4
- Storage: 2x 4TB NVMe in RAID1 (for source data) and 1x 8TB HDD SATA (for the backup repository)
- Dataset: 2TB of mixed data, composed of:
1.2TBof VM images (qcow2, vmdk)500GBof database dumps (PostgreSQL, MySQL)300GBof configuration files, logs, and various documents
I ensured that both source and destination filesystems were mounted with standard options to avoid distortions in I/O benchmarks. The objective was to simulate a data center environment with high-performance storage for source data and slower, but larger, storage for backups, as is often the case in real infrastructures.
Restic: Features and 2TB Test
Restic is known for its ease of use and content-addressable architecture, which allows for efficient deduplication and fast incremental backups. Its ability to manage repositories on various backends, including S3, SFTP, and local filesystems, makes it extremely versatile.
Initialization and First Backup
Restic repository initialization was immediate. I created a local repository on the 8TB HDD.
restic init --repo /mnt/backup_resticThe first backup, involving all 2TB of data, took approximately 8 hours and 30 minutes. During this phase, Restic consumed a significant amount of RAM, peaking at 12GB. This is a consideration for very large datasets, where available RAM on the backup server can become a limiting factor. Initial deduplication reduced the 2TB to approximately 1.8TB of effective data in the repository. Read also: PostgreSQL: Find Killer Queries with pg_stat_statements
restic backup /data --repo /mnt/backup_restic --verboseIncremental Backups and Performance
I then simulated data changes (adding new logs, modifying configuration files, and altering small portions of VMDKs) to test incremental backups. Here, Restic shone, completing backups in an average of 15-20 minutes, with lower RAM consumption (around 4-6GB). The speed was impressive, thanks to its ability to identify and transfer only modified data blocks.
BorgBackup: Features and 2TB Test
BorgBackup is another excellent backup tool, celebrated for its block-level deduplication and integrated encryption. It is particularly valued for its space efficiency and ability to handle large amounts of data with minimal overhead once the repository is stable.
Initialization and First Backup
For BorgBackup, repository initialization was also straightforward. I created a repository on the same HDD destination.
borg init --encryption=repokey /mnt/backup_borgThe first backup of 2TB took approximately 9 hours and 15 minutes, slightly longer than Restic. However, deduplication was superior: the original 2TB of data was reduced to about 1.5TB in the repository, a significant space saving compared to Restic on the first full backup. This is a major advantage for those with storage space constraints.
borg create --stats --progress /mnt/backup_borg::{hostname}-{now} /dataIncremental Backups and Performance
Incremental backups with BorgBackup took an average of 25-30 minutes, a bit slower than Restic, but still very efficient. CPU consumption remained moderate, and RAM usage was lower than Restic, at around 2-3GB. Its robustness and aggressive deduplication make it ideal for scenarios where space is a precious resource and incremental backups are less frequent but must be extremely efficient.
Detailed Comparison and Results
The test revealed that both tools are valid but excel in different scenarios. Here’s a summary of the main results:
| Feature | Restic | BorgBackup |
|---|---|---|
| First Backup Time | ~8h 30min | ~9h 15min |
| Incr. Backup Time | ~15-20min | ~25-30min |
| RAM Usage (Peak) | ~12GB (first backup) | ~3GB (first backup) |
| Deduplication (2TB) | ~1.8TB (initial) | ~1.5TB (initial) |
| Backend Versatility | High (S3, SFTP, Local) | Moderate (SSH, Local) |
| Encryption | Integrated (AES-256 CTR) | Integrated (AES-256) |
The choice between Restic and BorgBackup depends on priorities. If incremental backup speed and simplicity are paramount, Restic is a solid choice. If maximum space efficiency and superior deduplication are crucial, BorgBackup stands out. Read also: Honeypot August: 7 Days, 1,200 SSH Attacks
Common Errors and Troubleshooting
During the tests, I encountered a few points that deserve attention:
- Restic RAM Consumption: For very large datasets, if the backup server has limited RAM, Restic can run out of memory and fail. This can be mitigated with the
--limit-uploadoption or by segmenting backups, but the best solution is to have sufficient RAM. - BorgBackup CPU Consumption: Borg’s first backup can be CPU-intensive. Ensure the server has sufficient resources or schedule the first backup during off-peak hours.
- Repository Verification: Both tools offer commands to verify repository integrity. It is essential to run them regularly to ensure backups are recoverable. An unverified backup is a non-existent backup.
restic check --repo /mnt/backup_restic
borg check /mnt/backup_borg- Credential Management: Using environment variables for repository passwords (
RESTIC_PASSWORDorBORG_PASSPHRASE) is a secure practice for automation, avoiding writing them directly into scripts.
FAQ — Frequently Asked Questions
Can I use Restic/BorgBackup on NAS or network storage?
Yes, both support repositories on network storage via SSH (SFTP) or cloud protocols (S3 for Restic). It is crucial to ensure that the network connection is stable and fast enough not to compromise backup and restore times. Latency and bandwidth can significantly impact performance.
Which is the better tool for disaster recovery?
Both are excellent. Restic allows mounting the repository as a virtual filesystem, facilitating the recovery of individual files. BorgBackup offers a robust command-line interface for extracting archives or individual files. The choice depends on personal preference and recovery workflow.
Is the integrated encryption secure?
Yes, both use industry-standard encryption algorithms (AES-256 in CTR mode for Restic, authenticated with HMAC-SHA256; AES-256 for BorgBackup). It is crucial to protect the repository passphrase, as data is irrecoverable without it. Relying solely on these encryptions for extremely sensitive data is not advisable, but they provide an excellent first layer of protection.
How can I automate backups and old snapshot cleanup?
Both tools can be easily integrated into bash scripts or systemd timers. It is good practice to combine the backup command with a cleanup command (e.g., restic forget --prune or borg prune) to keep the repository lean and adhere to retention policies. Read also: ACN Incident: 24-Hour Notification Checklist
Conclusions with Operational Takeaways
The choice between Restic and BorgBackup is not universal but depends on the specific needs of your environment. For an organization with 2,000 endpoints and 300+ VMs, where Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are crucial, understanding their differences is fundamental. If you need extremely fast incremental backups and good backend versatility, Restic is an excellent solution, provided you have sufficient RAM. If, however, the priority is maximum storage space efficiency and aggressive deduplication, BorgBackup offers an undeniable advantage, especially for long-term archives. The operational advice is always to test both tools on your actual dataset, monitoring not only times but also resource utilization and, most importantly, the ability to reliably restore data. A backup is only useful if it can be restored.
Updated: August 2026
