I have the following problem. I'm currently need to store my backup on a cloud solution like dropbox since my local nas is broken. That's why I have to encrypt my backup. I'm using rsnapshot to generate it.

On the NAS I didn't encrypt it so I'm not experienced with it. What I've done is, I've zipped the latest backup and simple encrypted it via gpg. However, its still encrypting. My backup is aronud 50GB. I've never encrypted such a big file. Is there a way to encrypt such big files more efficiently or what am I doing wrong?

  • 1
    There are basically two ways you will probably want to look at doing this in the future. Rather than making one giant archive and encrypting that, it might be faster (or at least more manageable) to encrypt the individual files, and archive those. Alternately, look into actually encrypting the entire filesystem itself, but that would not apply to something like DropBox or AWS S3. – DopeGhoti May 8 '18 at 19:12
  • I too would also suggest finding another encryption solution. I'd suggest using a combination of lvm-snapshots with dm-crypt. That way you have fully encrypted file system backups. – Lucas Ramage May 8 '18 at 19:33

The time it takes to encrypt is proportional to the size of the data, plus some constant overhead. You can't save time for the whole operation by splitting the data, except by taking advantage of multiple cores so that it takes the same CPU time overall (or very slightly little more) but less wall-clock time. Splitting can of course be advantageous if you later want to access part of the data.

GnuPG compresses data before encrypting it. If the data is already compressed, this won't do anything useful and may slow the process down a little.

I recommend duplicity to make encrypted backups. It takes care of both collecting files and calling GPG and it knows how to do incremental backups. It splits the data into multiple volumes, so it can save wall-clock time by encrypting one volume while it's collecting files for the next one.

The first time you back up 50GB is going to be slow regardless. If you have AES acceleration on your hardware, it helps (as long as you make sure that GPG is using AES — GnuPG used CAST-5 by default before version 2.1, but it uses your public key's preferences and that should default to AES even in GPG 1.4 or 2.0).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.