Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If one doesn't want to dig into sophisticated backup solutions, it is always possible to write a shell script that gathers data and compresses it. Because of privacy issues one might want to encrypt the backup archive by using a suitable tool (zip/rar with password, gpg etc).

Now when it comes to automation, the problem of revealing the password steps in which creates the following issues:

  • When running the backup script from console, the password is just entered interactively.
  • When running the script via cron, this is impossible.
  • Hardcoding the password in the shell script is bad and ugly.

I believe this is a common situation for this problem. What is the generic or typical solution for the problem of encrypting data with a password, but in automated way?

share|improve this question
up vote 3 down vote accepted

Why re-invent the wheel when you have something like Duplicity which can already do all that for you? Duplicity handles doing incremental backups and can already be scripted to run via cron. It can also use GPG to encrypt the backups and decrypt on restore. Even better is the fact it can handle doing on-site or off-site backup over multiple methods.

share|improve this answer
Good point. BTW, at least Amanda also supports encrypted backups: – sleske Jul 27 '09 at 10:50

I'd recommend duplicity and ftplicity as a front end. With these tools you can sign and encrypt your backups using GPG.

share|improve this answer

One solution is to encrypt the archive using asymmetric encryption. That way the backup server only needs the public key.

You could do that with GPG, for example. It's explained in the sections "Getting started" of GPG's manual ("Generating a new keypair","Encrypting and decrypting documents").

But in general I see no problem with putting the password into some config file. Just make the context file unreadable for regular users. Then whoever can read it will need root / Admin privileges, and people who have that own your box anyway.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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