Rsync: how to mount truecrypt on-the-fly on the receiving side?

Question

The short version: how can I keep an rsync backup on a truecrypt volume? The hard part is to mount/unmount this volume on the fly when it is needed for rsync.

Details

This is my current backup configuration (which works fairly well for the most part):

• backup source is on Win7 64 bit, destination is a remote Linux box (Debian)
• actual data transfer is done by rsync via ssh (cwRsync with cygwin)
• rsync daemon is started on demand via ssh

On the Linux box the backup is protected by file permissions only. I want to increase security here and put the backup into a truecrypt volume. I can fuse-mount that volume manually in the shell. The question is now how can I make rsync not only open an ssh connection and starting the rsync daemon, but also to mount the truecrypt volume before (and unmount it after)?

My money is on option --rsync-path which can be used to pass a command line to ssh - provided that stdin and stdout still work the same. I guess that command would have to be a shell script. Is this possible, and what would the script look like?

For reference, here's a quote of that option:

--rsync-path=PROGRAM

Use this to specify what program is to be run on the remote machine to start-up rsync. Often used when rsync is not in the default remote-shell's path (e.g. --rsync-path=/usr/local/bin/rsync). Note that PROGRAM is run with the help of a shell, so it can be any program, script, or command sequence you'd care to run, so long as it does not corrupt the standard-in & standard-out that rsync is using to communicate.

One tricky example is to set a different default directory on the remote machine for use with the --relative option. For instance:

rsync -avR --rsync-path="cd /a/b && rsync" host:c/d /e/

This is the full rsync man page.

Answer 1

Meanwhile I have worked out any issues and have a solution which works for me since a few weeks. In case anybody is interested I am posting the details here. This article by Troy Johnson has helped along the way.

Prerequisites

• Truecrypt installed on Linux and available on the path
• a TC container prepared and available at /home/deepc/var/backup.tc
• cygwin and rsync installed on Windows and available on the path

Linux

I made two shell scripts to mount and unmount the Truecrypt container on the Linux box. Those scripts are being called remotely via ssh from the Windows machine:

~/bin/backup-mount.sh:

#!/bin/bash
# usage: backup-mount.sh <password>
~deepc/bin/backup-umount.sh
echo "$1" | sudo truecrypt -t --slot=2 -k "" --volume-type=normal --protect-hidden=no /home/deepc/var/backup.tc /home/deepc/mnt

~/bin/backup-umount.sh:

#!/bin/sh
sudo truecrypt -d /home/deepc/var/backup.tc

Windows

remote-backup.cmd:

@echo off
setlocal
set HOME=c:\home
set LC_ALL=de_DE.utf-8
set LC_CTYPE=de_DE.utf-8
set LANG=de_DE.utf-8

rem --iconv=utf-16,iso-88591
ssh -p THESSHPORT -i ../.ssh/id_dsa deepc@theremotehost.com bin/backup-mount.sh THEPASSWORD
rsync -rltvzPm --modify-window=1 --exclude-from=../etc/backup/excludes.txt --chmod=ugo=rwX --delete --delete-excluded --files-from=../etc/backup/files-from.txt -e "ssh -p THESSHPORT -i ../.ssh/id_dsa" --log-file=../tmp/remote-backup.log /cygdrive deepc@theremotehost.com:/home/deepc/mnt
ssh -p THESSHPORT -i ../.ssh/id_dsa deepc@theremotehost.com bin/backup-umount.sh

Put this batch file into the task scheduler, e.g. with a daily schedule. Be sure to adjust username, remote host, ssh port, Truecrypt container password, and of course the backup paths. Sorry but I could not bring myself to clean this up more after having wasted too much time already...

With this script Rsync will read includes and excludes from two text files, e.g.:

files-from.txt:

/c/Home/
/c/Users/deepc
...

excludes.txt:

Firefox/Cache
Firefox/*.lock
Thunderbird/*.lock
Thunderbird/**/*Junk*
Thunderbird/**/filterlog.html
Thunderbird/**/*.msf
Home/tmp
...

Done?

This is answers the original question. There is only one minor issue: special characters in filenames on Windows are mangled on Linux, with ext2 being used in the TC container on Linux. I tried all combinations for the --iconv parameter I could think of but to no avail. Seems I have to live with that - unless some brave soul has read until here, knows the answer, and enlightens me in a comment ;-) (NTFS in the container is not an option)

Answer 2

I've been trying to do something similar. I have Truecrypt containers on my laptop which I want to sync with a location on my NAS. Because I want two way sync I've been using Unison rather than rsync but Unison implements the rsync protocol so should be similar in operation.

I've used the idea of synching the TC container whilst it was unmounted and relying on the fact that TC only changes portions of the container if small numbers of data changes are made. However, the issue I find is that due to the size of the container (20GB or more) it still takes forever to sync as the destination (the NAS) which has a fairly low powered CPU has to checksum the entire container file to decide whether it has changed. The actual transfer is fairly quick but there is a long period beforehand where it chews CPU.

So, instead I've moved to the other approach that deepc has been working on, mounting the container at the remote end and then synching the contents. This is much quicker with a sync taking in the order of a few seconds if nothing has changed (as opposed to >45 mins with the other approach). The only think that was holding me up from this approach originally was that I couldn't get TC compiled on my NAS (Arm based) but I've solved that problem now and it's all working really well now.

I suppose YMMV and 'true' rsync may be better than Unison in this regard. But I would go with the synching of the contents of the containers rather than the containers themselves.

Answer 3

Use the truecrypt command line interface.

truecrypt --mount file --password=password

should work and truecrypt -h should give you a few ideas. However, the password would then have to be stored in plain text in your rsync file. Be careful to ensure it does not end up in some bash history on your destination box, otherwise the added security would vanish - a malicious attacker could just call history | grep truecrypt, see your password and have your backups.

Answer 4

If your truecrypt volume exists as a file in Windows, why not simply copy the file to the Linux machine? Then it is encrypted in transit and already encrypted when it gets to the destination. Add to that the fact that you don't ever have to use the credentials...

If the Windows machine supports VSS, you might be able to get a copy of even a mounted filesystem that is as consistent as it would be if you shut down the machine by pulling the plug.

If the volume doesn't exist as a file, this might not be nearly as easy. Also, I don't know how to program use of VSS, but I understand that it does snapshotting for use when backing up. (I don't know too much about the details).

Answer 5

It might actually be unnecessary to do this, as it would appear that rsync can efficiently do an incremental backup of a truecrypt container without having to look inside it. Note: I'm assuming that the motivation for doing this is to get the benefits of an incremental copy, which may not be the intention of the asker...

We are happy to report that the internal structure of truecrypt disk images make it possible to efficiently rsync them to a remote location. This means that after the initial (complete) upload of your TrueCrypt disk image, subsequent uploads will efficiently transfer only the changes that have been made to the encrypted filesystem since its last upload.

Found on http://www.rsync.net/resources/howto/windows_truecrypt.html and also a reference in this comment thread: http://digg.com/news/technology/TrueCrypt_Tutorial_Truly_Portable_Data_Encryption

rsync will not resend the entire file again, as it normally does with files encrypted with gpg, etc. Truecrypt only changes the portions of the file that require changing

and

I use the --partial and --inplace options, and it works like a charm. Generally transfers 2-3 GB each time, depending on how much work I did that week ...

I'll be testing this out soon, will comment back here with my findings.