Is there a good way to incrementally sync truecrypt containers? I currently have large containers (200gb+), and I'd like to find a way to back them up without having to mount them. Rsync seems to not be able to sync incrementally and instead tries to re-transfer the whole container each time even when only a single file inside the container changed.

Is there some rsync patch or some specific option to make rsync look harder for differences instead of transferring the whole file? Or, is there some better tool to do this?

  • Were the two containers created separately or was one a copy of the other. I think if they were created separately they will be different due to the random data you enter when you created them whereas if one was a copy of the other the rsync might (I'm guessing) work better. – Col Aug 14 '11 at 8:39
  • It was a copy. Then, I changed one file in the original container. – vonhogen Aug 14 '11 at 20:52

Unfortunately, due to the nature of stream encryption, it is not possible to incrementally back up an encrypted volume. This is because the entirety of the volume is cryptographically dependent on each individual part. This is for security reasons. You will need to either decrypt the container, or copy the container entirely each time.

| improve this answer | |
  • 5
    Actually, if only the changed sections of the file are transferred then that should work. Also, TrueCrypt works on a per-block basis meaning that only those blocks with data that has been changed get modified -- updating the entire 200+ GB container file for a single changed byte would require far too many processor and disk I/O resources to be practical. – Randolf Richardson Aug 14 '11 at 6:40

It seems this has been solved.

From the rsync website:

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.

| improve this answer | |
  • 1
    It is best not to provide just a link as an answer. By providing a description/precis of what you're linking to it helps in case the linked address changes. (It makes it easier to search for) – Tog Jul 23 '13 at 11:40

I've just tested rsyncing a TrueCrypt container to a remote host.

Incremental backups do in fact work. Initial transfer of a 128 MB container:

bash$ rsync -v --progress --checksum --inplace test.tc $REMOTE_HOST:
   134217728 100%  339.51kB/s    0:06:25 (xfer#1, to-check=0/1)

sent 134234196 bytes  received 31 bytes  338547.86 bytes/sec
total size is 134217728  speedup is 1.00

Then I copied a file to the TrueCrypt volume and rsynced again:

bash$ rsync -v --progress --checksum --inplace test.tc $REMOTE_HOST:
   134217728 100%   49.42MB/s    0:00:02 (xfer#1, to-check=0/1)

sent 162256 bytes  received 81140 bytes  23180.57 bytes/sec
total size is 134217728  speedup is 551.44

As you can see, after adding a file to the container, the second transfer was only 160 KB.


  • the --checksum option tells rsync to use checksums instead of only looking at the mod-time and size; if you don't do this, rsync won't know that the volume changed.
  • the --inplace option tells rsync to update the destination file in-place.
| improve this answer | |

RSync is a good tool for this because of its "delta-transfer" feature (which is enabled by default) that only transfers changed sections of files.

The fact that your file is at least 200 GBs means that when RSync reads the entire file to detect changes, it's likely that you're getting the impression that the whole file may be getting transferred instead of only its changes.

| improve this answer | |
  • I have the -P option turned on, so I can see the amount being transferred. It is transferring all 200gb by my calculations (the time also suggests this since it's indicating 4-5 more hours to go). I only changed one 30mb file within the container. – vonhogen Aug 14 '11 at 6:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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