Ist ja noch immer nicht raus...anscheinend.
Ich glaube, da ist gerade zum 20. Mal die Zange abgerutscht.
Man sollte manche Beiträge einfach mal in Ruhe lesen, auf sich wirken lassen. Zangengeburten gehören in unserem Metier leider zur Tagesordnung.
Horst versteht das mit dem Index nicht. Deshalb hole ich für ihn extra mal etwas weiter aus, auch wenn ER nachher wieder behaupten wird, dass er das für $5 im Monat ganz toll direkt in den USA sichert und wir von der OecherWolke ja viel zu teuer sind.
Wer mal Preise vergleiche möchte, kann das gerne hier tun (http://www.online-backup-info.de/bl...kup-anbieter-speichern-in-der-bundesrepublik/). Nach einem ersten Überblick liegen wir weit weit unter den Preisen für in Deutschland tätige Unternehmen, die auch IN Deutschland speichern.
(Die Beschreibung ist nur recht grob und technisch nicht 100%ig korrekt, sollte aber zum Verständnis (auch für Horst
) ausreichen; ich vermische jetzt auch mal "Hardwareblöcke" (auf Festplatten) mit Datenblöcken in CP, für das Verständnis ist der Unterschied irrelevant):Man muss sich eine Datei wie ein Blatt mit Rechenkästchen vorstellen. Eine Datei belegt immer MINDESTENS ein Kästchen (einen Block). Selbst wenn die Information dieser Datei das Kästchen (den Block) gar nicht vollständig ausfüllt.
Eine große Datei belegt tausende dieser Kästchen (Blöcke).
(CrashPlan interessiert die Festplattenblöcke nicht, CrashPlan bildet eigene Blockgrößen und spart auch auf diesem Weg schon viel Platz ein, da nicht die unvollständig gefüllten Blöcke der Festplatten-Blöcke übertragen werden (siehe nachfolgenden Exkurs).
Exkurs:
Wer sich noch an "HFS" (nicht Extended) erinnert, weiss um das Problem, wenn man eine 20GigaByte-Platte mit 64MEGAByte Daten vollständig füllen konnte. HFS konnte nämlich nur 65.536 Blöcke adressieren. Somit konnte auch nur maximal 65.536 Dateien auf der Platte drauf sein.
20GB = 20 * 1024 MB = 20480MB. Dies ergibt geteilt durch 65.536 Blöcke, ein Mindestblockgröße von ca. 312KiloByte. Eine Datei belegte also mindestens 312KB!! Auch wenn Sie nur 1KB groß war.
Mit 65.536 Dateien á 1KB konnte ich somit eine 20GB-Platte füllen, obwohl es nur 64MB an Daten waren! Je größer die Festplatte, desto größer waren die Mindestdateigrößen, man bekam aber keine Datei mehr auf die Platte drauf.
Darum gibt es seit Mac OS 8.1 HFS+. Das kann 4.294.967.295 Blöcke adressieren.
Zurück zu den Dateien:
Ändert man nun in einer großen Datei nur eine kleine Information, werden auch nur wenige Dateiblöcke geändert. Das ist wiederum abhängig vom Dateiformat und Programm. Ein Programm/Dateityp, der selber eine starke Komprimierung durchführt (z. B. JPEG, H264) ändert sehr viele Blöcke ab, eine PSD-Datei nur wenige Blöcke. Ein Problemfeld sind auch ZIP-Dateien. Nehme ich eine gezippte Datei, packe diese aus und die Datei ist dann ca. 500MB-Datei groß und ich ändere nur ein Bit und komprimiere diese wieder als ZIP, sind fast alle Dateiblöcke geändert (gegenüber der alten Datei, die ebenfalls als ZIP vorgelegen hat). Die Kompressionsalgorithmen sorgen da leider für "Chaos". Hier kann die Deduplizierung nur sehr wenig anrichten.
Im Finder wird die Datei als geändert angezeigt und typische Backup-Programme übertragen nun die gesamte Datei erneut auf das Backup-Medium (Wer seine Parallels-VMs mit TimeMachine sichert, wird das Problem kennen, dass in wenigen Tagen sehr große Backup-Platten überlaufen).
CrashPlan nutzt diese Information (Änderung der Datei) aber nur als Hinweis, diese Datei zu prüfen, welche Dateiteile (Blöcke) sich wirklich geändert haben. Damit nicht alle Blöcke der Platte immer wieder verglichen werden müssen, werden Prüfsummen gebildet.
CP bildet eine Prüfsumme pro Datenblock. Diese Prüfsumme wird in einem Index gespeichert, der auch schon mal das ein oder andere GB an Platz beanspruchen kann (je nach Datenmenge). Dieser Index liegt lokal, online und auch auf einer externen Backup-Platte vor (falls genutzt).
Ein aktuelles Beispiel:
Ein Rechner mit ca. 2.5TB an Dateien (ca. 700.000 Stück), die ca. 1.5TB auf dem CP-Server belegen, haben einen Index von ca. 2GB auf dem Rechner.
Ein anderer Rechner, der knapp 8TB Daten speichert (160.000 Stück), diese Daten sich aber nur sehr schlecht komprimieren/deduplizieren lassen (Einsparung nur ca. 5%), da es sich dabei schon um hochkomprimiertes Filmmaterial handelt (welches ja selber schon alle "Tricks" der Datenreduzierung nutzt), hat nur einen Index von ca. 1.1GB.
Die Größe ist natürlich auch abhängig von der Menge an Dateiversionen (in dem Index ist natürlich auch ein komplettes Inhaltsverzeichnis mit den ganzen Versionen enthalten). Auch Informationen über den Backup-Status der Dateien ist in diesem Index enthalten.
(Wenn Horst mal CrashPlan stoppt, den Ordner (/Library/Caches/CrashPlan) löscht und CrashPlan wieder startet, wird er sehen, wie dieser Index neu erstellt wird (anhand der Informationen auf dem Backup-Medium/Server)).
CrashPlan erhält nun vom "Real-Time-File-Watching" (FileSystemEvents auf dem Mac) oder durch den Scan der Verzeichnisse den Hinweis auf noch nicht gesicherte oder geänderte Dateien. CP prüft die Datei bzw. die Blöcke dieser Datei und deren Änderungs- bzw. Backup-Datum. Auch Änderungen an der Position der Datei (anderes oder umbenanntes Verzeichnis) werden erfasst.
Stellt CP fest, dass nun neue bzw. geänderte und noch nicht gesicherte Dateien (bzw. Blöcke) vorhanden sind, wird die Datei in "Häppchen" (Blöcke) zerlegt, zu diesem Block eine Prüfsumme gebildet, die dann mit dem Index abgeglichen wird.
"Ist diese Prüfsumme schon einmal vorhanden?"
"Ist deren Backup-Status in Ordnung?"
"Ist der Pfad identisch?"
Werden die drei Fragen mit "Ja" beantwortet, wird nur ein Eintrag im Inhaltsverzeichnis gemacht, dass der Block "4711" auch für die "neu" gesicherte Datei (die in Pfad X liegt) benötigt wird. Übertragen wird der Block nicht. Diese Info wird im Index vermerkt (lokal und online, bzw. im Index auf der Backup-Platte).
Die Entwickler von CP haben es dabei geschafft, das so hinzubekommen, dass die Blockgrößen nicht zu groß, bzw. zu klein sind, dass die Information ("Prüfsumme", die ja wiederum jeden Block eindeutig kennzeichnet) nicht mehr Platz belegt, als der Inhalt des Blocks selber.
Diese Deduplizierung ist eine sehr feine Sache und wird z. B. auch beim Dateisystem ZFS (das uns Apple leider ja mit 10.6-Server (Beta) erst schmackhaft gemacht hat, um es in der finalen Version wieder zu entfernen.
ZFS führt diese Deduplizierung (auf Wunsch) mit allen Dateiblöcken durch. Je nach Datentyp sind damit immense Einsparungen möglich (man stelle sich einen Server vor, auf dem z. B. 40-50 virtuelle Maschinen laufen, die alle vom gleichen Template erstellt worden sind. Z. B. ein typisches Hostingsystem mit Mail/Webserver/PHP/MySQL (wie man es hundertfach bei zig Providern angeboten bekommt). Diese Grundinstallation von 10GB ist 40-50mal auf dem selben Speicher drauf. ZFS reduziert den Speicherbedarf auf der Platte auf nur ≈ 10-20GB für alle 50 virtuellen Maschinen zusammen! Und die Kompression von ZFS ist noch gar nicht aktiv.). Auf 40-50 * 10GB ≈ 400-500GB werden also nur 10-20GB und das ohne Kompression!!
Man kann das auch sehr schön mal lokal ausprobieren. Einfach mal auf www.oecherwolke.de die Demo beantragen und mal ein paar Dateien sichern (ob online oder lokal auf einer externen Platte). Dann einfach mal mit ein paar größeren Dateien "spielen" und beobachten, inwieweit sich der Speicherplatz des Backups ändert. CrashPlan tut dabei immer so, als ob er die gesamte Datei neu sichert, es werden aber nur die Änderungen/Neuerungen gespeichert/übertragen. Man bekommt dann auch schon einmal Datenübertragungsraten von 300-400Mbit/s angezeigt, auch wenn man nur eine 1Mbit-Sendeleitung hat.
Anbei mal ein Beispiel, für ca. 210GB Daten wird ca. 1h-1.5h gebraucht. Bei einer 10Mbit-Sendeleitung (VDSL 50 Telekom). Diese wird aber gar nicht genutzt (nur an den Stellen, wo die Blöcke wirklich geändert worden sind). Es handelt sich dabei um etwas über 100GB große Datenbanken, von denen ältere Versionen bereits online existieren. Der Rechner ist ein Mac Mini 2Ghz i7. CPU-Auslastung liegt bei diesem Vorgang bei ca. 15%.
Ich habe daneben die Aktivitätsanzeige eingeblendet, dass man erkennt, dass kaum Daten übertragen werden. Die 200GB werden vom System CP als "geändert" gemeldet, somit müssen diese 200GB natürlich komplett auf Änderungen gescannt werden. Das braucht in diesem Fall am Längsten.
Gruß
Sven
- OecherWolke -
