![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 | |
We also thank MIT for the use of their facilities. |