Re: TrueCrypt & Carbonite
- From: Prof Wonmug <wonmug@xxxxxxx>
- Date: Mon, 20 Sep 2010 13:55:49 -0700
On Mon, 20 Sep 2010 15:58:08 -0400, Mark F <mark53916@xxxxxxxxx>
On Sun, 19 Sep 2010 12:57:20 -0700, Prof Wonmug <wonmug@xxxxxxx>
I recently installed TrueCrypt and have been experimenting with it. ICrash Plan (and perhaps other products) do a better job of handling
have discovered a couple of by-products or using it with a backup
system like Carbonite, which I use.
1. While the drive is mounted, the files are in the clear to all
programs running on the machine. Before I realized this, Carbonite,
which backs up continuously, had backed up all of the supposedly
encrypted files on my test volume. With Carbonite, I am able to
designate a volume to be excluded from backup, but I must do this
explicitly. This may not be a problem for some people.
2. If the TrueCrypt file is very large (gigabytes), Carbonite excludes
it from backup by default. I can override this, but I have to
explicitly do it. This is one of the drawbacks of these
all-you-can-eat backup systems. They play games to keep you from
eating too much.
3. If you change anything on the TrueCrypt volume, the file gets
modified and must be completely backed up again -- even if only a few
bytes actually changed. If the file is in the GB range, that could
take days to back up every time it changes.
large files: they only backup the parts that have changed.
Crash Plan seems to scan the entire file for changes and only backs up
the changed data, reducing the time needed for your backup to
complete. I think it also saves storage space for them at storage
side, which in the case of Crash Plan can be their central side, a
local or LAN disk of yours, or a "friend"s disk.
I have Crash Plan for backups of TrueCrypt volumes and for VMware
virtual disks (I put my big TrueCrypt volumes "inside" of VMware
virtual disks so that I can have multi-part container files.
Unfortunately the modified date changes for each of the 2GB VMware
container files when a volume is mounted, Crash Plan has to scan
all of the 2GB containers, rather than just the ones that actually
got changed while the virtual disk was mounted.) Crash Plan scans
at just about full disk speed, so a 2GB file takes about 20 seconds to
scan. Things would be impractical for me with a 300GB virtual disk
that I typically only change a few small files on each time I mount,
but I use Crash Plan for a bunch of 2, 4, and 8GB TrueCrypt files.
Like I say, use Crash Plan - it only transmits the changed data and
I don't know any way around any of these.
much faster than Carbonite anyhow.
How does it know what changed? By doing a binary compare?
Have you tried it with a TrueCrypt file? I don't know for sure, but I
would imagine that a TrueCrypt file might have extensive changes if
even only 1% of the unencrypted data changed.
If I get a minute, I might run a binary compare after changing one
file in a 100 file repository.
I looked at the CrashPlan website. I found it a lot more muddled than
Carbonite. A lot of options that are not clearly explained. Carbonite
may not be perfect, but it is what it says in the ads: Backup. Simple.
I may try CrashPlan if I get time, but my initial impression was only