FAQ, Frequently asked Questions

1  Ich will keine Dateien im Backup komprimieren
2  Wo ist die graphische Oberfläche (GUI)?
3  Ich brauche dieses lateLinks nicht
4  Erstellen eines Backups über ssh (nicht NFS) auf einen entfernten Server
5  Ich will dieses blocked file und will es für alle Dateien größer als 50 MB nutzen
6  Wie mache ich ein vollständiges Backup meines GNU/Linux Rechners?
7  Wie installiere ich storeBackup auf einem (Synology) NAS?
8  storeBackup auf Raspberry Pi
9  Können storeBackup die Hardlinks ausgehen?

*  *  *  *  *

FAQ 1  Ich will keine Dateien im Backup komprimieren

Ich will keine Dateien im Backup komprimieren. Wie kann ich das konfigurieren?

Beim Konfigurieren von storeBackup.pl die Option exceptSuffix auf '.*' setzen. Das ist das Suchmuster für „passt auf alles``.

*  *  *  *  *

FAQ 2  Wo ist die graphische Oberfläche (GUI)?

Es gibt einige Gründe, warum storeBackup über die Kommandozeile anzusprechen ist:

• Wenn möglich, solltest Du Deine Backup regelmäßig mit einem Automatismus durchführen, z.B. mit cron.
• Falls storeBackup auf einem Server läuft, gibt es dort wahrscheinlich keine GUI. Denke auch an die Abhängigkeiten einer Oberfläche zu unterschiedlichen Versionen der GUI-Bibliotheken.
• Wenn Du Daten auf ein irgendwie korruptes System spielen willst, wird die GUI (falls eine lief) eventuell nicht mehr starten. Dann ist es gut, ein Tool zu haben, dass von einer Kommandozeile oder von einer Recovery-CD verwendet werden kann. Es ist auch sinnvoll, storeBackup selbst Teil des Backups sein zu lassen (siehe Beispiel 2).
• Wenn Du nur einige Dateien aus dem Backup holen willst, kannst Du einen beliebigen Browser irgendeines Betriebssystems nutzen. Das ist eine Art GUI und das einzige, was Du (neu) lernen musst, ist der Pfad zum Backup.
• Wenn Du eine separate GUI schreiben willst, die storeBackup aufruft, unterstütze ich gern!

*  *  *  *  *

FAQ 3  Ich brauche dieses lateLinks nicht

Ich will einfach nur ein Backup auf ein externes USB Laufwerk machen und will die Option lateLinks nicht verwenden. Wie mache ich das?

Du musst Dich überhaupt nicht mit dieser Option (oder mit storeBackupUpdateBackup.pl), die für höhere Ansprüche gedacht ist, auseinandersetzen, wenn Du lateLinks nicht verwenden willst. Sieh Dir Beispiel 1 an.

*  *  *  *  *

FAQ 4  Erstellen eines Backups über ssh (nicht NFS) auf einen entfernten Server

Mit GNU/Linux ist es ebenfalls möglich, ein Backup über eine SSH-Verbindung laufen zu lassen. Das hat den Vorteil, dass kein (eventuell) zusätzliches Netzwerk-Dateisystem (wie bei NFS) konfiguriert werden muss.

Anstelle eines NFS-Mounts auf das Zielverzeichnis wird das Programm sshfs verwendet. Es ist für die meisten Distributionen verfügbar, kann jedoch auch von http://fuse.sourceforge.net/sshfs.html heruntergeladen werden.

Das Kommando, das entfernte Verzeichnis /var/backup auf dem Rechner chronos als User „backup`` nach /mnt/target zu mounten ist:

# sshfs backup@chronos:/var/backup /mnt/target

storeBackup.pl muss jetzt nur noch so konfiguriert werden, dass das Backup nach /mnt/target geschrieben wird. Nach dem Backup kann das Zielverzeichnis mit fusermount -u /mnt/target ausgehängt werden.

BESCHLEUNIGUNG EINES REMOTE-BACKUPS üBER SSHFS

