Restic vs Borg for server backups

Both restic and Borg are free, open source tools that turn a server's files into encrypted, deduplicated snapshots. People choose between them all the time for hosting servers, and both are good. The difference that decides most cases is where the backup can live. This comparison uses each project's own documentation, read on 30 October 2026.

The short comparison

Sources: restic.net, the restic repository docs, borgbackup.org and the Borg documentation.

What the two tools have in common

Both read your files, cut them into chunks at points set by the content, and store each distinct chunk once. A daily backup of a server where little changes costs a small amount of space and time after the first run. Both encrypt on the client, so the storage provider only sees ciphertext, both keep every backup as a snapshot or archive you can list and restore, and both can mount a snapshot as a folder to browse old files. Both are single programs you run from cron or a systemd timer, with no server to install.

Where the backups can go

This is the practical difference. Restic's documentation lists local folders, SFTP, its own REST server, Amazon S3 and S3 compatible services such as MinIO and Wasabi, OpenStack Swift, Backblaze B2, Azure Blob Storage, Google Cloud Storage, and any service reachable through rclone. For a hosting server the usual wish is "to a bucket somewhere else", and restic does that directly.

Borg 1.4 works with a local path or a remote repository over SSH, as its general usage page shows. To reach an object store you would copy the repository with another tool, and the Borg FAQ says you may use any reliable tool that makes an identical copy, naming cp, rsync or rclone, and warns to do it while no backup runs. A cheap SSH backup server, or a storage box with Borg support, works very well and keeps the fast native protocol.

Borg 2 changes the storage model, but the Borg site lists 2.0 as in testing and says not to use it in production yet. The releases page shows beta builds up to 2.0.0b25 as of 30 October 2026. If your plan depends on Borg 2, it depends on a beta.

Encryption and keys

Restic's reference says files are encrypted with AES-256 in counter mode, with a Poly1305-AES MAC. Borg's security notes say its encryption is AES-256 in CTR mode, authenticated with HMAC-SHA-256 or BLAKE2b-256. Neither is the weak point. The passphrase is: do not store it on the server next to the repository, and keep a copy where a fire or a lost account cannot take both. A backup you cannot decrypt is no backup.

Deduplication, compression and speed

Both use content defined chunking, so inserting a few bytes in the middle of a large file does not re-store the whole file. Borg lets you choose a compression method such as lz4 or zstd per backup. Restic has compression for newer repositories, but check the version you run. Speed claims on the internet vary with file counts, network and CPU, so measure on your own data. A server with millions of small files behaves differently from one with a few large databases.

Pruning, checking and the restore drill

Both tools separate making backups from deleting old ones. In restic you run forget with a retention policy and prune to free space; in Borg prune applies the policy and compact frees space. Both can check a repository. Restic's check --read-data reads every pack file, which the documentation notes costs time and, on cloud storage, download charges, so it offers --read-data-subset to check a slice each week.

The test that counts is the restore. Do this once, and again each quarter:

1. Restore one file to a scratch folder and compare it with the original.
2. Restore a database dump and import it into a throwaway database.
3. Restore a whole site into a new account, or a new server, and open it.
4. Write down how long step 3 took, from nothing to a working site.

A test plan for choosing

Copy a representative slice of your server, such as a hosting account with its database dump, to a test machine. Back it up with each tool to the target you really plan to use, change a few percent of the files, back up again, then time each of these: first backup, repeat backup, restore of one file, restore of everything. Note the repository size for each. Run it with a stable version, not a beta. The results tell you more than any benchmark post.

Where RespireCloud fits

RespireCloud backups are encrypted restic repositories with S3, Backblaze B2 and other targets, schedules, integrity checks and test restores, and a recovery bundle for the keys. See storage and backups, and automatic off site backups to S3 and Backblaze B2 for what to set up. If you run your own scripts instead, everything above applies the same way.

Which one should you pick

• Your target is a bucket (S3, Backblaze B2, Azure, Google Cloud). Restic.
• Your target is an SSH server you control, with Borg on it. Borg is excellent here, on the stable 1.4 line.
• You want one tool for many targets and little scripting. Restic.
• You want per backup compression choices and mountable archives over SSH. Borg.
• You want to wait for object storage in Borg 2. Wait until its authors call it ready, and test the migration first.

Either choice beats having no tested backup. Keep one copy somewhere else, encrypt it, guard the passphrase and restore from it before the day you need to.