3 ms·
If anybody else is using a similar method, I think it's also good to encrypt the backups: tar -zcv <SRC_BACKUP> | gpg -c --batch --passphrase <PASSWORD> -o
by bArray 7y ago
If anybody else is using a similar method, I think it's also good to encrypt the backups:
tar -zcv <SRC_BACKUP> | gpg -c --batch --passphrase <PASSWORD> -o <DEST_BACKUP>.gz.gpg
In my experience the encryption part doesn't add any extra time on a modern machine, with the spinning disk being the slowest cog.
- NieDzejkob 7y agoThere's a lot of complexity in gpg that's unnecessary for this usecase, I'd use age instead. https://age-encryption.org/ https://age-encryption.org/
- voidmain 7y agogpg is widely agreed to be a train wreck, but age is not generally suitable for encrypted backups because it doesn't offer any form of authentication (so an attacker can replace a backup with a malicious one).
- cyphar 7y agoCan you elaborate on the threat model a little bit? I'm struggling to understand how you can protect against this in a way where an attacker that both knows the relevant encryption key (whether public or secret, depending on whether the crypto is asymmetric) and has write access to the backup location. If you sign the backups with some distinct key of the backup server, why wouldn't the attacker have access to those keys too (in the above scenario they already have access to the keys that the backup server is using for encryption). I know there's an open issue in age for adding authentication[1], so there clearly is some threat this would protect against but I can't figure it out. [1]: https://github.com/FiloSottile/age/issues/59 https://github.com/FiloSottile/age/issues/59
- yjftsjthsd-h 7y agoSure, but I trust GPG. Has age been audited? Has it been attacked in the wild and held?