next up previous contents
Nächste Seite: Beispiellauf Aufwärts: Wie storeBackup arbeitet Vorherige Seite: Reduzierung des Plattenplatzes   Inhalt


Performance

Die oben beschriebene Methode Plattenplatz zu sparen geht davon aus, dass vor der Sicherung einer Datei im existierenden Backup nach identischen Dateien gesucht wird. Diese Suche erfolgt im vorhergehenden Backup sowie im neu erzeugten Backup selbst. Natürlich wäre es nicht sinnvoll, jede zu sichernde Datei direkt mit jeder im Backup zu vergleichen. Daher werden die md5-Summen der Dateien der vorherigen Sicherungen über eine Hash Tabelle mit der md5 Summe der zu sichernden Datei verglichen.

Das Berechnen einer md5-Summe geht schnell, aber bei großen Datenmengen ist das immer noch nicht schnell genug. Aus diesem Grund überprüft storeBackup initial, ob eine Datei seit dem letzten Backup unverändert geblieben ist (Pfad + Dateiname, ctime, mtime müssen gleich sein). Wenn das der Fall ist, wird die md5-Summe von der letzten Sicherung übernommen und der Hardlink gesetzt. Wenn dieser initale Check einen Unterschied liefert, wird die md5-Summe der Datei berechnet und im Backup nachgesehen, ob schon einen Datei mit derselben Prüfsumme existiert. (Der Vergleich mit mehreren Backup-Serien verwendet einen erweiterten, aber ähnlich performanten Algorithmus.) Bei diesem Ansatz müssen nur wenige md5-Summen für ein (wiederholtes) Backup berechnet werden. Wenn Du storeBackup tunen willst, insbesondere beim Schreiben über NFS, sind zwei Möglichkeiten zu erwägen:

Die folgenden Performance Messungen zeigen nur die direkte Sicherungszeit (ohne den Aufruf von storeBackupUpdateBackup.pl (wenn nötig)9). Die Läufe wurden mit Beta Versionen von storeBackup 2.0 durchgeführt.
Zunächst einige Hintergrundinformationen zu den folgenden Werten: Das Backup lief auf einem Athlon X2, 2.3GHz, 4GB RAM. Das Netzwerk hatte 100 MBit/s, storeBackup wurde mit Standard-Parametern verwendet. Die Einheiten der Messwerte sind Stunden:Minuten:Sekunden oder Minuten:Sekunden. Die Größe von sourceDir war 12GB, die daraus resultierende Größe des Backups mit storeBackup waren 9.2 GB. Die Sicherungen wurden mit 4769 Verzeichnissen und 38499 Dateien durchgeführt. StoreBackup.pl linkte 5038 Dateien intern; diese waren demnach doppelt vorhanden. Die Datenquelle waren meine eigenen Dateien und der „Desktop`` von meinem Windows XP Laptop, also „reale`` Daten.

Die erste Tabelle zeigt die Zeit für das Kopieren der Daten mit Standardprogrammen auf den NFS Server. Der NFS Server war mit der Option async10 gemountet. Dieses ist nicht die Standardkonfiguration, sondern eine Performance-Optimierung.

Kommando Dauer Backup-Größe
cp -a 28:46 12 GB
tar jcf 01:58:20 9.4 GB
tar cf 21:06 12 GB


Die Ergebnisse sind wie erwartet: tar mit Kompression ist viel langsamer als die anderen, und cp ist langsamer als tar, da es viele Dateien anlegen muss. Eine Zahl überrascht: Die Größe des Backups mit tar ist 9.4 GB, die des Backups mit storeBackup.pl dagegen nur 9.2 GB. Der Grund dafür liegt in den 5038 intern verlinkten Dateien - die Duplikate werden bei storeBackup nur einmal gespeichert.

Was wir hier nicht sehen, ist der Effekt des Inhaltsvergleichs. Er bedeutet aber einen großen Unterschied bezüglich der Performance und insbesondere im benötigten Plattenplatz. Wenn sich der Zeitstempel einer Datei ändert, werden traditionelle Backupsysteme diese Datei(en) auch in einem inkrementellen Backup nochmals speichern - storeBackup wird nur einen Hardlink erstellen.

Nun lassen wir storeBackup.pl auf denselben Daten laufen. Der NFS Server ist nach wie vor mit async gemountet. Es gab keine Änderungen in sourceDir zwischen dem zweiten und dritten Backup.

storeBackup 1.19, Standard 2.0, Standard 2.0, lateLinks mount with async
1. Backup 49:51 100% 49:20 99% 31:14 63%  
2. Backup 02:45 100% 02:25 88% 00:42 25% Dateisystem Cache geleert
3. Backup 01:51 100% 01:54 100% 00:26 23% Dateisystem Cache gefüllt


Wir sehen Folgendes:

Nun das Ganze ohne „Tricks`` wie async Mounts über NFS:

Kommando Dauer Backup-Größe
cp -a 37:51 12 GB
tar jcf 02:02:01 9.4 GB
tar cf 25:05 12 GB


storeBackup 1.19, Standard 2.0, Standard 2.0, lateLinks mount with sync
1. Backup 53:35 100% 49:20 100% 38:53 63%  
2. Backup 05:36 100% 05:24 96% 00:43 13% Dateisystem Cache geleert
3. Backup 05:10 100% 04:54 95% 00:27 9% Dateisystem Cache gefüllt


Wir sehen jetzt Folgendes:

Fazit: Wenn man über NFS mountet, kann man storeBackup mit der Option lateLinks massiv beschleunigen. Zur Konfiguration siehe Kapitel 7.6.

Auch die Verwendung von „blocked files`` erhöht die Performance massiv, da in den Fällen, in denen sie sinnvollerweise verwendet werden, nur ein kleiner Prozentsatz der Dateien kopiert oder komprimiert werden muss. Siehe hierzu auch die Beschreibung über blocked files über den Einfluss dieser Option auf die Performance und den benötigten Plattenplatz.


next up previous contents
Nächste Seite: Beispiellauf Aufwärts: Wie storeBackup arbeitet Vorherige Seite: Reduzierung des Plattenplatzes   Inhalt
Heinz-Josef Claes 2014-04-20