The contents or the container?
That’s a conglomerate of several questions I often get about VeraCrypt, TrueCrypt (VeraCrypt’s predecessor), and backing up encrypted drives in general.
Backing up is critical, without a doubt. But when you encrypt sensitive data to protect it, there’s no one answer on exactly how you should back it up. It depends on how you’re backing up already and a couple of decisions you make along the way.
Become a Patron of Ask Leo! and go ad-free!
Backing up encrypted containers
If you keep your data in encrypted containers (such as password-protected zip files or VeraCrypt volumes), it’s important to decide whether you want to back up the container (requiring the software and passphrase to access its contents in the future) or back up the unencrypted contents and secure the backup some other way.
What kind of encryption we’re talking about
First, let’s take whole-disk encryption, such as that offered by BitLocker and VeraCrypt, off the table. They’re actually simpler to back up, with slightly different considerations. You’ll find that covered here: How Should I Back Up an Encrypted Disk?
This article is specifically about encrypted containers. That would include, but not be limited to:
- VeraCrypt containers, which VeraCrypt describes as a ” virtual encrypted disk within a file”.
- TrueCrypt containers, which are the same.
- Password-protected ZIP files.
The key distinction here is that there are two ways of looking at what you have.
- From “the outside”, the container appears as a file whose contents are indecipherable because it’s encrypted.
- From “the inside”, when unlocked with the encryption key, the container appears as a normal file or collection of files.
Let’s look at this last distinction more closely.
Container files
I’ll use VeraCrypt as my example, but this discussion is true for almost all types of containers and archives.
The most common use of VeraCrypt is to create a “virtual encrypted disk within a file” to hold your encrypted data.
Container files from the outside
A container is just a file on your hard disk. Let’s say this file is “C:\data\mydata.hc” (that’s just my example – your container could be any name and be located anywhere).
In this case, our C: drive holds a file. Its path is C:\data\mydata.hc.
When it’s not mounted by VeraCrypt, it’s just a file. In fact, it’s just a file whose content looks like totally random data because the “real” content is encrypted and inaccessible until you have VeraCrypt mount it.
Container files from the inside
If we mount the container file in VeraCrypt (which involves typing in your passphrase and choosing a drive letter), the contents of the container become visible in their unencrypted form and you can work with them normally.
Mounting the container tells Windows to treat it as if its contents were a disk drive. In the example above, we’ve assigned that drive the letter “V:” and provided the passphrase, so the contents of the container are now accessible in their un-encrypted form.
Read data from V: and it’s read from the container and transparently decrypted. Write data to V: and it’s encrypted and written to the container file C:\data\mydata.hc.
Unmount V: and the data is no longer visible in an unencrypted form. It’s all contained in the encrypted container c:\data\mydata.hc.
Backing up
You have two options for backing up what you’ve placed in an encrypted container.
1. Back up the container
In the example above, backing up the container means we’d back up c:\data\mydata.hc. In fact, if you create an image backup of drive C:, it will automatically include the file. Some backup programs even require the volume to be unmounted in order to back up.
The benefits to this approach include:
- Backing up your C: drive causes this container file to be backed up automatically.
- The container file still contains all of your private data, and it remains encrypted.
The drawback is that:
- The container file still contains all of your private data, and it remains encrypted.
That means you’ll need to use the software used to create it in order to access its contents (VeraCrypt in this example).
Back up the container’s contents
This method means you’ll mount your container and back up what appears in the mounted drive — drive V: in my example.
The benefit to this approach:
- The backed-up files are not encrypted and can be accessed without any additional tools.
The drawback to this approach:
- The backed-up files are not encrypted.
If you take this route, you need to secure your backup some other way to keep that data protected.
What’s right for you?
I can’t say.
If your backups themselves are encrypted or otherwise secure, then perhaps you don’t need to back up the container volumes and only need to back up your unencrypted files.
On the other hand, backing up the encrypted container is by definition secure. VeraCrypt and TrueCrypt volumes and Zip files are completely portable and can be opened on any computer running the appropriate software, provided you have the correct passphrase.
Do this
Think through your scenario. The two questions to ask are:
- Will you have the correct software and password if you ever need to recover a backed-up encrypted container?
- If you back up the unencrypted files, would they possibly be accessible to the wrong people?
Regardless of which technique you use, back up.
Subscribe to Confident Computing! Less frustration and more confidence, solutions, answers, and tips in your inbox every week.
Podcast audio
Related Video
There is one other advantage of whole disk encryption mentioned in the TrueCrypt manual: it’s slightly faster than using a container file.
I create a second Truecrypt volume that is the same size as the original on a separate disk and mount them both on startup. I run Syncback every day to make sure that the second volume’s contents is identical to the original. This is free.
I also run Carbonite (carbonite.com) with my own encryption key to backup the contents to the cloud in real-time. This is about $50 a year for unlimited backup.
22-May-2012
I use Macrium Reflect to backup my TrueCrypt encrypted system drive, and in the Advanced Options for the backup job I turn on 256 bit encryption and use a very strong password. That way I have a good reliable backup, and my data is safe whether someone steals my computer or my backup drive. I also use an online backup service that encrypts the data before it leaves my computer as a second backup for my non-replaceable data files, so that even if someone gets both my computer and my backup drive I can still recover my data.
Sometimes restoring a backup of a system drive that was encrypted with TrueCrypt can be a little tricky, in that you may have to repair the boot sector before the computer will boot again, but otherwise it works fine. And of course you have to re-encrypt the drive, because the restored backup is NOT encrypted.
Truecrypt’s default settings do not change the file properties (date stamp and file size) after you make changes to your encrypted container (“file”).
When subsequently doing either an incremental or differential backup, the backup software frequently looks to see if file properties have changed, signaling a need to update that file’s backup. However due to that default setting, changes to the Truecrypt container won’t be recognized . . . or saved/backed up. (“Full” backups copy all files so they aren’t effected).
You frequently recommend Truecrypt (and for great reasons), but I think you should also always advise people to either change this default setting when installing Truecrypt or be aware of the limitations and run full backups of Truecrypt containers.
Your very informative articles are targeted to the less informed — people like me who wouldn’t anticipate this default setting issue and the unintended results.
22-May-2012
Hi,
Is there a way to prevent windows from asking “to format the partition” ? if using entire partition
encryption
22-May-2012
Leo: you’re correct about using private encryption with Carbonite: you lose web access to your files.
Here is what they have to say about Private Keys:
“Currently, only PC (Windows) machines are given the option to manage their private encryption key.
If you choose to manage your private encryption key, you cannot access your backed up files through Anywhere File Access or use the Courier Recovery service.”
Hey Steve and John, did you guys disable your ieee 1394 access; otherwise, truecrypt is worthless.
23-May-2012
I’m bothered, Leo , by your not noting a correction that i communicated to you regarding your comment that ‘one can not backup a full system disk Truecrypt system without decrypting it. In your reply to me personally, you agreed with me: several ‘boot CD-based’ recovery ware certainy can do this: Eg: terabyteunlimited.com ‘s “TBI Backup” programs. On such an important matter, your reader’s should have this knowledge, don’t yu agree?
26-May-2012
Cloud Sync with Private Encryption Key
I wasn’t aware of Carbonite, until reading this page, but have been using IDriveSync, for a couple of months, with its private encryption key feature.
IDriveSync offers 5 GB of cloud storage, for free.
The company claim support of OS X, iOS, and Android. I hope the private encryption key is supported for cross-platform syncing, but there’ll need to be a Linux version before I explore this.
I use Veracrypt’s full disk encryption. I find it more secure, no danger of accidentally leaving an important file unencrypted, and simpler, type in a password before booting and I’m done. I back that system unencrypted to an external drive at home. Since I’m mainly concerned about protecting my laptop when I’m out, I don’t see the need to have my backups encrypted. If I do want my backups encrypted, I can have my backup program do that.
When I used container encryption, I just backed it up normally with my system image backup. If anything happened to my hard drive, I could either restore the system image and if the VC container were damaged, I would have mounted the backup and copied the container file to the HDD.
Related to backing up an encrypted container but unrelated to , if you have Veracrypt set to never update the timestamp, it won’t be backed up
because backup programs check for the timestamp and file size to see if the file has been changed.
If you have a large container, the whole container will be backed up even if you only change one tiny file, thus eating up a lot of backup storage space.
Leo, you wrote:
“…[T]here are two ways of looking at what you have.
[…]
From “the inside,” when unlocked with the encryption key, the container appears as a normal file or collection of files.”
Leo, I do believe you may have intended that sentence to read, “From the ‘inside,’ the container appears as a normal folder or collection of files.”
And even that’s a tad misleading: From the “inside,” a (mounted) encrypted container doesn’t merely appear to be, but really and actually is, a completely separate (but temporary) drive within Windows [File] Explorer, complete with its own drive letter (e.g., in my own case, “M:\”)!
Hope this clarifies things a just bit…