Hello, everyone. I was sitting around thinking about file systems, specifically ext4 and btrfs. And I thought about restic. So, one question came to mind: “Why isn’t restic redundant in storage?” I started looking for information on this topic. I would like to discuss with you a scenario where a bit of data on the disk crashes or a sector breaks. Why doesn’t restic create a duplicate blob in storage for such cases? When restic was not yet able to compress data, it would have been unreasonably difficult for storage. But now that restic can compress data, it could create a duplicate blob in case the first one breaks for some reason. I would like to hear your opinion on this
UPD: I would also like to add that it would be great if this parameter could be configured. For example, so that you could pass a command or key to the storage to determine how many blob copies the storage should contain.
In setups and filesystems which have redundancy, they are able to ensure that their copies of the data are on separate physical devices.
Although you may get lucky and experience only localised corruption such that additional copies that ended up on the same physical device can be used to repair, my gut feeling is that I’d always like for extra copies to be on different physical devices, so some way to do that would be desirable.
But then, can I not already solve this by either doing redundancy myself in the filesystem (or below), or else running two restic repositories on different devices and having one copy to the other after a check had been done?
So, I am not sure if this would be a very high priority feature.
I wouldn’t mix up the functions. I like the Unix philosophy that a tool should do one thing and do it well. Filesystems and RAID solutions are available for handling data corruption. Everyone can choose the one that suits them best.
