ein paar Tips für alle, die zur Sicherung im Netzwerk BackupPC einsetzen:
Reduktion von vielen kleinen Dateien
Es kostet bei BackupPC vor allem sehr viel Performance, wenn eine grosse Zahl von Dateien gesichert wird. Ich habe hier z. B. mehrere Systeme die ca. 4 Mio kleinste Dateien haben. Die Sicherung dauert aufgrund dieser Eigenschaft und zusätzlicher anderer Faktoren bis zu 30 Stunden.
BackupPC(rsync) schaut bei der Sicherung jede Datei an das braucht bei mehreren Millionen Dateien seine Zeit. Zusätzlich belastet es den BackupPC-Server, der bei der Rotation und Löschung von Backupsätzen auch wieder prüfen muss, welch Dateien denn nun alle zu löschen sind. Umso mehr Dateien es insgesamt sind, umso aufwändiger ist dieses Bereinigen.
Die eigene Lösung war hier, die Verzeichnisse lokal auf den Systemen zu sichern(tar+bzip2), die Originaldaten von der BackupPC-Sicherung auszuschliessen und nur die gepackten + komprimierten Dateien dann zu sichern. BZIP2 deswegen, weil das auch bei maximaler Kompression recht wenig RAM benötigt im Vergleich zu xz. Zur Verminderung der Backup-I/O auf den Servern wird alle 2 Monate ein Vollbackup durchgeführt und sonst wöchentlich(wöchentliches Backup reicht bei den vorliegenden Daten) ein Differenzbackup, das jeweils überschrieben wird.
Damit wird die Arbeit vom BackupPC-Server auf den zu sichernenden Server verlagert und der Sicherungsdurchsatz steigt so enorm.
Zwischenspeicherung der Prüfsummen
BackupPC wendet bei der Sicherung auch Deduplizierung an. D. h. es werden bei der Sicherung Dateien, die mehrfach und identisch im Backup-Pool vorhanden sind nur einmal gespeichert. Die Ersparnis hierbei ist enorm. Hier ein Beispiel, bei dem der Speicherplatzverbrauch der Dateien und des Platzes mit Duplikaten mal gezählt wurde:
Code: Alles auswählen
Processed files: 231,071,765
Files with duplicates: 21,824,018
Duplicate files: 230,981,091
Saved Space due to hardlinking: 12,826,217,232,475
Used Space on disk: 4,321,123,213,244
Doch diese Deduplizierung kostet. Im Fall von BackupPC 3 werden dabei immer wieder die Prüfsummen im Backup-Pool neu berechnet und bei den Backups mit dem gegen geprüft, was vom zu sichernden Server kommt. D. h. das erzeugt eine grosse Menge I/O-Operationen zusätzlich.
Man kann jedoch BackupPC auch anweisen die Prüfsummen zu cachen. Lt. diversen Fundstellen wird diese Einstellung dann bei der übernächsten Vollsicherung wirksam.
Dazu muss in der allgemeinen Konfiguration bei RsyncRestoreArgs und RsyncArgs die Option --checksum-seed=32761 hinzugefügt werden. Diese Option soll aber auch viel RAM zusätzlich benötigen. In welcher Grössenordnung, kann ich selbst nicht sagen. Ich würde mal unqualifiziert ins Blaue raten, dass es bei mindestens 1 GB pro 50 Mio Dateien liegt.
Umstieg auf BackupPC 4
Bei BackupPC 4, was wohl um einiges performanter ist, aber noch nicht in den offiziellen Debian-Paketquellen verfügbar, gibt es die Einstellung --checksum-seed=32761 nicht mehr. Hier werden die Checksummen wohl grundsätzlich nur von den zu sichernden Servern erstellt und nicht mehr auf dem Server. Insofern ist BackupPC 4 auch grundsätzlich ein Tip, wenn man mehr aus dem Server rausholen möchte.
Im Übrigen ist BackupPC in vielerlei Hinsicht ähnlich, wenn auch unter der Haube viel verändert wurde. Das Webinterface ist mal grundsätzlich gleich hässlich und funktional im CGI-Modus geblieben, was aber im Betrieb die Basisbedürfnisse durchaus gut befriedigt. Dass da jetzt ein hübscheres CSS dahinter ist, ist nur eine kleine visuelle Änderung. Insofern erfordert der Umstieg auf die neue Version kaum die intensive Beschäftigung mit der Software.
Kommt noch. Die Liste(inum,size,link-count) der doppelten Dateien auf dem einen System ist schon 16 GB gross...
