Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Attention CrashPlan users



David Kramer <david at thekramers.net> asked:
> Before I do this, can you tell me what happened and how you
> recognized it?  Did it corrupt the backup?

Some background on this is available at the vendor's own forum:
https://crashplan.zendesk.com/entries/64160-how-do-i-request-a-full-integrity-check

For two years, I have been subscribing to their remote backup service, and
also using their software to run my local backups (I switched from Amanda, and
opted for CrashPlan Desktop rather than the oh-so-user-unfriendly Bacula for
backing up several home computers beyond my main fileserver).

On 23-Jan, I ran a restore on the main fileserver to a scratch volume.  The
total size of the local backup volume is small, about 65GB out of 10TB of
storage, and I wanted to extract about 18GB of files.

About 60% of the files restored OK, but over 6000 of them wouldn't unpack. 
The CrashPlan software cited checksum errors.  Reporting this to the vendor, I
haven't yet gotten past tier-2 support; the front-line folks doubt that there
is a bug like this.  I firmly believe there's a problem worth looking into. 
But their front-line procedures aren't robust enough to gather the forensic
data needed to properly diagnose and report a true data corruption problem if
such exists in their software.

One other thing I was (belatedly) told by their tier-2 manager was that I
hadn't configured the so-called service log for adequate retention time.  So
once I figure out how this is configured, if I can get some other CrashPlan
users to watch for the problem (it will be silent until you do a restore),
then we should collect lengthy (as in months-long) verbose debug-enabled
service logs.

At the moment my recommendation on CrashPlan for potential new users is: look
for another product.  For current users, it's:  watchful waiting.

-rich





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org