sshfs nutzt eine eigene Netzwerkanfrage für jeden individuellen Hardlink, der gesetzt werden muss, und für jede einzelne Datei, die gelöscht werden muss. Da die Latenz (Dauer) für jede Aktion über das Netzwerk generell um einiges größer ist als für eine lokale, kann ein entferntes (Remote-) Backup ziemlich langsam sein, auch wenn die Bandbreite groß genug ist.

Aus diesem Grund empfiehlt es sich, für derartige Anwendungen von storeBackup die Optionen lateLinks und doNotDelete zu verwenden. Ihre Verwendung ermöglicht es, das Erzeugen von Hardlinks und das (spätere) Löschen lokal auf der entfernten Maschine durchzuführen. Die Verwendung von lateLinks resultiert mit sshfs generell in einer Verbesserung der Performance um den Faktor 10 bis 75, abhängig von der Anzahl der Änderungen und der Latenz des Netzwerks.

Das Vorgehen ist allgemein:

1. Mounte das Remote-System:

   # sshfs backup@chronos:/var/backup /mnt/target
   

2. Starte das Backup:

   # storeBackup.pl --backupDir /mnt/target --lateLinks \
        --doNotDelete [other options]
   

3. Nimm den Mount wieder weg:

   # fusermount -u /mnt/target
   

4. Setze die Hardlinks auf dem Remote-System:

   # ssh -T -l backup ebox.rath.org \
       'storeBackupUpdateBackup.pl --backupDir /var/backup'
   

5. Lösche alte Backups auf dem Remote-System:

   # ssh -T -l backup chronos \
       "storeBackupDel.pl --backupDir /var/backup [other options]"
   

Beachte, dass dieses Vorgehen erfordert, dass storeBackup auch auf dem Remote-System installiert ist.

*  *  *  *  *

FAQ 5  Ich will dieses blocked file und will es für alle Dateien größer als 50 MB nutzen

Um das gewünschte Resultat zu bekommen, setze einfach:

checkBlocksSuffix = .*
checkBlocksMinSize = 50M

Diese Konfiguration wird Blocked Files für alle Dateien mit einer Größe von mindestens 50 MB verwenden. Wenn Du das ab einer anderen Größe willst, z.B. 800KB, ändere den Werte von checkBlocksMinSize auf 800k.

Erklärung für Experten: storeBackup.pl erzeugt von der Konfiguration oben folgende interne Regel:

'$file =~ /.*$/' and '$size >= 52428800'

Du kannst daher auch direkt die folgende Regel definieren:

'$size >= &::SIZE("50M")'

um dasselbe Resultat zu bekommen.

*  *  *  *  *

FAQ 6  Wie mache ich ein vollständiges Backup meines GNU/Linux Rechners?

Erzeuge als Erstes eine Konfigurationsdatei:

storeBackup.pl -g completeLinux.conf

Öffne die Konfigurationsdatei mit einem Editor Deiner Wahl und editiere die folgenden Optionen:

sourceDir = /

Setze sourceDir auf /, so dass das gesamte Dateisystem gesichert wird.

backupDir=/media/drive

Hier nehme ich an, dass die angeschlossene Festplatte für das Backup unter dem Pfad /media/drive angebunden ist. Dies muss angepasst werden, wenn sie woanders gemountet ist. Die Backups können natürlich z.B. alternativ auf einem NFS-Mount liegen. Falls Du diese Konfiguration hast, findest Du Erläuterungen zu NFS unter Konfiguration von NFS. Wenn Du das Backup über NFS machst, solltest Du auch Verwendung der Option lateLinks lesen.

Als nächstes sind die Verzeichnisse anzugeben, die nicht gesichert werden sollen. Wir müssen hier backupDir angeben, um eine Rekursion zu vermeiden.

exceptDirs= tmp var/tmp proc sys media

Füge andere Verzeichnisse, die Du nicht sichern willst (z.B. über NFS gemountete Home-Verzeichnisse), an diese Liste.

Nehmen wir weiterhin an, Du willst die Inhalte aller anderen Verzeichnisse, die tmp oder temp (groß oder klein geschrieben) heißen und sich irgendwo im Dateisystem befinden, ausschließen. Füge dann hinzu:

