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:

• Optimierung von NFS (siehe NFS Konfiguration)
• Verwendung der Option lateLinks von storeBackup und möglicherweise die Trennung des Löschens von alten Sicherungen vom Backup-Prozess.
  Die Verwendung von storeBackup mit lateLinks ist vergleichbar mit einer asynchronen Client / Server Applikation - oder genauer formuliert wie die Verwendung mehrerer Batch-Läufe auf mehreren Rechnern:
  • Überprüfung der zu sichernden Verzeichnisse, um festzustellen, was sich geändert hat und Sichern (oder Komprimieren) der betroffenen Daten auf den Backup-Server. Die dann noch fehlenden Ordner und Hardlinks werden in einer Datei protokolliert.
  • Nimm diese Protokolldatei und erzeuge ein „normales``, vollständiges Backup.
  • Lösche alte Backups gemäß der Löschregeln.

Die folgenden Performance Messungen zeigen nur die direkte Sicherungszeit (ohne den Aufruf von storeBackupUpdateBackup.pl (wenn nötig)⁹). 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 async¹⁰ 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:

• Der erste Lauf von storeBackup.pl ist kürzer als tar jcf (tar mit Kompression). Es ist einfach zu verstehen, warum: storeBackup.pl verwendet beide Cores des Rechners, wohingegen die Kompression von tar nur einen Core verwendet. Wenn man sich die Zahlen aber näher betrachtet, stellt man fest, dass storeBackup.pl weniger als halb so lange benötigt (42%). Zusätzlich berechnet storeBackup.pl noch sämtliche md5-Summen und muss tausende von Dateien anlegen (siehe auch den Unterschied zwischen tar und cp). Der Zeitunterschied von über 50% für das Erstellen der Sicherung ergibt sich aus zwei Effekten: storeBackup.pl komprimiert nicht alle Dateien (abhängig von der Endung, z.B. werden .bz2 Dateien nicht nochmals komprimiert) und es erkennt Dateien mit demselben Inhalt, für die nur ein Hardlink erzeugt wird (der Grund für die 9.2 anstatt der 9.4 GB).
• Das zweite Backup wurde mit neuem Mounten des Quellverzeichnisse erstellt, so dass der Lesecache nicht gefüllt war (und das Ergebnis verfälschen würde). Man sieht einige Verbesserungen zwischen der 1.19er und 2.0er Version, da bei der internen Parallelisierung von storeBackup.pl Optimierungen erfolgten.
  Beim dritten Lauf sieht man keine Verbesserungen zwischen 1.19 und 2.0, weil das Lesen jetzt aus dem Datei System Cache erfolgt, so dass der limitierende Faktor die Geschwindigkeit des NFS Servers ist - und die ist in beiden Fällen gleich.
• Mit der Option lateLinks kann man eine Verbesserung um den Faktor 4 sehen. Die hier benötigte Zeit hängt massiv von der Zeit für das Lesen des sourceDir (und der Zeit für das Lesen der Meta-Informationen aus dem vorherigen Backup) ab.

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:

• Alles ist jetzt wegen der - durch die synchrone Kommunikation bedingte - höheren Latenz mehr oder weniger langsamer. Wenn nur eine Datei geschrieben wird (wie bei tar, ist der Unterschied zu async geringer; wenn viele Dateien geschrieben werden, ist er größer.
• Wir sehen auch, dass bei Verwendung von lateLinks der Unterschied zwischen sync und async sehr gering ist. Der Grund dafür ist einfach zu verstehen: Es werden nur wenige Dateien über NFS geschrieben, so dass die Latenz nur eine geringe Bedeutung für die Gesamtdauer des Backups hat. Hier ergibt sich dann, dass Backups mit lateLinks und einem sehr schnellen Qullverzeichnis (Cache) jetzt 10 Mal so schnell geworden sind.
• Weil die Latenz mit lateLinks nicht so wichtig für die Durchführung eines Backups ist, habe ich diesen Dateiserver über ein VPN¹¹ über das Internet gemountet. Dies bewirkt eine sehr hohe Latenz und eine Bandbreite von etwa 20KByte/s vom NFS Server und 50KByte/s zum NFS Server (beobachtet auf einem Netz-Monitoring Programm). Mit denselben Randbedingungen wie vorher (gemountet mit async, Quellverzeichnis im Cache, keine Änderungen) erhielt ich eine Beschleunigung des Backups (verglichen mit einem Backup ohne lateLinks) um den Faktor 70.
  Wenn also Deine veränderten oder neuen Dateien (komprimiert) verglichen mit der verfügbaren Bandbreite nicht zu groß sind, kann storeBackup (mit lateLinks auch für Backups über VPNs oder Netzwerke mit hoher Latenz verwendet werden.¹² Natürlich sollte die Option lateCompress in so einem Fall nicht verwendet werden. Ein weitere Vorteil von lateLinks ist beim hier besprochenen Fall, dass die Parallelisierung aufgrund der Tatsache, dass das Lesen des Quellverzeichnisses kaum Interaktionen mit dem NFS Mount benötigt, besser funktioniert.

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.