[bArray]

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]

There's a lot of complexity in gpg that's unnecessary for this usecase, I'd use age instead.

https://age-encryption.org/

[yjftsjthsd-h]

Sure, but I trust GPG. Has age been audited? Has it been attacked in the wild and held?

[voidmain]

gpg 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]

Can 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