© David Crockett, 123RF.com

Schnell ist im Alltag die falsche Datei überschrieben, ein Ordner verschwunden, anstelle der Spam- eine echte Mail gelöscht oder ein PC so verkorkst, dass die Systemreparatur länger dauern würde, als ihn neu aufzusetzen. Hat der Admin vorgesorgt, kann er sich den Rettungseinsatz zur Unzeit sparen.

Es gibt nur zwei Arten von Computernutzern: jene, die schon mal Dateien oder E-Mails verloren haben, und jene, die noch welche verlieren werden. Automatisierte und regelmäßige Backups der Daten aller Benutzer sollten in jeder Firma selbstverständlich sein. Um an alte Dateien zu gelangen, muss der Admin die passende Restore-Software starten, die richtigen Bänder einlegen, die benötigten Objekte suchen und dann wiederherstellen. Dies ab und zu tun müssen ist kaum der Erwähnung wert; mit vielen zu betreuenden oder besonders schusseligen Usern häufen sich die Einsätze.

Damit wird eine schnellere und unkompliziertere Variante wünschenswert, um auf historische Stände von Dateien zugreifen zu können: Dateisystem-Snapshots. Die bilden keinen Ersatz für vollwertige Backups, ergänzen diese aber, um Daten im schnellen und einfachen Zugriff zu halten. So ist es möglich, historische Stände von Verzeichnisbäumen vorzuhalten und Anwendern bereitzustellen, um bei gelöschten Dateien oder Mails ohne Administrator auszukommen.

Was ein Admin geübt auf der Befehlszeile durchführt, ist dem normalen Anwender einerseits meist nicht geläufig, andererseits im sicheren Betriebsumfeld zumeist auch gar nicht möglich, da ihm die erweiterten Rechte des Administrators fehlen. Und gerade in der Aufregung um soeben gelöschte Dateien ist das Eintippen von selten geübten und vermeintlich kryptischen Befehlen umso fehlerträchtiger. Wie gut, wenn es vorbereitete Strukturen gibt, auf die ein instruierter Benutzer oder auch alle mit gewohnten Werkzeugen wie Dateimanager oder E-Mail-Client zugreifen können.

Laufend Schnappschüsse

Eine praktische Lösung dazu lässt sich mit frei verfügbaren Werkzeugen zusammenbasteln. Das folgende Beispiel geht von einem gängigen Samba-Dateiserver aus, der im LAN Dateien für Windows- oder Linux-Arbeitsplätze bereitstellt. Das Tool Rsnapshot [1] ist ein Wrapperskript zu Rsync, dem Synchronisierungs-Werkzeug von Samba-Entwickler Andrew Tridgell. Es legt in regelmäßig ausgeführten Durchläufen Schnappschüsse von Dateien und Verzeichnissen an, die auf Hardlinks basieren.

Ein üblicher Ansatz ist, stündliche, tägliche, wöchentliche Läufe auszuführen, es entstehen Snapshots nach dem Schema:

hourly.0
hourly.1
hourly.2[...]
hourly.x

Dabei stellt »hourly.0« den jüngsten Schnappschuss dar.

Unveränderte Dateien und Verzeichnisse sichert Rsnapshot nicht erneut, sondern legt sie in Form von Hardlinks im Dateisystem ab. Damit lässt sich erreichen, dass der Gesamt-Platzbedarf nicht zu groß wird. Das Zielverzeichnis für die Snapshots muss aber Hardlinks beherrschen, gängige Linux-Dateisysteme wie Ext 3, Ext 4 und XFS tun dies.

Soll der Fileserver aus Verfügbarkeitsgründen die Snapshots nicht lokal ablegen, können Rsync und Rsnapshot die Dateien auch per SSH über das Netzwerk auf einem zweiten Samba-Server ablegen. Das hier gezeigte Setup geht aber von davon aus, dass Daten und Snapshots auf demselben Server lagern.

