Home / server / Questions / 654397
Accepted
initall
Asked: 2014-12-24 05:25:15 +0800 CST

How do I encrypt large (20Gb+) compressed files from a backup?

  • 772

I want to encrypt regularly created and compressed backup files from OpenVZ containers, before they leave the server and get copied to the providers backup space via ftp.

They vary in size, from 6 to 50 GB (after being compressed, lzo) UPDATE ... and are created automatically by the virtualization environment Proxmox.

Various comments here and there on mcrypt ("code quality / support") or openssl ("not for large files") that make me wonder if they fit. What can you recommend?

Furthermore: I can't split the backup file during compression to smaller parts and don't want to do it afterwards for performance reasons. I've had bad experiences using duplicity and want to avoid it, should you want to mention that.

The server environment is Debian 7.

debian

1 Answers

  1. Best Answer

    Others have suggested various symmetric encryption tools which are suitable for pipelining, such as aespipe. I suspect those will be about as efficient as you can get, given that encryption is a fairly CPU-expensive sort of thing to do, and it's not a bad suggestion.

    But I'd suggest considering an asymmetric tool such as gpg. The under-the-hood bulk encryption will still be via a symmetric cipher using a nonce key, but the whole issue of key management becomes vastly easier with the GPG toolchain available.

    In particular, the use of a simple symmetric cipher to encrypt the backups either fatally torpedoes the security (in that the same key is used to encrypt all backups, and the server must have access is to it on a regular basis) or substantially increases your complexity (in that you use a different key for each backup, and must now manage them manually).

    With a tool like gpg, you can generate a single keypair for the encryption of all backups, and the server that encrypts needs only the public half to which to encrypt the backups. You can keep the private key separately, either under normal security or - if business reasons require it - arrange to split the key amongst many individuals, some subgroup of which is needed to reconstitute the private key, using standard key-sharing protocols.

    • 2