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?
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.
I'd recommend duplicity and ftplicity as a front end. With these tools you can sign and encrypt your backups using GPG.
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.