[Box Backup] Store corruption not detected or fixed by bbstoreaccounts

Alex Harper boxbackup@boxbackup.org
Sat, 24 Jan 2009 13:59:20 -0800


> Is it deep in directories? Could you copy it and its parent directories to
> a new account? Otherwise can you leave it in the account that it's in now
> for a few days?

New discoveries (see below) make me believe I should keep the whole thing as
an exemplar. I've solved the problem by finding enough space to replicate
the account.

> Well if you trust Box Backup's crypto then it's safe to send it to me
> anyway :) (as I don't have your keys) but I understand if you don't want
> to.

I'd prefer to avoid it.

> I might need to send you test programs to run against it to try to decrypt
> parts of the file and see whether it works or not.

I'm happy to test anything you like. However, I should add that things have
gotten worse...

On the original account with the original crypto error I reported, another
error has cropped up on a different file:

WARNING: zlib error code = -3
WARNING: Exception thrown: CompressException(TransformFailed) at
../../lib/compress/Compress.h(154)

Looking back at captured output this error was reported in the same compare
-a output as the original crypto error, but because it wasn't a fatal error
I overlooked it. However, I actually needed to restore the file yesterday
and the restore failed.

I then ran compare -a on another user's account and discovered the exact
same error on a similar data file. In the case of the second account the
compression exception was fatal. I'm still not sure why it wasn't fatal on
my account.

In both my account and the other user account the newly discovered corrupt
file is a large (1.5GB or more) mail database that Box is backing up while
open but largely quiescent. The files are from the same program (Entourage
2008) on two different laptops of two different architectures (PPC vs x86).
In both cases this is a hot file with a large number of revisions.

Since the files are so structurally similar and updated similarly I'm
willing to believe that this is a problem with the diff patch. Or maybe a
problem with recipe generation in general.

Its also possible that the problem is with the filesystem, as a part of
diagnosing this I discovered a frayed cable to the drive. That said, fsck is
fine, other non bbstored data on the drive checksums correctly, and it seems
suspicious that the corruption is so similar. The argument against
filesystem issues or cosmic rays would be that since these are not the only
hot files, why are they having such similar errors?

If you have any diagnostics you want me to run I'm willing. Because I'm
cutting over to my secondary backup as the primary now and shutting down
bbstored there's no longer much time pressure, I can keep the account around
for a while if it helps.

Alex


--
Alex Harper                                     aharper@foobox.net
"Use whatever you think of first" -- Larry Wall