I run a small modest CentOS server at my house for misc backups, etc. My friend on the other side of town also runs a small modest server at his house for similar purposes. We have been toying with the idea of using eachothers servers to do remote/offsite backups.

Basically, we'd each buy an external hdd to store at eachothers homes, hooked up to eachothers servers. Then, we'd each setup scheduled rsync's to push the appropriate data from one server to the external hdd on the other server. Pretty straightforward for the most part.

However, one thing that is important (at least for me) is data encrpytion. I want to store my data on the external hdd on my friends server. But I don't want my friend (or anyone who accesses my friend's server) to be able to read whats on the external hdd.

What is the best approach to this? Can you use rsync to send data to an encrypted hdd drive and somehow pass a passphrase along with the data that it uses to write it once it reaches the server?

5 Answers 5


I would take a look at Duplicity. It is free and easy to use.

Duplicity will do full and incremental backups and transfer them using rsync, FTP, SFTP, etc.

Duplicity uses GPG to encrypt the backups and uses signature files and what not.

I use it to backup my email servers and it is fantastic, one simple batch file.


Warning There are some security concerns regarding encfs raised by this security review. Cryfs or ecryptfs should be considered instead ## sync local unencrypted data to remote encrypted backups via rsync ..

## mount read-only encrypted virtual copy of unencrypted local data :
encfs --reverse --idle=60 -o ro ~/data/ ~/.tmp_encrypted_data/

## rsync push local encrypted virtual copy of data to remote encrypted copy :
rsync -ai --whole-file ~/.tmp_encrypted_data/ [email protected]:backup/

## unmount encrypted virtual copy of local data :
fusermount -u ~/.tmp_encrypted_data/
  • 2
    Wow, I'd never heard of EncFS before. This is AWESOME, given I have 200GB to sync to cloud from a laptop with a 240GB disk. Feb 3, 2015 at 8:52
  • 1
    This solution seems more optimal then the duplicity or rsyncrypto variants. It's just a simple rsync of an encrypted (virtual) version of your files. That's just what was required in my situation. Problem with duplicity is the BIG full-backup. Problem with rsyncrypto is the requirement of a copy of your data. EncFS just encrypts it when rsync reads the data.. :D Jun 19, 2016 at 21:37
  • 1
    How do you access this data again?
    – veio
    Jan 30, 2021 at 12:15
  • 1
    @veio To access your data again you need the hidden file .encfs6.xml. That file contains the encrypted key, and your password is necessary to decrypt it. You also need to set the environment variable ENCFS6_CONFIG. You can see more information here: wiki.archlinux.org/title/EncFS Nov 26, 2022 at 18:05

rsyncrypto has been written exactly for this purpose. It allows you to leverage rsync's delta-copy algorithm while encrypting your data locally and storing the encrypted blobs remotely.

However, keep in mind that rsyncrypto makes a tradeoff between security and performance.

  • 2
    Having had a quick look at how rsyncrypto works, I'm rather terrified at the idea of anyone using it. I'd like to see a reputable cryptographer's opinion on the approach before I trusted any of my data to it.
    – womble
    Aug 7, 2015 at 9:39

Here is my backup script based on Thor's answer (still valid several years later!). It adds copying of file .encfs6.xml as needed for later decryption (not needed on 2011?), creation of temporary folder for encrypted mount and reading of encryption password from file (for automated scripting):



SOURCE_ENC=$(mktemp -d /tmp/source_enc.XXXXXX)
echo "Created temporary folder $SOURCE_ENC ..."

## sync local unencrypted data to remote encrypted backups via rsync

# mount read-only encrypted virtual copy of unencrypted local data
encfs --extpass="cat /home/jortiz/.passbackup" --reverse --idle=60 -o ro $SOURCE $SOURCE_ENC

# rsync push local encrypted virtual copy of data to remote encrypted copy
rsync -ai --whole-file $SOURCE_ENC/ $BACKUP

# Copy encfs xml file to backup folder for later decryption
rsync -ai --whole-file $SOURCE/.encfs6.xml $BACKUP

# unmount encrypted virtual copy of local data
fusermount -u $SOURCE_ENC

echo "Removing temporary folder $SOURCE_ENC ..."

In my case, I am setting up a daily backup of my laptop and small servers to a external USB drive connected locally. I want to encrypt the backup just in case the drive disappears one day, together with some sensitive data.

  • If you just want to copy data to a local USB disk, I recommend using full-disk encryption (with LUKS) and then doing rsync --link-dest to the drive. I expect this to be faster, more private, and using more proven technology, which is always good for backup. This has been rock-solid in my experience (and I had many backup disappointments, e.g. with TimeMachine to remote storage, Duplicity, and Btrfs with Snapshots). There are several examples for rsync --link-dest uses out there, e.g. netfuture.ch/2013/08/… May 21, 2020 at 13:24

A solution like the one you describe above requires sending your encryption key to your friend's machine. If we consider your friend an "untrusted site" you've just blown your security (he can capture the key and read your data).

If you want to be sure your friend can't read your backups you must encrypt the files before you send them (e.g. make a tarball, encrypt it with gpg or similar, then rsync it over), and never give him the key (or enough plaintext to reverse-engineer the key).
Note that doing this negates the delta benefits (bandwidth savings) of using rsync: The encrypted file will change substantially each time you make a backup, so you'll probably be copying the whole thing every time.

  • 4
    that is what is nice about Duplicity, it encrypts it before leaving the computer but it is fully capable of doing incremental backups by reading signatures/change lists and what not, that is why I suggested it to him. The first backup will take a long time but after that he will be good to go while maintaining a nice level of security.
    – Luma
    Jul 13, 2010 at 18:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .