SpiderOak Woes

[blu-Z8efaSeK1ezqlBn2x/YWAg at public.gmane.org (Edward Ned Harvey)]

> From: discuss-bounces-mNDKBlG2WHs at public.gmane.org [mailto:discuss-bounces-mNDKBlG2WHs at public.gmane.org] On Behalf
> Of Rob Hasselbaum
> 
> Is this efficient in practice? For example, if I create an encrypted
volume
> in TrueCrypt, it shows up on the host file system as just a big file. Is
> CrashPlan (or any other backup provider) smart enough to only transfer the
> changed bits on each sync? Or is it going to move the whole file every
time
> some part of it changes?

Don't confuse the two things here - Crashplan itself encrypts the data
communications and storage.  By default, they generate and manage a key for
you, but you have the option to generate and manage your own, so you can be
assured they don't have access to your data.

If it just so happens that your data includes something like a truecrypt
volume, I've heard it said that crashplan is smart enough to send just the
changed parts.  I'll point out that in order to do so, it is a requirement
that the whole thing be read locally which is disk intensive, and possibly
cpu intensive, but if they live up to the claims, it's not necessarily
network intensive.

Around 2 years ago, I tested this very concept.  Create a truecrypt volume
(large dynamic/sparse volume) and back it up.  Then, mount it, make some
trivially small change, and dismount it.  Create an incremental.  As I
recall, it performed up to the claims - But then there was a problem.

Never trust a backup system until you complete a successful restore.  I
tried to restore that truecrypt volume, and guess what.  Since it's a sparse
file, it's represented as a really big file, and there was no option
available at the time, to restore a formerly sparse file sparsely.  So in
the worst case, you would not have enough disk available and the restore
would fail.  In the best case, you could successfully restore the file
without sparseness, and it would simply take an eternity to complete, whilst
consuming a smeg load of disk space.

I submitted the feature request to support sparse files better.  They seemed
to be clueless what I was talking about.  I recall conversations (I don't
remember if it was email, online chat, or phone) where I repeatedly
explained what a sparse file was, and how it's useful in encrypted volumes
and virtual machines.  Nevermind what's a virtual machine, it's just a
program that creates a special type of file.  Yes, a sparse file.  No, it's
not a file type, it's a property.  Etc.  It seemed to me like they probably
weren't going to do it, so I gave up and didn't look back.  But that was a
couple of years ago.  I have no idea what they've changed since that time.