Both restic and BorgBackup are serious, privacy-respecting open-source backup tools. They solve the same problem differently. This comparison covers speed, compression, backend support, security model, and which fits your workflow.
| Feature | Restic | BorgBackup |
|---|---|---|
| Platforms | Linux, macOS, Windows, FreeBSD | Linux, macOS (limited Windows) |
| Backend support | Local, SFTP, S3, B2, Azure, GCS, rclone | Local, SFTP/SSH only natively |
| Compression | zstd, lz4, gzip (good) | lz4, zlib, zstd (often better) |
| Encryption | AES-256 client-side | AES-256 client-side |
| Deduplication | Content-defined chunking | Variable-length chunking (often smaller) |
| Setup complexity | Low | Medium |
| Append-only mode | Via rest-server | Native SSH append-only |
| GUI options | Backrest, Resticprofile | Vorta, BorgBase |
| Active development | Yes | Yes |
| Windows support | Full | Limited, WSL workaround |
Borg typically achieves better compression on text-heavy workloads like source code, logs, and config files. Restic uses zstd by default since 0.14 and the difference is smaller than it used to be. For binary data, media files, and already-compressed files, neither tool helps much - compression is skipped automatically.
Deduplication is roughly comparable. Borg's variable-length chunking can be more efficient on certain workloads. Restic's content-defined chunking is predictable and works well across all data types.
This is restic's biggest advantage. It natively supports SFTP, S3-compatible storage, Backblaze B2, Azure Blob, Google Cloud Storage, and anything rclone can reach. Borg natively supports local and SSH/SFTP only - you need rclone as a wrapper for cloud backends.
If you want to back up to multiple cloud backends, or need S3 or B2 specifically, restic is the cleaner choice.
Both tools encrypt everything client-side before upload. Neither the storage provider nor an attacker who compromises the storage can read your data without the key. Borg's SSH append-only mode is excellent - it prevents an attacker who gains access to your backup client from deleting existing backups. Restic's rest-server provides similar protection via its append-only mode.
For new setups, restic is the more practical default. The broader backend support, better Windows handling, and simpler mental model make it easier to maintain long-term. If you are already using Borg and happy with it, there is no reason to switch. The tools are comparable in reliability and both have active communities.
Restic has been the faster-moving project over the past two years. The 0.16 and 0.17 releases brought improved compression defaults (zstd is now the default), better large-repository performance, and enhanced copy command support for migrating between backends. The go-based single binary model means upgrading is a drop-in replace with no dependency chain to manage.
Borg 2.0 has been in development for several years and brings significant improvements including a new archive format and better performance, but the migration path from Borg 1.x requires manual steps. For existing Borg users this is a consideration for planning upgrades.
The hosted backup service landscape reflects the tool split. BorgBase is the primary managed hosting option for Borg users. For Restic users, ServerCrate provides a dedicated SFTP vault purpose-built for the Restic over SFTP workflow - private vault per user, ZFS-backed, flat pricing, no egress fees.
If you are choosing between restic and Borg partly based on hosted service quality, the comparison is between BorgBase (mature, EU + US options, strong Borg-specific tooling) and ServerCrate (purpose-built for Restic, US West Coast, ZFS storage integrity, simpler pricing). See the BorgBase vs ServerCrate comparison for more detail.
If you are starting fresh in 2026 with no existing backup history: use restic. The setup is simpler, the backend support is broader, and the community resources are excellent. If you have years of Borg repositories and a working setup: stay on Borg. Migration is painful and the tools are functionally comparable for Linux server use cases. The right tool is the one you will actually maintain and test restores on.
Here's what you actually type to get a first backup running with each tool. Assume you've installed the binary (apt install, pacman -S, or download the static binary) and you have an SFTP destination.
export RESTIC_REPOSITORY=sftp:user@host:/path/to/repo
export RESTIC_PASSWORD=your-password
restic init
restic backup /etc /home /var/wwwThat's the whole setup. restic init creates the encrypted repository, restic backup creates a snapshot. No config file, no additional tooling.
# Configure SSH key auth with the remote first
export BORG_REPO=ssh://user@host/path/to/repo
export BORG_PASSPHRASE=your-password
borg init --encryption=repokey-blake2 $BORG_REPO
borg create $BORG_REPO::'{hostname}-{now}' /etc /home /var/wwwBorg requires SSH key-based auth on the server side (password SSH doesn't play well with Borg's SSH multiplexing). Once SSH is set up, the workflow is similar but the repository format is different.
Both tools support similar retention concepts but with different flag syntax. A typical homelab retention (keep 7 daily, 4 weekly, 12 monthly) looks like this:
restic forget \
--keep-daily 7 \
--keep-weekly 4 \
--keep-monthly 12 \
--pruneborg prune -v --list $BORG_REPO \
--keep-daily 7 \
--keep-weekly 4 \
--keep-monthly 12Nearly identical. See our full Restic retention policy guide for edge cases like yearly retention, tag-based pruning, and avoiding common mistakes.
This is the workflow you'll run during a real emergency. Fast, targeted restoration matters more than anything else. Both tools support browsing snapshot contents and pulling specific files.
mkdir /mnt/backup
restic mount /mnt/backup
# browse the tree, find your file
cp /mnt/backup/snapshots/latest/home/user/file.txt /tmp/
fusermount -u /mnt/backupborg list $BORG_REPO
borg extract $BORG_REPO::snapshot-name home/user/file.txtRestic's mount workflow is more intuitive if you're used to standard Unix file operations. Borg's extract is faster for known-path restores. Full restore guides: Restic restore guide.
Both tools are fast enough that network upload speed is almost always the bottleneck. Here's what actually differs in practice:
check --read-data tends to be faster for integrity audits, especially over remote SFTP.--append-only mode is a clean protection against ransomware on the client side: even if your backup client is compromised, the attacker can't delete existing snapshots. Restic can achieve this with rest-server but it's not the default.Private vault ready in seconds. Works with any restic setup.
No egress fees, cancel anytime, 7-day money-back guarantee