Hey, welcome to the forum!
You can indeed use restic to backup a container, that’ll work. You won’t get to benefit from the deduplication built into restic so much, but the sparse areas in the container will deduplicate just fine. For a sequence of zeroes, restic will use 512KiB for the block size. Another downside of your approach is that you can’t just use the restic mount command to browse around in the backups, which is a really nice feature!
I’m not sure about the file system recommendations in this setup, sorry.
Excellent question! You’re partly right: Damage to the key files is fatal. The config file is not so important, we can live without it (although in this case you’d need to patch restic, but it’s possible). The index files are just an optimization, they can be rebuilt from the files in data/ with restic rebuild-index from scratch. When a file in data/ is damaged, it depends if it’s a metadata file, all files referenced cannot be restored, but in theory the data is still there. If it’s a data file, parts of files won’t be restorable.
Not quite, restic uses standard crypto (AES256 for encryption and Poly1305-AES for MAC), although the combination is not so common. The implementation is the one from the Go standard library, which is used by many other projects.
At least one cryptographer looked at the crypto in restic (and decided to use it for his personal backups):
You should be skeptical, I can understand that very well. And you’re also right: The crypto in restic is much better than dm-crypt: With block devices, you’re given a 512byte block-based interface, and you need to provide this to the higher layers in the kernel. There’s no way you could store additional data, like an IV or a MAC. So basically when you’re using block-device-based crypto, you give up on authenticating the data you’re decrypting. The only way around that is to implement crypto on the file system layer or higher, like zfs or restic.
For restic, all files in the repo (except the key files) are encrypted and have a MAC, so we can check the data is authentic before attempting to decrypt anything. This eliminates a whole class of vulnerabilities (like Padding Oracles).
If it helps anything, I’m working as a penetration tester, so I get to break systems and crypto for a living. Which does not imply that I’m overly qualified in implementing secure systems, but I have a very good idea what the most relevant vulnerabilities for such systems are and how to prevent them.
We cannot guarantee that, it’s very hard to do (depending on the backend). We’re trying very hard, though. The order in which the files are written to the repo, and the fact that each file in the repo is written exactly once, and then either deleted and/or replaced by a file with a different name, helps with this.
I don’t know if you’ve discovered the design document yet, but it’s here: References — restic 0.16.3 documentation The complete repository is defined there, and it’s rather simple.
That’s very hard to say. From Europe at least, B2 is very slow due to the high latency of at least 800ms until the HTTP response header arrive for each API call. DigitalOcean Spaces is faster, but I’ve gotten reports from several users that the service seems not to be stable.
Do any of the other users in this forum have recommendations?
In terms of file systems: I’ve heard very good things about zfs, did you try that yet?