Dieser exportiert eine Freigabe namens »Daten« , das darunter liegende Verzeichnis im Linux-Filesystem heißt »/mnt/data« . In die »smb.conf« gehört darum folgende Sektion:

[Daten]
path = /mnt/data
writable = yes

Die Datei »rsnapshot.conf« in Listing 1 enthält die Parameter für »rsnapshot« . Hier darf der Admin als Trennzeichen nur Tabulatoren verwenden. Für einen Testlauf eignet sich »rsnapshot -tv hourly« , dabei listet das Skript die erzeugten Befehle, führt sie jedoch nicht aus. Eine passende Crontab zeigt Listing 2.

Sofern die Konfiguration korrekt und ausreichend Platz im Zielverzeichnis vorhanden ist, füllt Rsnapshot nun regelmäßig die Schnappschuss-Directories mit aktuellen Kopien der bearbeiteten Files der Samba-Freigabe. Der erste Lauf dauert erwartungsgemäß am längsten, denn er muss alle Dateien kopieren. Folgende Durchläufe sind deutlich schneller. Es empfiehlt sich also, den Erstlauf außerhalb der produktiven Arbeitszeit des Servers auszuführen.

01 snapshot_root      /mnt/rsnapshots/           # Das Zielverzeichnis, das die Schnappschüsse aufnimmt
02 backup             /mnt/data      daten/      # Das Quellverzeichnis und sein Label in den Snapshots
03
04 # Die "interval"-Zeilen bestimmen, wie viele Schnappschüsse jedes Level maximal vorhalten soll:
05 interval           hourly  6
06 interval           daily   7
07 interval           weekly  4
08 interval           monthly 3

01 # "ionice" und "nice" sorgen hier für niedrige Priorität bei der Ausführung.
02 # So stört "rsnapshot" nicht so sehr, wenn es während der Arbeitszeit am Produktivserver läuft:
03 00 7-19 * * 1-5    ionice -c3 nice /usr/bin/rsnapshot hourly
04 40 21 * * 1-5      ionice -c3 nice /usr/bin/rsnapshot daily
05 00 23 * * 6        ionice -c3 nice /usr/bin/rsnapshot weekly
06 20 23 1 * *        ionice -c3 nice /usr/bin/rsnapshot monthly

Zugriff erfolgt

Jetzt fehlt noch der einfache Zugriff für den Anwender, der in der Abteilung für das Restore zuständig zeichnet. Hierfür lässt sich wieder der ohnehin vorhandene Samba-Server nutzen. Listing 3 zeigt, wie er die Snapshots per Netzwerkfreigabe bereitstellt. Das Setzen von »writable=no« in der »smb.conf« hat den Sinn, ein irrtümliches Verändern der Snapshots zu unterbinden. Es verhindert auch, dass ein Mitarbeiter direkt mit einem Snapshot weiterarbeitet.

Die Option »valid users« schränkt optional den Kreis derer ein, die sich mit dieser Freigabe verbinden dürfen. So bestimmt der Admin, welche Benutzer Zugriff auf die Snapshots haben. Sollen alle zugreifen dürfen, entfällt diese Option.

Ab nun ist es möglich, in den Zielverzeichnissen auf historische Stände der Dateien zuzugreifen (Abbildung 1), etwa auf die Version einer Office-Datei aus der letzten Woche oder von gestern, 17 Uhr. Die damit betrauten Anwender können nun per Datei-Explorer in den Snapshots browsen und den gewünschten Stand der Dateien einfach ins Arbeitsverzeichnis zurückkopieren.

01 [Snapshots]
02 path = /mnt/rsnapshots
03 writable = no
04 valid users = meier, schmidt, @admins
05 browsable = no

Abbildung 1: Eine typische Rsnapshot-Hierarchie, die den zeitlichen Verlauf der Schnappschüsse auf Benutzerseite widerspiegelt. Gerade markiert ist der jüngste Abzug.

E-Mails wiederholen