exceptRule= '$file =~ m#/te?mp/#i'

Um Cache-Dateien auzuschließen, werden alle Verzeichnisse mit cache im Namen (groß oder klein geschrieben) hinzugefügt. Ändere die Zeile von oben in:

exceptRule= '$file =~ m#/te?mp/#i' or '$file =~ m#cache.*/#i'

Aber jetzt gibt es das Risiko, dass vielleicht einige wichtige Dateien nicht gesichert werden, weil sie in einem Verzeichnis mit Namen /tmp/, /temp/ oder in einem Verzeichnis mit z.B. Cache im Namen liegen.
Aus diesem Grunde schreiben wir die Namen aller aufgrund dieser Regel ausgeschlossenen Dateien in eine Datei, die wir nach Durchführung des Backups überprüfen können:

writeExcludeLog=yes

Jetzt wird es in jedem Backup eine Datei .storeBackup.notSaved.bz2 geben, in der die ausgeschlossenen Dateien gelistet sind.
Um alle Dateitypen zu kopieren (insbesondere Block- und zeichenorientierte Devices in /dev), setzte:

cpIsGnu=yes

Um ein vollständiges Backup durchzuführen, muss auch der Boot Sektor gespeichert werden. Das folgende Skript geht davon aus, dass dieser auf dem Laufwerk sda gespeichert ist. Dies muss eventuell an die Anforderungen Deines Systems angepasst werden. Erzeuge das Verzeichnis /backup und speichere das folgende Skript pre.sh dort:

#! /bin/sh

rm -f /backup/MBR.prior
mv /backup/MBR.copy /backup/MBR.prior
# copy the boot loader
dd if=/dev/sda of=/backup/MBR.copy bs=512 count=1 > /dev/null 2>&1

# copy back with:
# dd if=/backup/MBR.copy of=/dev/sda bs=512 count=1

Setze die Rechte:

chmod 755 /backup/pre.sh

Setze precommand in der Konfigurationsdatei um das Skript aufzurufen:

precommand = /backup/pre.sh

Um während des Backup zu sehen, dass etwas passiert, setzte:

progressReport = 2000
printDepth = yes

Schau Dir die keep*-Optionen an und setze sie auf für Dich sinnvolle Werte. Außerdem solltest Du logFile auf einen für Dich passenden Werte setzen - überprüfe ebenso die anderen Einstellmöglichkeiten.

Wie immer wird das erste Backup einige Zeit brauchen, da für alle Dateien md5-Summen berechnet werden müssen - insbesondere aber wegen der Kompression der Dateien. Das nächste Backup wird sehr viel schneller sein.
Nach der Durchführung des Backups solltest Du kontrollieren, welche Dateien aufgrund der Option exceptRule nicht im Backup sind.

*  *  *  *  *

FAQ 7  Wie installiere ich storeBackup auf einem (Synology) NAS?

Folgendes Verfahren hat zum Erfolg geführt.

Vorbereitung:

