Why won't my Truecrypt volume backup?

One of the nice aspects of Truecrypt volumes is that they are great ways to
back up information – to the cloud or elsewhere – safely and securely. Create a
volume with a strong passphrase, load up your secure data, dismount and you’re
good to go.

But … maybe not.

Depending on the backup technique you use there’s a default setting in
Truecrypt that might be getting in your way. Fortunately it’s an easy fix.

]]>

The short answer

In Truecrypt preferences make sure that “Preserve modification timestamp of file containers” option turned off and you can backup your Truecrypt container files as you would any other.

Traditional backup uses timestamps

One of the most common ways that backup software determines whether a file needs to be backed up is by looking it it’s time stamp. More specifically, the “last modified” timestamp, which indicates when the file was last changed.

By comparing the file’s timestamp with that of its backed up copy, the backup software can infer either that the file hasn’t changed since it was last backed up, or that it has and thus the backup needs to be updated.

That kind of timestamp comparison is actually the basis for incremental backups: backup only those things that have changed since the last backup.

Truecrypt and timestamps

Truecrypt volumes are container files that, in turn, contain in encrypted form a complete file system along with all the files and folders you choose to place in the Truecrypt volume.

For example you might have your Truecrypt container as a file “mystuff.tc”. When mounted (which requires specifying the decryption passphrase) it might then also appear as drive “P:”. Within P: you would find all the files contained with that volume. When dismounted only the container file – mystuff.tc in this example – remains visible, and if examined is only so much random data since it’s encrypted.

Here’s the dilemma: what timestamp should the container file have?

One would think that the container should reflect the most recently modified timestamp of any file it contains. If the volume is mounted and you change a file within it – say you edit P:\passwords.txt – you might expect the container file – mystuff.tc – to then also have the same timestamp, since that’s the time at which it was last modified.

You might expect that, but you would be wrong.

By default a Truecrypt container’s ‘last modified’ timestamp is not updated by Truecrypt.

Why Truecrypt works this way

It’s definitely not obvious.

At least not until you think about what Truecrypt is trying to do.

Truecrypt is trying to keep your encrypted information private.

And information about when you modified your encrypted information … well, that’s actually part of that encrypted information too.

Exposing it by updating the externally visible timestamp of the container – something that can be seen without needing the passphrase – actually boils down to a form of information leakage and is a potential security/privacy risk depending on how you’re using Truecrypt.

Truecrypt’s default behavior breaks backup

So, you’re going along and using Truecrypt to keep your sensitive data. Fantastic.

You update the sensitive files in your Truecrypt container. Great!

You then dismount the Truecrypt volume, and run your backup.

And the volume doesn’t get backed up.

Even though you’ve changed information within it.

The volume doesn’t get backed up because as we’ve now seen Truecrypt doesn’t update the container’s timestamp by default. Thus the backup software thinks the container hasn’t changed and doesn’t need backing up.

Even though it does.

Changing Truecrypt’s behavior

Fortunately for most of us exposing the date the container contents have been updated isn’t a big deal, doesn’t represent a risk, and is something that we’d rather have so our backups would work.

Right click on the Truecrypt icon in the taskbar, and click on Preferences.

Make sure that “Preserve modification timestamp of file containers” is not checked, and click OK.

By unchecking this option, Truecrypt will not preserve the timestamp, but rather update it.

If something has changed within the container Truecrypt simply sets the container’s timestamp to be the time at which it was dismounted. It’s not at all uncommon for that to always be true, as particularly if the container is formatted NTFS data kept within that file system is updated even if no files are actually modified.

Now, when backup comes along, it’ll see that the timestamp has changed since the last backup, and will backup the container like any other file.

Note: your container may still be dismounted in order to be backed up. When the container is mounted Truecrypt locks it such that most other applications cannot actually access it. Depending on your backup software this may impact its ability to backup the file. Dismounting resolves this issue.

What I do

I use Truecrypt extensively, and I have the “Preserve modification timestamp of file containers” option turned off. The timestamp on the Truecrypt volume file is updated when I unmount it.

As you might expect I keep assorted sensitive files in this Truecrypt volume, and protect it with a strong passphrase. I keep my Truecrypt volume in Dropbox.

During the day I might mount the volume and make changes to its contents. When I later unmount the Truecrypt volume Dropbox notices and determines that the timestamp has changed and backs up the file – both to the Dropbox servers as well as to all the other machines on which I have Dropbox installed.

If, for some reason I need to have the Truecrypt volume mounted on more than one machine at a time I select one machine on which to mount it normally, and use Truecrypt’s read-only option to mount it on any other machines. This avoids a conflict in the case where the volume is modified on two machines simultaneously.