CrashPlan ist eine Software zur Datensicherung auf externen Festplatten, auf Computern von Freunden und in der «Cloud» – und aus meiner Sicht vorläufig leider nicht mehr empfehlenswert, nachdem ich im «Try before you buy»-Weblog von Nik Clayton folgendes gelesen habe …
If you’re a Crashplan user (quite possibly because I’ve recommended it to you in the past) you need to be aware that.
1. Previous versions of Crashplan have silently corrupted data that has been backed up.
2. The team at Crashplan are aware of this. More recent versions of the software do not have this problem.
3. However, more recent versions of the software do not fix, acknowledge, or in any way indicate that some of the files in the backup are corrupt.
4. Crashplan support appear to wholly unconcerned with this in a manner that means I no longer have faith in the product or their support. I leave you to determine the course of action that’s right for you.
… auf Deutsch zusammengefasst: Ältere Versionen von CrashPlan beschädigten gesicherte Daten, in neueren Versionen wurde das Problem behoben. Allerdings beheben diese neueren CrashPlan-Versionen das Problem nicht, so dass die beschädigten Daten beschädigt bleiben. Ebenso werden die betroffenen Benutzer nicht informiert. All das im Widerspruch zur CrashPlan-eigenen Beschreibung der Funktionen …
Once your files are backed up, CrashPlan continuously checks that your files are 100% healthy and ready to restore when you need them. If it finds any problems, CrashPlan fixes them.
… das Beispiel zeigt, dass es nicht genügt, Daten zu sichern – auch die Integrität und Wiederherstellung der gesicherten muss regelmässig geprüft werden.
Nachdem ich das zitierte Blogpost in großen Teilen und daraufhin den Thread zum Thema im Crashplan Forum gelesen habe ist meine Vertrauen in Crashplan (zum Glück) wiederhergestellt! Matthew Dornquast hat in einem ausführlichen Posting klargestellt, dass es sich um eine falsche Darstellung eines einzelnen Support-Mitarbeiters gehandelt hat.
Ich bin geneigt dieser Darstellung zu vertrauen. Wie man auch in der vom Original Blog-Post zitierten Kommunikation mit dem Support sehen kann, wurde offensichtlich das eigentlich Anliegen, das Vertrauen in den Service zu bestätigen/wiederherzustellen und eine Erklärung für das Verhalten zu geben, von dem Mitarbeiter nicht erkannt. Das ist allein schon ziemlich dämlich wenn man bei einem Backup-Unternehmen arbeitet, deswegen glaube ich gerne, dass der Support-Mitarbeiter auch den technischen Hintergrund, den er mit Entwicklungsingenieuren diskutiert hatte nicht richtig wiedergeben hat.
Matthew beschreibt in seiner Klarstellung, dass Crashplan regelmäßig die Daten in den Backup-Archiven anhand der gespeicherten Prüfsummen überprüft. Falls die Daten auf dem Quellrechner noch vorhanden sind werden sie automatisch neu übertragen. Das geht natürlich nur falls die Datei auf dem Quellrechner nicht gelöscht wurde. Auch alte Versionen werden nicht magisch wiederhergestellt. Das ist allerdings nicht der Fehler von Crashplan! Laut Matthew ist die Software nicht als Archivlösung vorgesehen. Es kann also vorkommen, dass alte Daten, die auf dem Quellsystem schon gelöscht wuren, bei Versagen eines Backupziels verloren gehen. Unter anderem aus diesem Grund hat Crashplan auch schon immer empfohlen mehrere Backup-Ziele zu verwenden.
Was genau in dem Fall des Original-Posters passiert ist, lässt sich wohl nicht mehr nachvollziehen. Allerdings stimmt die Darstellung in den oben zitierten Punkten nicht, da sie sich auf falsche Aussagen eines Support-Mitarbeiters beruft. Das der diese so gemacht hat ist natürlich für Crashplan äußerst geschäftsschädigend. Die Aussage
ist schlichtweg falsch, da die Hardware des Original-Posters die Daten nicht korrekt gespeichert hat und nur der Prozess zur automatischen Reparatur/Neuübertragung nicht funktionierte. Dieser läuft periodisch und auf lokalen Backups seltener als auf Crashplan Central. Es könnte also z.B. sein, dass die Beschädigung einfach noch nicht entdeckt wurde.
Im Endeffekt bleibt die ganze Sache eine Frage des Vertrauens und bei Verwendung von mehreren Backup-Zielen fühle ich mich bei Crashplan immer noch am besten aufgehoben. In Matthews Post beschreibt er für meine Begriffe glaubwürdig, dass Crashplan mit einer gesunden Portion Paranoia versucht alle erdenklichen Szenarios von Datenverlust in den verschiedenen Komponenten des Rechners (RAM, Festplatte etc.) und bei der Datenübertragung zu erkennen und zu korrigieren.
Auf jeden Fall hat sich Crashplan hier einen ziemlichen Kommunikationspatzer geleistet. Auch wenn, wie Matthew richtig anmerkt, bei Existenz eines echten Bugs viel mehr Berichte dieser Art im Internet zu finden sein müßten. Nicht vergessen sollte man auch, das hier nur eines von zwei Backupzielen betroffen war und korrekt gemeldet wurde, dass mehrere Dateien aus dem Backup nicht wiederhergestellt werden konnten.
Hey, danke für den Bericht incl. des ausführlichen Kommentars von wintermute. Ich habe mich jahrelang mich Arhiciverung und Datensicherung auseinander gesetzt (s. “f-copy”) und halte Crashplan vom Konzept her für die beste Lösung für Privatanwender und kl. Betriebe z.Zt., v.A. wegen der Möglichkeit, die Daten übers Internet bei einem “Freund” zu sichern, und sich damit die Kosten (und Risiken) für eine Online-Sicherung zu ersparen.
Interessanterweise erscheint dieser Artikel als 2. Hit beim Googlen ncach Crashplan
Vielen Dank für Deine Rückmeldung.
Ich habe mir CrashPlan in der neusten Version, die nun auch Mac-Metadaten ausreichend unterstützt, zum Ausprobieren vorgemerkt.
Crashplan geht sehr gut!
Ich verwende CrashPlan auch. Es funktioniert. Solange man die GUI nicht ansehen muss, ist gut.