Multiple repos needed for redudancy?

I have read an article in c’t magazine about BorgBackup (paywall, German: BorgBackup: Datenverlust ist zwecklos | c't | Heise Magazine).

There c’t writes, that you should do 3-2-1 backups. Three copies, 2 different devices, 1 outside your house. Referred to BorgBackup you should use 2 repos. They argue that BorgBackup doesn’t store redundant. Even “worse” they deduplicate data blocks. So a corrupted block could affect many files.

As I know restic is amongst others inspired of BorgBackup. So does this also apply to restic?
Or do you think it’s a good advice at all?

Today I have a restic repo on a hosted SFTP server. The SFTP server takes snapshots of the repo on file basis and uses a RAID. Should be fair enough, shouldn’t it?

It all boils down to common sense and what you want to protect against. This has nothing to do with what is recommended in the Borg world or not.

If you want to protect against your house burning down along with your local backup copy, have an offsite one. That’s indeed a good idea.

If you want to protect against an attacker getting access to your repository server and being able to erase its entire storage, make a setup where you have a copy stored on immutable storage or similar to prevent the attacker from erasing all your backups.

RAID is just something that to some degree protects against disk failures, so that’s pretty much a different topic.

In short; Use as many backup copies/repositories as makes sense for your needs and how important your data is. Think in terms of “if X happens, how can I restore my data?” and orchestrate your backups based off that.

1 Like

OK, I understand. But to evaluate for me: restic has no redundancy, hasn’t it? When a datablock is damaged restic couldn’t restore it with ECC or something like that?

So said when my repo is damaged I have only the hope, that a older file based snapshot of the repo of my hoster has a working state. Or it didn’t get damaged at all because of the RAID. Which of course is not a 100 % security at all.

In general the 3-2-1 strategy exists for more than 20 years and is a good advice, no matter which software you use for your backup.

  • your hard drive may crash
  • your house may burn
  • the data center may burn (as we saw with ohv on France)
  • backup may be corrupt

But statistically all these things should not happen all together at once. So with 3-2-1 there should always be a way to go.
Also BTW the backup outside your house does not necessarily have to be a data center. It may also be the house of your parents or a friend or something like that. Like in times before cloud storage became popular, I would always bring one backup on USB drive to my office and swap that one a week.

1 Like

Restic can detect which parts of your repository has been damaged, but you still need the data in order to correct those damaged parts in the repository, yes. This is a good reason to have multiple backups.

OK, thank you rawtaz and betatester77!

1 Like

There are some thoughts about adding parity for redundancy. Maybe it will come one day.

1 Like

Thank you for the link!

I’m a little bit confused, because I searched in the issues before.
I think I have slept too little today - sorry … :sleepy:

Feature request: Implement error correcting code

1 Like

In How to create par2 parity files for a Restic repository users have created some scripts to manually add ECC information using par2.

But - as already said - ECC just prevents from bitflip-type errors, for other error cases it is advisable to have a copy at a different place using different hardware/technology.

2 Likes