[1kGarand]

I see some terrible backup strategies here.

1. Backups should not be on a single drive. 2. Backups without checksums will result in corruption. 3. Offsite is a must. 4. Unencrypted off site backup means someone already copied your data. 5. Encrypted offsite backups should have forward secrecy. So different keys for each file and keys file gets backed up encrypted.

My backup strategy: File server runs zfs raidz with Daily/weekly/monthly snapshots on disk.

Snapshots get copied to 2 external drives, zfs mirrored.

Files get encrypted and uploaded to backblaze using my custom software. Nothing fancy, just standard authenticated encryption (chacha20poly-poly1306) but with per file key management and argon2.

[walterbell]

> Encrypted offsite backups should have forward secrecy. So different keys for each file and keys file gets backed up encrypted.

Any references on PFS for backups? Was there no existing OSS backup solution that implements PFS?

[cyphar]

I'm not sure why you'd want PFS for backups. The idea of backups is that you have a history (not just a simple mirror) and so having PFS intentionally renders older backups unusable (unless you're storing all the keys -- in which case you have somewhat defeated the point of PFS).

Now, PFS would allow you to handle key compromise by making future backups unreadable. But there are other solutions for this (such as upgradeable encryption).

[1kGarand]

Most encrypted backup solutions are really bad with protecting keys. Fixed ivs are ok for one file. Not ok for possibly millions of small files. Basically exposed your private key along with your backup.

[walterbell]

How do you manage millions of keys, if you have millions of small files to be backed up? Would it be ok to have something between 1:all and 1:1?

[1kGarand]

Sqlite.