borg supports compression, restic doesn't (and there is no way to add it without breaking backwards compatibility because of how the file format was designed). That's all I need to know for my use cases.

I used to use borg and I migrated away from it to Restic when I somehow corrupted my backup archive. I dunno what I did, but I started getting "non-utf-8 filename" python errors every time I tried to access it. It might have had something to do with the archive being on a removable disk.

Anyway! I'm happier with restic now. It's never crashed for me, and it has native cloud backends. But it's ultimately just another backup application.

And I managed to corrupt Restic archive, so I switched to Borg

So the lesson is, they can all be corrupted. I'm a borg user btw, it's been working fine for several years now so I have no plans on switching.

I use it over NFS.

> So the lesson is, they can all be corrupted.

To which the conclusion is: test your backups!

Still, some might corrupt more easily than others. People just confuse first-hand problems with statistical significance.

Is there any statistically-significant data on which backup applications are the most reliable? I'm not married to restic, but I'll judge it by first-hand experience in the absence of anything else.

Not really, no. It usually goes like in this thread: Someone had a problem with software X and switched to software Y. Someone else had the opposite experience. It's worth pointing out that Borg and other hash-deduplicating backup tools regularly find faulty hardware where other backup tools wouldn't notice the data getting corrupted (e.g. many people advocate for "plain" backup tools like rsnapshot or just having an rsync cronjob, but all of these are unable to check the integrity of backups). Sometimes, users point to the backup tool (sometimes they're right and it's a bug, but usually it's a bad stick of RAM or a hard drive loosing a few bits here and there).

I switched from Borg to Restic because it nicely integrates with cloud backup services. I've been using restic+backblaze happily for the last 2 years.

And it's just a single go-binary, i just trow it on a win/bsd/linux machine create a key, start the backup. I love the simplicity of it, however for more complex plans i use git-annex.

Does restic provide time travel like Borg does?

By time travel if you mean viewing/mounting your repo at various checkpoints then yes.

Borg is much older and has seen production use for decades and had all the bugs worked out. Iirc rustic is still sub-1.0. Not ideal for backup software.

Borg sequentially scans your filesystem for changes and only then starts backing up changed data. (tbf: a lot of backup tools seem to do this)

Restic scans your filesystem for changes, and then also starts backing up the changes it finds in parallel while it is still scanning for more changes.

When you have millions of files, this makes a huge difference.

This is wrong. The difference between the two is that Restic uses multi-threading and Borg currently doesn't. Both just scan the filesystem and add files to the backup set as they go.

Hmm, maybe it has changed or I'm remembering wrong. It's been years since I tried borg, but I remember it taking something like 10 hours to scan for changes, and then another 4 hours or so to actually backup the data.

With restic, it still took around 10 hours to scan for changes, but it was also already done backing up all the data by the time the scan finished.

Speaking of which, borg in Debian is maintained by the Debian Borg Collective, and the nickname of one of the maintainers is Locutus of Borg: https://tracker.debian.org/teams/borg/