Restic vs BorgBackup

The single most useful question is where the backups will live, because that narrows the choice fast. Restic was built with cloud object storage as a first-class target. It writes directly to Amazon S3, Backblaze B2, Wasabi, Azure Blob, Google Cloud Storage, plus SFTP, local disk, and its own REST server, with no helper needed. If your plan is to push encrypted backups to cheap object storage, Restic is the natural fit.

Borg does not talk to object storage directly. Its remote model is SSH to a machine that also has Borg installed, which it uses to do deduplication on the server side efficiently. That is powerful for a backup server you control, and hosted Borg providers like BorgBase and rsync.net exist precisely to be that endpoint. To push Borg to S3-style storage you bolt on rclone, which works but adds a moving part. So: object storage leans Restic, an SSH or local Borg repo leans Borg.

Both deduplicate by splitting data into content-defined chunks and storing each unique chunk once, so backing up the same files repeatedly costs little extra space and unchanged data is never re-sent. In practice both are very space-efficient, and for most homelab data the difference is modest.

Borg has a long reputation for the tightest storage efficiency, with mature deduplication and compression that squeeze repositories hard. Restic historically lacked compression, which narrowed the gap in Borg's favor, but Restic added zstd compression in version 0.14, closing most of it. Today both compress and deduplicate well; if absolute minimum repository size is your priority, Borg still has a slight edge, but it is no longer a decisive one.

Restic ships as a single static Go binary with no dependencies and runs on Linux, macOS, and Windows, which makes it trivial to drop onto any machine, including Windows clients that Borg does not target. Borg is Python-based and centered on Linux and macOS; running it on Windows is awkward. If you need to back up mixed operating systems with one tool, that alone can decide it.

Operationally both are command-line tools you wrap in a script and a scheduler, with snapshots you can list, mount, and prune by retention policy. Each has community front ends if you want a UI: Backrest is a popular web UI for Restic, and Vorta is a desktop GUI for Borg. Whichever you choose, set a retention policy, prune on a schedule, and test a restore, because an untested backup is a hope, not a backup.

Both encrypt by default and are designed so the repository can live on storage you do not fully trust. Data and metadata are encrypted client-side before they leave the machine, so a compromised S3 bucket or backup host exposes ciphertext, not your files. This is what makes pushing either tool to cheap third-party storage reasonable.

The flip side of client-side encryption is that the key is everything. Lose the Restic key or the Borg passphrase and the backups are unrecoverable by design; there is no reset. Store the key or passphrase somewhere separate from the backups themselves, such as a password manager and a second offline copy, so a single failure does not take both your data and your only way back to it.

Whichever tool you pick, the point is a real backup strategy, not just running a command. The 3-2-1 rule is the standard target: three copies of your data, on two different media, with one off-site. Both tools support this naturally, with one repository on a local disk or NAS for fast restores and another in the cloud or on a remote host for the off-site copy.

This is also where the backend choice and the tool choice meet. A common, dependable setup is Restic to Backblaze B2 for the off-site copy plus a local repository for speed, or Borg to a home backup server plus a hosted Borg provider off-site. Either pattern gives you the off-site protection that matters when the risk is fire, theft, or ransomware rather than a single failed drive.