Backup HowTo

Seit langem mache ich mir gedanken, wie man auf eine sinnvolle Weise Desktop, Server oder auch nur bestimmte Bereiche der Festplatte sichern kann. Schon lange hätte ich ein System einsetzten sollen, aber wenn man erst alle Tücken und Kleinigkeiten listet, auf die mach achten muß, verliert man die Lust, etwas zu programmieren.

Da nun aber endgültig Schluß mit dem Problem beim Datengau sein muß und immer mehr Systeme und Daten zusammenkommen, die gesichert werden müßten, habe ich mich nun dazu durchgerungen etwas zu tun. Nachdem die c't in diesem Jahr ein paar Artikel zu diesem Thema geschrieben hat, die meine Überlegungn vorantrieben, habe ich nun folgendes Szenario für „das Beste“ erachtet.

Ein Backup ist nur dann ein gutes Backup, wenn man die Daten in jedem Fall nach einem Problem wieder verfügbar machen kann. Backups müssen meiner Meinung nach auf Medien gespeichter werden, die nicht im System liegen - also eingebaute Festplatten usw. - und sollten sogar die Räumlichkeiten verlassen - also z.B. aus dem Büro oder dem Hosting-Center des Webservers.

Dabei haben sich natürlich über die Jahre und noch heute die Bandspeicher als bestes Medium für Langzeitarchivierung bewährt. Da die Kosten zu hoch für Privatleute und kleine Firmen sind, weichen viele auf die DVD aus. Das ist aber große Vorsicht geboten, da Brenner und Rohling zueinander passen müssen. Andernfalls kann es leicht passieren, daß die gebrannten Daten gleich nach dem Vorgang unlesbar oder zumindest teilweise defekt sind.

Der Einfachheit halber machen viele ihre Backups auch nur auf Festplatten - intern oder extern spielt dabei eine nur untergeordnete Rolle. Das Problem ist, daß sie anfälliger gegenüber Umwelteinflüsse sind als manch anderes Medium. Besonders problematisch ist die Tatsache, daß die Geräte oft dauerhaft(er) direkt mit einem Computersystem verbunden sind. So kann sich zum Beispiel Überspannung auch darauf auswirken.

Ein wesendlicher Vorteil der Festplattenbackups ist aber, daß sie schnell erstellt und schnell verfügbar sind.

1. Daten sollen dauerhaft gesichert werden.
2. Daten sollen auf DVD / CD gebrannt werden
3. Daten sollen über einen gewissen Zeitraum einfach verfügbar sein
4. Daten sollen verschlüsselt auf die DVD / CD gespeichert werden
5. Daten sollen auch bei geringfügiger Beschädigung der DVD / CD wieder hergestellt werden können
6. Geringe auf DVD / CD zu speichernde Datenmenge
7. Einfaches rückspielen der Backups

Ich bin froh, daß ich über zwei Programme gestolpert bin, die für meine Zwecke sehr gut geeignet sind. Natürlich haben beide ihre eigenheiten und man muß sich mit gewissen einschränkungen abfinden. Dennoch ist es weniger Zeitraubend, als yabp ¹⁾ zu schreiben.

Für das vorhalten der Daten für eine gewisse Zeit und deren einfachen Zugriff, ist rsync predestiniert. In unserem Fall wird dirvish benutzt, welches rsync benutzt. Für die dauerhafte Sicherung der Daten wird backup2l eingesetzt, welches standardmäßig tar benutzt. Allerdings lassen sich sogenannte „Treiber““ einsetzten - das sind Programme, die backup2l nutzt, um die Sicherungsarbeit zu vollführen. Genaueres lest bitte in der Manpage oder der Konfigurationsdatei.

dirvish speichert die zu sichernden Verzeichnisse, lokal oder über Netzwerk, in Backupverzeichnisse. Jede weitere Sicherung prüft die neuen zu sichernden Daten mit der letzten Sicherung und überträgt nur die geänderten Daten. Diese werden aber in ein neues Verzeichnis gelegt. Alle Daten, die sich nicht geändert haben, werden mittels sog. Hardlinks ²⁾ platzsparend gespeichert. Diese Prozedur wird beliebig oft wiederholt.

backup2l prüft anschließend das neuste dirvish-Backup und speichert inkrementell die Daten. Die Rotation kann ebenso wie bei dirvish vom Nutzer eingestellt werden.

Das Inkrementelle Backup wird am Ende auf eine DVD / CD gebrannt.

Natürlich ist hier nur die Funktionsweise umrissen. Der genaue Vorgang und die Einstellungen werden im folgenden genauer besprochen.

Der oben beschrieben Ablauf läßt dich am Besten anhand eines Bildes verdeutlichen:

Nachdem nun klar ist, wie das System funktionieren soll, ist es Zeit, die Konfiguration vorzunehmen. Dazu betrachten wir erst die Konfiguration von dirvish und anschließend jene von backup2l.

Das Programm hat eine etwas eigenwillige Betrachtungsweise der Backupstrukturen. Zu Beginn definiert man ein globales Backupverzeichnis - es nennt sich „Bank“. In dieser „Bank“ kann man dann sogenannte „Tresore“ anlegen, in welche die regelmäßigen Backups angelegt werden.

Eine Bank soll unterschiedlichen Speicherorten entsprechen. Es ist dadurch möglich, einen Tresor von einer Bank in eine andere zu verschieben, ohne die Konfiguration zu verändern.

Banks have nothing to do with clients, really. They are just storage areas on the backup machine where vaults can be kept. They could represent separate hard drives, partitions on the same hard drive, or subdirectories of one partition. They just need to be the area where some of the vaults (and only vaults) are stored.

Ein Tresor muß einen eindeutigen Namen haben (Grund siehe oben). In der englichen Anleitung wird es folgendermaßen beschrieben:

Vault names should be globally unique because they aren't qualified by the name of the bank they happen to be in. You can move a vault from one bank to another - perhaps because the partition filled up - and dirvish will continue to find the vault. For example, don't call a vault 'home', call it 'myhost-home' or similar.

Ein sehr interessantes Feature ist die Nutzung von branches. Die volle Wirkung entfalten sie, wenn man mehrere Clients mit mehrheitlich identischen Daten besitzt. Hier wäre zum Beispiel das /usr-Verzeichnis zweier Debian PCs zu nennen. Dabei referenzieren beide Sicherungen auf die Datenbasis eines Clients.

Wahrscheinlich muß man dirvish nachinstallieren:

apt-get install dirvish

Auf allen zu sichernden Clients muß rsync installiert sein:

apt-get install rsync

Anlegen zweier Banken und je eines Tresors:

mkdir /path/to/backups/bank1
mkdir /path/to/backups/bank1/home
mkdir /path/to/backups/bank2
mkdir /path/to/backups/bank2/client1-home

Die Konfiguration von dirvish besteht aus zwei Konfigurationsdateien. Die globale Datei /etc/dirvish/master.conf enthält eine oder mehrere Banken und die Tresore. Letztere sollten möglichst aussagekräftige Namen besitzten, die aber nicht mit den zu sichernden Verzeichnissen identisch sein müssen. Zusätzlich können Client-Verzeichnisse angegeben werden, die auf keinem der Clients gesichert werden sollen.

Die zweite Konfigurationsdatei liegt immer in den jeweiligen Tresoren im Unterverzeichnis dirvish/default.conf. Diese hat mindestens den zu sichernden Rechner und was dort zu sichern ist zum Inhalt. Desweiteren können spezifische Konfigurationen angegeben, die die der master.conf ergänzen oder überschreiben.

# Beispiel einer dirvish master.conf
# zwei Banken und je einen Tresor
bank:
     /path/to/backups/bank1
     /path/to/backups/bank2
 
xdev: 1
index: gzip
log: gzip
image-default: %Y%m%d_%H%M
checksum: 1
summary: long
# speed-limit: 1000 #Mbps
 
exclude:
     lost+found/
     core
    .nfs*
 
Runall:
     client1-home
     client2-home
 
expire-default: +15 days
#expire-rule:
# MIN HR    DOM MON       DOW  STRFTIME_FMT
#*   *     *   *         1    +3 months

Beschreibung der Zeilen:

1. bank: Backupziele der Banken
2. xdev: Verfolge keine Links, die auf andere Devices zeigen
3. index: Format der Datei, in der alle Dateien des Backups geschreiben werden
4. log: Format der Logdatei
5. image-default: Beschreibt den Standard Imagenamen
6. checksum: Erzwingt den checksum-Vergleich der Dateien.
7. summary: Format der Zusammenfassung
8. speed-limit: Möglichkeit die Transfergeschwindigkeit zu begrenzen.
9. exclude: Ausschließen bestimmter Dateien oder Verzeichnisse
10. Runall: Definiert die Tresore, die bei automatischem Backup zu sichern sind.
11. expire-default: Standardzeit nachdem ein Image abgelaufen ist - also gelöscht werden kann.
12. expire-rule: Spezielle Regeln, nach welchen Images länger behalten werden können. (In unserem Fall nicht notwendig)

Die Einstellmöglichkeiten sind sehr vielfältig. Es lohnt sich der Blick in die Manpage!

# Beispiel dirvish/default.conf
# Tresor 'home'
 