• aktiviere ssh auf dem NAS
• installiere den Paketmanager (http://www.synology-wiki.de/index.php/IPKG)

Installation:

• Installation von storeBackup in ein beliebiges Verzeichnis, z.B.: /volume1/homes/admin/storeBackup. (/volume1 ist der Mountpoint der Festplatte bzw. der nutzbaren Partition; unter homes liegen die Home-Verzeichnisse der Userkonten, auch das vom admin)
• als admin einloggen: ssh admin@ip-des-nas
• Sicherstellen, dass das x-Bit gesetzt ist:
  # chmod u+x /volume1/homes/admin/storeBackup/bin/*
# chmod u+x /volume1/homes/admin/storeBackup/lib/stbuMd5*
• Nach /usr/bin verlinken:
  # ln -s /volume1/homes/admin/storeBackup/bin/* /usr/bin
• md5deep installieren:
  # ipkg install md5deep
• md5deep als md5sum nach /usr/bin verlinken:
  # ln -s /opt/bin/md5deep /usr/bin/md5sum

Damit sollte storeBackup lauffähig sein.

*  *  *  *  *

FAQ 8  storeBackup auf Raspberry Pi

Mir wurde berichtet, dass storeBackup auf dem Raspberry Pi (raspbmc und Raspbian GNU/Linux 7) läuft. Man sollte auf Folgendes achten:

• setze noCompress auf 1 (mehr als ein Komprimier-Job macht keinen Sinn).
• Verwende Option saveRAM und stell sicher, dass in Deinem temporären Verzeichnis genügend Platz ist. Es scheint am besten, ein eigenes Directory für temporäre Dateien anzulegen und storeBackup.pl über die Option tmpdir darauf zu verweisen. Zumindest mit raspbmc scheint der temporäre Bereich (/tmp) so klein zu sein, dass es ansonsten auch ohne Option saveRAM (bei der einige Hash-Tabellen ausgelagert werden) bei Aufruf von storeBackup.pl einen Crash mit seltsamen Fehlermeldungen gibt.

Es ist wichtig, Swapping zu vermeiden, weil der Raspberry Pi auf irgend etwas sehr langsames (z.B. eine sdcard) auslagert. Natürlich hängt eventuelles Swapping davon ab, welchen RAM-Ausbau Dein Raspberry Pi hat und was für Daten Du sicherst.

Wie immer ist das erst Backup langsam (sehr langsam), aber das nächste ist (ziemlich) schnell (natürlich abhängig von der langsamen CPU (verglichen mit heute üblicher PCs) und dem langsamen Speicher, in den geschrieben wird.

*  *  *  *  *

FAQ 9  Können storeBackup die Hardlinks ausgehen?

Man benötigt für jede Datei mindestens einen Inode, daher spart das Hardlinken von Null-Byte-Dateien zumindest viele Inodes. Dieses kann keine Auswirkungen haben (wenn im Dateisystem genügend statisch reserviert werden (ext)) oder tatsächlich Platz sparen, wenn das Dateisystem sie dynamisch alloziert (reiserfs, btrfs) oder wenn Du ansonsten mit einem ext-Dateisystem die statisch allozierte Anzahl von Inodes erreichst.

Einen Hardlink zu erzeugen sollte auch schneller sein als einen neuen Inode zu erzeugen.

Für storeBackup ist die Verwaltung von Hardlinks kein Problem. Es versucht, einen Hardlink zu erzeugen und, falls das nicht erfolgreich ist, wird eine neue Datei erzeugt und anschließend gegen diese verlinkt. Die Grenze für die Anzahl der Hardlinks zu erreichen bedeutet lediglich eine neue identische Datei zu erzeugen. Aufgrund dieses einfachen Algorithmus muss sich storeBackup nicht um die Anzahl der Hardlinks, die ein Dateisystem unterstützt, kümmern. Dieses Verhalten unterschiedet sich von dem typischer Unix Tools wie cp, tar oder rsync. Wenn Du mit ihnen ein Verzeichnis mit vielen Hardlinks auf ein Dateisystem kopierst, das nicht genügend Hardlinks unterstützt, bekommst Du eine Fehlermeldung (siehe auch die Erläuterung zum Program linkToDirs.pl, das Teil der storeBackup-Tools ist und dieses Problem auf die oben beschriebene Art und Weise umgeht).

Btrfs würde ich momentan (2014) nicht für Backups verwenden, weil ich es nicht für stabil genug halte. Aber nichtsdestotrotz habe ich einige Tests gemacht und das Verhalten bezüglich Hardlinks scheint sehr anders als das anderer Dateisysteme zu sein. Ich erreichte die Hardlink-Grenze - mit allen Dateien in einem Verzeichnis - es war aber möglich, weitere Hardlinks auf diese Dateien aus einem anderen Verzeichnis zu erzeugen. Aber wie auch immer - aufgrund von storeBackups simplen Algorithmus ist es auch mit btrfs effizient.

Zusammengefasst denke ich, dass es keinen Grund gibt, Null-Byte-Dateien nicht per Hardlink zu verbinden.