Der Treff ist zur üblichen Zeit am üblichen Ort
Inhaltsverzeichnis
1. Zusammenfassung des Treffs
Werner
Der Treff war diesmal wieder gut besucht, so etwa 12 Personen.
1.1. storeBackup
Ich habe mich mit Heinz-Josef über sein Datensicherungsprogramm storeBackup.pl unterhalten und einiges zur Konfiguration und Arbeitsweise in Erfahrung gebracht. Ich werde das Programm zum einen auf meinem Server einsetzen und dort regelmäßig per cron ausführen lassen, zum anderen habe ich auf meinem Arbeitsplatzrechner ein kleines Script erstellt und als Icon auf dem Desktop abgelegt. Vom Arbeitsplatz aus wird vor der Datensicherung eine nfs-Verbindung zum Server hergestellt (dort ist die Backup-Festplatte angeschlossen). Nach der Datensicherung wird die nfs-Verbindung wieder aufgehoben.
Erste Erfahrungen mit storeBackup.pl
Mein Server hat noch USB-1.1, d.h. der Datentransfer zur Festplatte ist nicht gerade berauschend. Somit habe ich beim Backup angegeben, dass die Dateien komprimiert gesichert werden sollen. Anschließend habe ich eine weitere Test-Datensicherung gemacht ohne Datei-Komprimierung. Der Zeitunterschied war sehr gering, was darauf zurück zu führen ist, dass der Server mit einem Celeron-Prozessor mit 1 GHz und mit 1GByte RAM ausgerüstet ist. Somit dürfte das Speichern einer vorher komprimierten Datei in der Summe genauso lange dauern wie das Speichern ohne Komprimierung - zumindest bei meiner Hardware-Ausstattung. Bei einer leistungsfähigeren CPU umd mehr RAM wird das wohl anders aussehen. Bei USB-2.0 wird wohl der Unterschied in den Zeiten wesentlich größer sein.
Anders hat es ausgesehen bei dem benötigten Speicherplatz. Ohne Komprimierung wurde 31 GByte belegt, mit Komprimierung jedoch nur 24 GByte. Das ist schon recht ordentlich.
Was das Programm interessant macht, ist die Funktion große Dateien (>> GByte) in kleine Stücke zu teilen. Frage: Wofür soll das gut sein?
Für die Antwort muss man etwas von der Arbeitsweise des Programms wissen. Prinzipiell funktioniert das so:
- Beim ersten Backup werden alle zu sichernden Daten kopiert.
Von diesen Dateien wird eine Prüfsumme erstellt (md5sum)
- bei den folgenden Datensicherungen werden von den Dateien die Prüfsummen erstellt und mit den gespeichern Werten verglichen. Nur wenn dort ein Unterschied besteht, wird die betreffende Datei gesichert. Somit gibt es nur eine geringe Datenmenge für den Backup.
- Nach dem Backup ist zunächst ein Verzeichnis mit nur einigen Daten vorhanden. Will man nun alle Daten vom 1. Backup und 2. Backup zurück sichern, so müsste man zunächst den 1. Backup und dann den 2. Backup (und ggf. weitere) zurück sichern. Das ist das Verfahren bei einem inkrementellen Backup.
Bei storeBackup.pl ist das anders. Nach dem zweiten Backup werden in diesem Backup-Verzeichnis Hardlinks auf die unveränderten (fehlenden) Dateien des ersten Backups erstellt. Das hat den Vorteil, dass jetzt in beiden Backupverzeichnissen jeweils alle Daten zu finden sind obwohl bei der Datensicherung nur die geänderten Dateien gesichert wurden. Der Vorteil liegt darin, dass jetzt bei einer Rücksicherung nur eine Datensicherung zurück gesichert werden muss um alle Dateien eines bestimmten Standes zu erhalten.
Jetzt wird wohl auch zu verstehen sein, was die Teilung großer Dateien in kleine Stücke für einen Nutzen bringt. Als Beispiel möchte ich die virtuelle Disk meiner VirtualBox heran ziehen.
Im Original ist die Datei 7 GByte groß. Wird diese Datei über nfs auf dem Server gesichert dauert das bei meinem Netz mehr als 12 Minuten (~10 MByte/Sek.). Dann kommt noch der Server mit USB-1.1 hinzu. USB-1.1 schafft etwa 1 MByte/Sek. - also Faktor 10, d.h. es dauert mehr als 2 Stunden um diese Datei zu sichern.
storeBackup.pl hat nun die Datei in 1 MByte Stücke zerlegt. Somit gab es 7000 Datei-Stücke zu sichern. Das dauert natürlich auch seine zwei Stunden - beim aller ersten Backup.
Nachdem ich mit der VirtualBox gearbeitet hatte, wurde der Inhalt der 7 GByte Datei verändert. Normalerweise müsste die ganze Datei erneut gesichter werden. Nicht so bei storeBackup.pl, denn, wie oben erklärt, werden von den gesicherten Dateien die Prüfsummen erstellt und gesichert, so auch von den 1 MByte Stücken der großen 7 GByte Datei. Beim zweiten Backup wurden jetzt nur die veränderten 1-MByte Dateien gesichert, deren Prüfsumme sich geändert hatte. In meinem Beispiel waren das 374 Dateien, also 374 MByte an Daten. Bei meiner Netzwerk/Server-Konfiguration ergibt das einen Zeitbedarf von ca. 6-7 Minuten. Und das ist ein ganz anderer Wert als die 120 Minuten wenn die große Datei gesichert wird.
Anmerkung:
Beim ersten Backup werden alle Dateien gesichert. Falls Dateien doppelt vorhanden sind, werden die Duplikate erkannt und per Hard Link verlinkt.- Das gleiche gilt für die großen Dateien, die in kleine Blöcke zerhackt werden: Wenn ein identischer Block innerhalb einer Datei gefunden wird, wird er auch verlinkt. Wenn ein identischer Block in einer anderen Datei gefunden wird, auch.
Wenn also beim ersten Backup viele GByte vorhanden sind, dann dauert das auch seine Zeit, aber ab dem 2. Backup geht's ab wie Schmitts' Katze...
Mehr Infos und die aktuelle Version des Programms gibt es unter http://freshmeat.net/projects/storebackup/
1.2. dvd-slideshow
Weiterhin hat mich Herrmann zu dem Programm dvd-slideshow angesprochen. Er will von digitalen Bildern DVDs mit Diaschauen erstellen. Dazu hatte ich ihm ein von mir geschriebenes Shell-Script gegeben. Mit diesem Script hatte er einige Anwendungsprobleme die ich Ihm jedoch beseitigen konnte.
Herrmann ist sehr daran interessiert seine Bilder als DIA-Schau auf DVD zu bringen. Ich werde wahrscheinlich am zweiten Oktober-Treff dazu einen Vortrag halten. Dies ist aber noch von einigen persönlichen umständen abhängig. Wann es letztendlich statt findet wird dann hier in HuLUG-aktuell bekannt gegeben.