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

I'm very new to linux and I am running difficulties with duplicity.

I am currently trying to create a backup script using duplicity and backing up over sftp and I am not sure if I am already encrypting the backup. The following is the code I'm running in the script.

export PASSPHRASE=mypassphrase
export FTP_PASSWORD=mypassword
duplicity ~/scripts scp://user@myhost/path/to/backup/dir

Is my backup being encrypted?

share|improve this question

Well, you transfer is since it does use SCP wich is a subset of ssh...

Now, you want to have your script file permission changed so only a specific user can read it/execute it.

After that, you might want to have the files at the backup destination encrypted if you are not to access them unless you need recovery... You could also do that before the transfer for better security in case of DNS spoofing... Especially if the host is on a network that you do not control or Internet.

But YES, sep connection are encrypted.

Hope this help ! ;-)

P.S : I do not know duplicity but if I recall, it does create .tar file... Not sure anymore if it does encrypt as well...

share|improve this answer

Old thread, but the answer here is that SSH (and SCP, sFTP) encrypts the connection. Duplicity is intended to encrypt the file at rest (at its destination) in addition to doing efficient backups. So yes, the script deals with both those issues.

For practical reasons, I would suggest the desire to encrypt at rest is a much greater priority than encrypting in transit. Intercepting a file in transit requires one to be listening/intercepting packets very close to either the source or destination (e.g. on the same network segment or imitating the gateway on either end). Relatively easy to do, but also a limited population who have the opportunity to attack (someone likely physically near you). Also, consider that if you start with an encrypted file, true, someone within that limited population may intercept it, but now what they have for all their effort is a file that is still encrypted. This is my longwinded way of saying that there is a lot of paranoia about "secure" servers or connections and not much focus given to encrypting files at rest, which statistically may be the far greater vulnerability.

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.