Ein ähnlicher Ansatz ist auch für E-Mails möglich. Maildir als Storage-Format macht es möglich, Snapshots auf Datei-Ebene anzufertigen, die den Inhalt der User-Mailboxen historisch korrekt abbilden. Der Open-Source-POP- und -IMAP-Server Dovecot bringt das Konzept der Namespaces [3] mit, wie es in RFC 2342 [4] beschrieben ist. Einen solchen Namespace kann der Admin dazu benutzen, zum Beispiel den letzten stündlichen Snapshot ins IMAP-Postfach des Anwenders einzublenden. Das Anfertigen der Snapshots des Dovecot-Datenverzeichnisses »/mnt/dovecot« übernimmt wieder Rsnapshot. In die »/etc/rsnapshot.conf« gehört deswegen die Zeile:

backup /mnt/dovecot/ localhost/

Listing 4 konfiguriert zwei Namespaces, den ersten für das originale Postfach, den zweiten für das Einblenden des letzten stündlichen Snapshots im Ordner »EmailBackup.h2« . Beispielsweise bekommt der IMAP-Ordner »INBOX.gentoo-users« dann den Snapshot »INBOX.EmailBackup.h-2.gentoo-users« als Entsprechung (siehe Abbildung 2). Der Benutzer des Postfachs kann nun selbst innerhalb seines IMAP-Clients auf den Snapshot zugreifen und verloren geglaubten Mails einfach per Drag&Drop wiederherstellen.

01 namespace {
02 inbox = yes
03 location =
04 prefix = INBOX.
05 type = private
06 }
07
08 namespace snaps-h2 {
09         prefix = INBOX.EmailBackup.h-2.
10         hidden = no
11         list = yes
12         inbox = no
13         location = maildir:/mnt/doveshots/hourly.0/localhost/mnt/dovecot/%u/Maildir:INDEX=/var/tmp/dovecot/indexes/hourly.0/%u:CONTROL=/var/tmp/dovecot/control/hourly.0/%u
14         type = private
15 }

Abbildung 2: Im E-Mail-Client jedes Benutzers blenden sich neben dem regulären IMAP-Foldern, hier beispielsweise »gentoo-users«, korrespondierende Snapshot-Folder ein, hier »EmailBackup.h-2«.

Asynchrones Retten

Einen anderen Ansatz verfolgt das Dovecot-Plugin Lazy Expunge [5]. Die per Mailclient gelöschten Mails landen in einem definierten Ordner, der sich wiederum – wie oben – im IMAP-Baum einblendet. Die Funktion entspricht etwa dem des Papierkorbs: Löscht der Anwender Mails aus seinen IMAP-Ordnern, schiebt das Plugin diese Mails in den vorgegebenen Expunge-Ordner. Dieser lässt sich nun per IMAP-Namespace als für die Anwender sichtbar einblenden.

Die Vorhaltezeit der Mails bestimmt der Administrator mit der Konfiguration eines entsprechenden Cronjobs: Denkbar ist zum Beispiel, die Expunge-Ordner der Anwender alle 24 Stunden per »find« und »rm« zu putzen, was dem Ausleeren des Papierkorbs gleichkommt. Das Wiki [5] erklärt die Konfiguration recht anschaulich an einem Beispiel.

Der Vorteil von Lazy Expunge ist, dass es gelöschte Mails lückenlos vorhalten kann, denn jede dieser Mails landet unmittelbar und definitiv im Ordner »Expunge« . Der Ansatz mit Rsnapshot – E-Mail und Dateien gleichermaßen betreffend – lässt dagegen eine gewisse Grobmaschigkeit zu: Der jeweils letzte Snapshot beinhaltet den Stand zum Zeitpunkt des letzten Rsnapshot-Laufs – je nach Konfiguration passiert der stündlich. Legt der Anwender eine Datei zwischen zwei Läufen an oder trifft in dieser Zeit eine E-Mail ein und der User löscht sie noch vor dem nächsten Durchlauf, erhält Rsnapshot keine Gelegenheit, eine Kopie davon anzufertigen. Dem kann der Admin mit häufigeren Läufen begegnen; er sollte aber die damit einhergehende Belastung des Dateiservers im Auge behalten.

