restic vs BorgBackup vs rclone: A Practical Comparison Guide for Linux Server Backups by Use Case

restic vs BorgBackup vs rclone — Choosing a Backup Tool for Small Linux Servers

"I backed it up, but I couldn't restore it" — the tool you pick decides whether you recover

There's a truth you only learn at 3 a.m. when something actually breaks: backup is not about storing data — it's about restoring it. You've run tar from cron onto an external disk, then discovered the archive was corrupt, you'd forgotten the password, or the snapshot you needed had been overwritten. If you're a solo developer or a small-team infra person, you've probably been there.

This post is not another troubleshooting dump. It's about confidently picking the right tool for your situation. restic, BorgBackup, and rclone are all excellent — but they are not the same thing. Spoiler: none of them is universally "the answer." The right choice depends on your storage backend, budget, and dedup needs. I've included copy-paste examples so you can have automated backups running in about 30 minutes.

The core differences at a glance: a three-way comparison

Let's start with the part that trips people up. The biggest difference among these three is whether you're looking at a real backup tool or a sync tool.

The most important row is the last one. rclone has no point-in-time restore. You can use rclone like a backup tool, but at heart it is a mirror. That distinction is where tool selection starts.

Recommendations by scenario: "If your situation is X, use Y"

(a) Offsite cloud (B2/S3) first → restic

If you want the repo on object storage like Backblaze B2 or S3, restic is the least friction. The client talks to S3/B2 natively — no extra daemon — and encryption, dedup, and compression are built in, so setup stays simple. It's a single binary, easy to deploy, and restores cleanly across platforms. If your goal is "throw it in the cloud and forget it," restic is the closest thing to the right answer.

(b) Local NAS + strong dedup and compression → BorgBackup

If you back up the same server wholesale every day and the change volume is small, Borg's dedup efficiency shines. You get a wider choice of compression (zstd/lz4), and it's mature and fast on local and SSH repos. The catch: the repo side needs a borg binary (typically over SSH), and S3 is not a first-class target — so Borg is strongest when the destination is a local disk, a NAS, or a server you can SSH into. If you want B2, you'll need to go through rclone.

(c) Simple file sync / mirroring → rclone (but this is not a backup)

If you only need to mirror static files, media assets, or data that already has a source of truth elsewhere, rclone is light and fast. This is not a backup. rclone sync deletes files on the destination when they disappear from the source. Accidentally wipe the original, let sync run, and the "backup" evaporates with it. Need point-in-time restore? Use restic or Borg. If you insist on rclone as a backup, at least combine it with versioning (B2 file versions) or --backup-dir.

Copy-paste setup: init → backup → retention → automation

restic basics (Backblaze B2 example)

# save·· set
export RESTIC_REPOSITORY="b2:my-backup-bucket:server01"
export B2_ACCOUNT_ID="<keyID>"
export B2_ACCOUNT_KEY="<applicationKey>"
export RESTIC_PASSWORD="<_>"

# 1) save ( 1)
restic init

# 2) backup run
restic backup /etc /var/www /home --tag daily

# 3) + ( 7 / 4 / 6 )
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

# 4)
restic check --read-data-subset=5%

BorgBackup basics (SSH remote repo)

export BORG_REPO="ssh://backup@nas.local:22/./repo"
export BORG_PASSPHRASE="<_>"

# 1) save (repokey: save )
borg init --encryption=repokey

# 2) backup (zstd , archive )
borg create --compression zstd,6 \
  ::'{hostname}-{now:%Y-%m-%d}' /etc /var/www /home

# 3)
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6

# 4)
borg check --verify-data

One-line cron automation

# 3when backup + ( /var/log)
0 3 * * * /usr/local/bin/restic-backup.sh >> /var/log/restic.log 2>&1

systemd service + timer (recommended)

Logging and failure tracking are cleaner than cron. Create two unit files and enable the timer.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=restic daily backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStart=/usr/bin/restic backup /etc /var/www /home --tag daily
ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
Nice=10
IOSchedulingClass=idle

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

With Persistent=true, if the server was down at backup time, systemd catches up after boot. On small setups, that option saves you more often than you'd think.

Four common traps

Ransomware now goes after the backup repo itself — encrypting or deleting it. That's why the 3-2-1 rule (three copies, two media types, one offsite) and immutable/append-only backups are back in the spotlight.

1. Skipping append-only mode — Borg can force a remote repo into append-only. Put command="borg serve --append-only ..." in SSH authorized_keys and a compromised client cannot delete existing archives. On B2/S3, turn on Object Lock (immutability) or versioning.
2. Underestimating restic prune cost — On cloud storage, prune eats memory, time, and API calls. Back up daily, but prune weekly instead of every day, and you'll cut cost and load.
3. Treating rclone sync as a backup — As above, sync deletes destination files to match the source. There is no versioning or point-in-time restore. For backup, use restic/Borg, or at minimum pair --backup-dir with storage-side versioning.
4. Lost password/key = permanent data loss — Lose restic's RESTIC_PASSWORD or Borg's passphrase/keyfile and the data is gone forever. Store it in a password manager, and keep a Borg keyfile in a separate, safe location.

From the field: I run restic + B2 for a single VPS, and Borg for in-house NAS backups. One simple rule — "restic for native cloud convenience, Borg for local dedup and compression" — cut the time I used to waste second-guessing tools.

Rough storage cost comparison: B2 vs S3

On small backups, egress (download) cost often matters more than storage price. Restore tests and real recoveries mean pulling data down, and S3 Standard egress is not cheap.

※ Prices change often — always check the official Backblaze and AWS pricing at the time you read this. The table shows relative trends, not exact numbers.

The takeaway is clear. For tens to hundreds of GB of offsite backup, B2 is usually cheaper, and S3-compatible stores (B2, Wasabi, etc.) have made the market more competitive.

Conclusion: one command you can run today

The most dangerous backup is the one you keep postponing while you wait for a perfect design. Start now.

export RESTIC_REPOSITORY="b2:my-backup-bucket:server01"
restic init && restic backup /etc /var/www

And run a restore test at least once (restic restore / borg extract). A backup you cannot restore is not a backup.

FAQ

Q. Which is easier to start with, restic or BorgBackup? A. If you're pushing straight to the cloud (S3/B2), restic is simpler to set up and a better first tool. If you're stacking backups on a local NAS or an SSH-reachable server and want strong dedup and compression, Borg is more efficient.

Q. Can I back up with rclone alone? A. Not recommended. rclone is a sync tool; point-in-time restore and versioning are not built in. If you use it anyway, you must combine it with storage versioning (B2 file versions) or --backup-dir.

Q. How do I keep ransomware from hitting the backup repo too? A. Use Borg --append-only, turn on Object Lock (immutability) or versioning on S3/B2, and keep an offsite copy under the 3-2-1 rule. Also keep backup-server credentials separate from the client.