[bccdee]

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.

[sheerun]

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

[INTPenis]

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.

[lucb1e]

> 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.

[bccdee]

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.

[formerly_proven]

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).