Rechner wieder aufsetzen

“Das Ding ist praktisch tot!” Ist ein Büro-PC von Malware befallen, total verkonfiguriert oder durch ein Update unbenutzbar geworden, kann es gerade bei Desktoprechnern die schnellste und einfachste Lösung sein, ihn aus dem Backup neu hochzuziehen (Abbildung 3). Mac-Benutzer kennen das von der Time Machine, die benutzerfreundlich auf alte Versionsstände zurückrollt.

Der Klassiker für solche Imagesoftware ist Ghost [6]. Auch im Open-Source-Bereich gibt es hierfür sehr zufriedenstellend arbeitende Tools, angefangen vom reinen Image-Handling [7] bis hin zum Deployment (FOG, [8]). Admins, die User vor Ort ins Zurückspielen solcher Images einweisen wollen, müssen sich konzeptionell überlegen, ob sie vorab Images jedes vorhandenen Rechners einzeln anfertigen wollen, ob es ein einheitliches für alle geben soll.

Als vorbereitende Maßnahme sollte das Bios aller Rechner so eingestellt sein, dass jeder PC stets versucht zuerst über das Netzwerk zu booten. Per DHCP bekommt der PC dann als Bootfile PXE Linux [9] geschickt. Das “Preboot Execution Environment Linux” ist Teil des Syslinux-Pakets. In dessen Konfiguration ist der Defaulteintrag das Booten von lokaler Platte, sodass das Hochfahren des Rechners zwar jedes Mal etwas länger als gewöhnlich dauert, der Anwender aber nichts unternehmen muss, wenn der Rechner normal starten soll.

Listing 5 zeigt die Konfigurationsdatei für PXE Linux, die unter »/tftpboot/pxelinux.cfg/default« auf dem im DHCP-Server mit »next-server« angegebenen Server liegen möge. Muss der Anwender das System nun über das Netz re-installieren, schaltet er den Rechner ein, gibt »restore« ein und geht dann am besten einen Kaffee trinken.

Abbildung 3: In krassen Fehlerfällen geht es schneller, einen PC mit Hilfe von Backups frisch einzurichten statt das System zu reparieren.

01 DEFAULT local
02 PROMPT 1
03 TIMEOUT 300
04 SAY Type restore to restore from net, press enter to boot from disk
05
06 LABEL restore
07         KERNEL fedora/vmlinuz
08         APPEND initrd=fedora/initrd.img ks=http://10.1.1.1/ks-restore.cfg ramdisk_size=268235456 ksdevice=eth0
09
10 LABEL local
11         LOCALBOOT 0

Kickstart

Das Setup verwendet den Kickstart einer Fedora-Installation, aber beim Aufbau für diesen Test ließ sich auch ein Gentoo-System restaurieren. Der Admin kopiert von der Fedora-Boot-CD oder -DVD den Kernel und die »initrd« ebenfalls auf den TFTP-Server. Außerdem ist im Netz ein Webserver notwendig, der die Kickstart-Konfiguration und das Backup der Systeme als ».tar.bz2« -Datei vorhält. (Es dürfen natürlich auch zwei getrennte Webserver sein.)

Listing 6 zeigt das Kickstart-File, das zwar so tut, als ob es Fedora installieren wolle, aber von einem Skript im »%pre« -Bereich, das vor allen anderen Aktionen startet, unterbrochen wird. Es führt nämlich am Ende einen Reboot aus, der Rest der Fedora-Installationsroutine kommt gar nicht zum Tragen. Die Zeilen 1 bis 23 stellen in Kickstart-Manier [10] Zeitzone, Root-Passwort, Parameter für die Festplatte, die allerdings niemand interpretiert, sowie die Quelle der Installation ein. Damit der Kickstart-Parser durchläuft, sind die meisten der Einträge auch notwendig.

