The comparison usually revolves around speed and compression ratio. Those are the least decisive criteria. What actually settles it is the nature of the tool and where it is allowed to write.
rsync: a synchronization tool
rsync copies efficiently by transferring only the differences. It is an excellent tool — for what it is.
Used bare, it produces an exact mirror of the source. With the delete option, whatever disappears on the source disappears on the copy. You wipe a directory by mistake, and the next sync propagates the deletion. With no earlier versions, there is nothing left to recover.
You can turn it into a backup tool by adding a versioning layer: dated directories where unchanged files are shared through hard links, so each version only costs what actually changed. It is robust, readable, and free of exotic dependencies — every version is a plain directory anyone can browse.
The price: you carry the logic yourself. Retention, consistency, integrity checking, encryption: all of it is on you. And rsync does not deduplicate inside files: a one-gigabyte file with a single byte changed is copied in full into the new version.
Borg: deduplication that changes the scale
Borg solves exactly that last point. It splits data into variable-size chunks, with boundaries determined by the content itself. Inserting one byte at the start of a large file therefore does not shift every chunk after it: only the chunks that genuinely changed are new.
On repetitive data — and a daily backup of the same system is massively repetitive — the gain is spectacular. Backing up virtual machine images every day becomes viable, where a full copy would be absurd.
On top of that come compression, encryption, built-in integrity verification, and retention management with keep rules by day, week and month.
Its main constraint is structural: Borg is at its most efficient when its own program runs at the far end. That assumes a remote server you can install it on. Pointed at object storage or a shared hosting space where you control nothing, it loses its advantage.
restic: freedom of destination
restic offers the same fundamental properties — deduplication, encryption throughout, snapshots, retention — with one decisive difference: it writes to generic object storage or a plain directory, with nothing to install on the target side.
That flexibility opens up the most interesting possibility from a security standpoint, covered below.
On the core features, Borg and restic are comparable. Benchmarks separate them by margins that, in a homelab, will not change your life. The useful criterion is the destination, not raw performance.
The criterion that should decide: who can delete?
Here is the point comparisons list last, when it should come first.
Modern ransomware does not stop at encrypting: it hunts for your backups. It inspects mounts, harvests the credentials stored on the machine, and wipes whatever it can reach. If your backup server is reachable from the compromised machine with full write access, it goes down too.
The countermeasure fits in one sentence: the machine being backed up must not have the right to delete its own backups.
Two concrete implementations:
- Write-once storage: once deposited, data can be neither modified nor deleted before its retention expires, not even by an administrator account. That is restic's edge with compatible object storage.
- An append-only repository: the client can write new data but cannot delete existing history. That is the Borg equivalent, with pruning run from the server rather than from the client.
How to choose
rsync with versioning fits if you back up to a local disk or a NAS, want to be able to read your backups without any tooling at all, and value simplicity above everything. It is also the best choice for an external drive you plug in, sync, and put away.
Borg wins if you have a remote server you control, with large repetitive volumes and long retention. Deduplication is what makes the difference there.
restic wins if your destination is object storage, or if you want write-once protection without standing up a dedicated server.
And in every case, the same closing question: where is the encryption key? If the answer is "on the machine being backed up", your archives are unreadable the day that machine is gone. It has to exist somewhere else, offline, in a place you have written down.
Comments