client: user@myclient
tree: /home/
exclude:
     *.bak
     *~
     .kde/share/cache/*
     .firefox/default/*/Cache/*
     .mozilla/default/*/Cache/*
 
#expire-default: +2 days

Beschreibung der Zeilen:

1. client: Name des Client, der zu sichern ist. Bei lokaler sicherung die Ausgabe des Programmes hostname
2. tree: Pfad, der zu sichern ist
3. Extraoptionen speziell für diesen Tresor.

Die Datei für den anderen Tresor kann bis auf die client:-Variable identisch aussehen.

: Noch zu schreiben. Hinweise hier http://wiki.dirvish.org/?VaultBranch

dirvish nutzt rsync über eine SSH-Verbindung, wenn es einen entfernten Client sichern soll. Dazu muß dern angegeben Nutzer in der Option client: einen SSH-Zugang ohne Passwortabfrage erhalten. Leider ist dieses in den meisten Fällen der User root. Einen solchen Zugang verschafft man sich über den Austausch eines SSH-Schlüssels.

Wie dieses funktioniert, ist im Internet zu genüge zu erfahren. Unter anderem hier.

Nicht vergessen den Zugang für root in der sshd_config zu erlauben.

Um die Konfiguration zu testen muß als erstes ein Initiales Backup durchgeführt werden. Dies kann je nach Datenmenge und Netzanbindung einige Zeit dauern:

dirvish --init -vault client1-home

Nun sollte man die Konfiguration ausgiebig testen. Mit der Option –no-run kann man einen „Trockentest“ durchführen. Dabei sollte man insbesondere die Expire-Schwelle prüfen (in unserem Fall –time „now + 15 days“).

dirvish --no-run --vault client1-home --image-time tomorrow

Wie Zeitangaben definiert sind, kann man in den Manpages der Perl-Module lesen (siehe: man 3 Time::ParseDate und Time::Period).

Ein Testbeispiel:

dirvish --vault client1-home --image-time tomorrow
dirvish-expire --no-run --vault client1-home --time "now + 15 days"

Wie oben schon beiläufig erwähnt gibt es einige Dateikathegorien, die sich schlecht sichern lassen. Das liegt daran, daß Sie sich häufig ändern oder unwichtige Daten enthalten. Neben den Cache-Dateien der Browser sind es zum Beispiel Mailboxen im MBOX-Format. Hier werden viele Mails in einer Datei gespeicht. Daher muß dirvish praktisch jedes Mal die gesamte Mailbox sichern. Außerdem besteht die große Gefahr, daß die Dateien während eines Speichervorgangs gesichert werden und somit unvollständig sind. Besser wäre ein anders Mailbox-Format zu nutzen oder diese anders zu sichern.

Dieses Programm implementiert die Möglichkeit Inkrementelle Backups zu erstellen. Das Schema in dem diese angelegt werden, mutet erstmal etwas unverständlich an. Es arbeitet mit sogenannten „Levels“, die die Hierarchie der Backuptiefe und -dauer der Inkrementellen Archive bestimmt.

Ich wäre in meinem Programm yabp folgendermaßen vorgegangen:

1. 1. Sonntag: Vollbackup
2. Montag bis Samstag: Inkrementell zum jeweiligen Vortag
3. 2. Sonntag: Inkrementell zum 1. Sonntag
4. Montag bis Samstag: Inkrementell zum jeweiligen Vortag
5. 3. Sonntag: Inkrementell zum 2. Sonntag
6. Montag bis Samstag: Inkrementell zum jeweiligen Vortag
7. 4. Sonntag: Vollbackup

Was ich im Grunde aber wirklich zum Ausdruck bringen möchte, ist, daß ich mich an Wochentage und ähnlichem orientieren wollte. Das macht das Verständnis und die Überlegungen einfacher.

Die Arbeit mit den Leveln von backup2l bringt einige Einschränkungen mit sich:

1. Bezeichnung der Dateien können keine Datumsangabe besitzen ³⁾
2. Jedes Level hat eine identische Menge an Ausführungen bevor eine Rotation kommt.

Das Programm muß installiert werden:

apt-get install backup2l

Das Programm nutzt standardmäßig die Datei /etc/backup2l.conf und generiert so mittels cron die täglichen Backups. In meinem Fall ist das aber zu ungenau. Damit meine ich, daß ich jedes dirvish-Backup einzeln ansteuern möchte. Das hat zudem den Vorteil, daß man später den Start in einen dirvish-Hook packen kann.

Aus diesem Grund lege ich in jedem Tresor ein Verzeichnis backup2l und darin die Datei backup2l.conf an.

mkdir /mnt/storage/backups/bueroserver/home/backup2l

Im doc-Verzeichnis findet man eine Beispieldatei, die man kopieren und dann auf unsere Bedürfnisse abändern kann. Um die Übersicht zu wahren, werde ich nur Zeilenangaben und Änderungen der wichtigen Optionen angeben und besprechen.

backup2l.conf - Allgemein

# Zeile 16: Prefix für alle erstellten Backups
VOLNAME="myserver_home"
 
# Zeile 26: Verzeichnisse (absolute Angabe), die gesichert werden sollen.
SRCLIST=(/path/to/backups/bank1/home)
 
# Zeile 53: Zielverzeichnis der Backups
BACKUP_DIR="/mnt/d_platte/backup"
 
# Zeile 61 bis 72
# Anzahl der inkrementellen Rotationen
MAX_LEVEL=2
# Anzahl der inkrementellen Backups pro Level
MAX_PER_LEVEL=5
# Anzahl der Voll-Backups
MAX_FULL=2
# Anzahl der differenziellen Backups, die pro Level NICHT gelöscht werden sollen
GENERATIONS=6

Nach diesen Zeilen kommen auch für backup2l die Hooks, um vor oder nach der Sicherung Aktionen auszuführen. Schon angelegt, aber noch auskommentiert ist die Erstellung der Paketliste:

backup.conf - Speziell

#Zeile 91: Erstellen der Debian-Paketliste
#          (Ist in unserem Fall nicht sinnvoll, da wir ja ein anderes
#           System sichern!)
# echo "  writing dpkg selections to /root/dpkg-selections.log..."
# dpkg --get-selections | diff - /root/dpkg-selections.log > /dev/null \
#  || dpkg --get-selections > /root/dpkg-selections.log
 
# Zeile 114: ändern, damit das Programm überhaupt läuft
UNCONFIGURED=0

Danach kommen die Treiber. Man sollte sie sich mal anschauen. Wir verwenden erstmal den Standard DRIVER_TAR_GZ.

Auch hier sollte man ausgiebig testen. Vor allem kann man sich so verdeutlichen, ob man die Rotation und Arbeitsweise der Level verstanden hat.

Durch explizites angeben der Konfigurationsdatei, kann man die gerade erstellte Datei dizidiert testen. Wenn man nicht sofort die Manpage konsultieren möchte, muß man unter Angabe einer Konfigdatei und --help, die Kurzhilfe anschauen.

Erstellen eines Backup:

backup2l -c backup2l.conf -b

Dieses kann man wiederholen, bis man alles verstanden hat.

Bei der Konfiguration der Level muß man am Ende dann wohl doch die Realität befragen. Wieviel Daten kommen zusammen, paßt alles auf eine DVD / CD usw.

Die Dateigröße bei DVDs ist auf etwa 2Gb begrenzt. Daher sollte man eine Split-Grenze angeben.

Nun kommt der schwerste Teil, nicht, weil die Konfiguration so komplex wäre, sondern weil man genau überlegen muß, wie man weiter verfahren möchte. In meinem Fall nutze ich die post-server: Option, um backup2l gezielt zu starten.

Ich habe in die Bank einen symbolischen Link gesetzt, der auf die aktuellte dirvish Backup-Version verweist. Dieser Link wird die neue Quelle vom backup2l-Backup des home-Tresor. Weil dieser Link nach jedem dirvish-Durchlauf aktualisiert wird, funktioniert das inkrementieren von backup2l.

Anlegen des Links:

ln -s /path/to/bank1/home/yyyymmdd_hhMM /path/to/bank1/aktuell_home

Ändern der Quellzeile backup2l/backup2l.conf:

# Zeile Verzeichnisse (absolute Angabe), die gesichert werden sollen.
SRCLIST=(/path/to/backups/bank1/aktuell_home)

In der Datei dirvish/dirvish.conf wird folgender Eintrag hinzugefügt:

post-server:  ; rm /path/to/bank1/aktuell_home; ln -s $DIRVISH_DEST/../ /path/to/bank1/aktuell_home && /usr/sbin/backup2l -c /path/to/bank1/home/backup2l/backup2l.conf -b;

Nun wird nach dem Sync der alte „symb-link“ gelöscht und durch den aktuellen ersetzt. Danach wird backup2l mit der entsprechenden Konfigurationsdatei aufgerufen.

Datenbanken und ein paar andere Dienste sollte man anders sichern, da sonst deren Konsistenz nciht gewährleitet ist.

Die Partitionstablle ist auch immer wieder wichtig zu sichern. Folgendermaßen funktioniert das.

Speichern der Partitionstabelle: <code bash|Konsole> sfdisk -d /dev/sdX > sdX-Parttab.backup </console>

Rücksichern der Partitionstabelle: <code bash|Konsole> sfdisk /dev/sdX < sdX-Parttab.backup </console>