Die eigentliche Arbeit erledigt das Shellskript ab Zeile 24. Es unterteilt die Festplatte in drei Partitionen, legt die Dateisysteme an und mountet sie temporär. In Zeile 42 lädt Wget das Archiv herunter und pipet es direkt in das auspackende Tar-Kommando. Die Zeilen 42 bis 47 sind nicht notwendig, wenn im Archiv die Device-Nodes enthalten sind. Dies sind auch die mindestens nötigen Nodes – für den Fall, dass der Admin das Archiv von einem laufenden System gezogen und das »/dev« -Filesystem nicht mitgenommen hat –, damit das danach aufgerufene Lilo funktioniert und das wiederhergestellte System von der Festplatte bootet. Es empfiehlt sich jedoch, im Masterimage den Device-Baum mitzunehmen.

01 lang en_US
02 keyboard us
03 timezone --utc Europe/Berlin
04 rootpw test123
05 reboot
06 text
07 install
08 url --url=http://10.1.1.1/empty
09 bootloader --location=mbr
10 zerombr
11 clearpart --all --initlabel
12 part /boot --fstype ext3 --size 100
13 part swap --size 512
14 part / --fstype ext3 --size 1 --grow
15 auth  --useshadow  --enablemd5
16 network --bootproto=dhcp --device=eth0
17 firewall --disabled
18 selinux --disabled
19 skipx
20 %packages --ignoremissing
21 grub
22
23 %end
24 %pre
25 #! /bin/bash
26
27 parted -s /dev/sda mklabel msdos
28 parted -s /dev/sda mkpart primary ext2 0 100MB
29 parted -s /dev/sda mkpart primary linux-swap 100MB 500MB
30 parted -s /dev/sda mkpart primary ext3 500MB 100%
31 parted -s /dev/sda 1 set boot on
32 parted -s /dev/sda 2 set swap on
33 mke2fs /dev/sda1
34 mkswap /dev/sda2
35 mke2fs -j /dev/sda3
36 mkdir /tmp/system
37 mount /dev/sda3 /tmp/system
38 swapon /dev/sda2
39 mkdir /tmp/system/boot
40 mount /dev/sda1 /tmp/system/boot
41 cd /tmp/system
42 wget -O - http://10.1.1.1/gentooimage.tar.bz2|tar xjpf -
43 mknod dev/sda b 8 0
44 mknod dev/sda1 b 8 1
45 mknod dev/sda2 b 8 2
46 mknod dev/sda3 b 8 3
47 mknod dev/console c 5 1
48 mount -t proc none /tmp/system/proc
49 chroot /tmp/system /sbin/lilo
50 reboot
52 %end
53 %post --nochroot
54 %end

Raum für Eigenes

Das Skript in Listing 6 ist als Inspiration, nicht als Optimum zu verstehen – so fehlt ihm eine vernünftige Fehlerbehandlung. Ein paar Bash-Kenntnisse reichen aber, um es beliebig anzupassen. Steht beispielsweise ein abstrakter Master bereit, so könnte das Skript das Netzwerk einbinden, den Hostnamen selbst setzen und so weiter. Will der Administrator Windows-Systeme mit Open-Source-Mitteln automatisch reanimieren, holt er aber besser FOG mit ins Boot, da es ein paar Tricks beherrscht, die nach Zurückspielen des Image notwendig sind.

Auch die im ersten Teil der Artikels aufgezeigten Restore-Setups für Dateien und E-Mails erheben keinen Anspruch auf Vollständigkeit. Linux-Magazin-Leser, die robustere Lösungen für ihre Endanwender entwickelt und im Einsatz haben, können diese gern an mailto:redaktion@linux-magazin.de schicken. Die besten wird die Redaktion in den nächsten Magazin-Ausgaben veröffentlichen.