Wer Hotplug verstanden hat und ein Tool wie Ivman richtig zu nutzen versteht, dem öffnen sich die Türen zur Automatisierung beinahe beliebiger Abläufe. In diesem Artikel stößt ein Notebook Backups an, sobald sein Besitzer eine bestimmte Platte anstöpselt.

Zu manchen Dingen gibt es keine Alternative: zu einem regelmäßigen Backup beispielsweise. Wer das nicht glaubt, den überzeugt früher oder später die Endlichkeit jedes Festplattendaseins. So wahr und abgedroschen diese Erkenntnis auch sein mag, leicht umzusetzen ist sie deswegen noch lange nicht.

Mobile Rechner brauchen Flexibilität

Für Laptops etwa taugen Cron oder das zyklische Pflichtbewusstsein eines Backup-Clients wenig. Denn wenn die Sicherung turnusmäßig starten sollte, ist vielleicht gerade der Akku leer, sind Server, Bandlaufwerk oder Backup-Platte hunderte Kilometer entfernt oder der Anwender gerade nicht gewillt, Rechenleistung an einen Routinejob abzutreten. Wäre alles beisammen und der Zeitpunkt günstig, denkt der User aber garantiert nicht ans fällige Sichern.

Optimal wäre deshalb, wenn der mobile Rechner die Eigensicherung selber im Hinterkopf behielte und bei passender Gelegenheit von alleine alle Daten an einen sicheren Ort kopierte. Wenn der Zeitplan aber einmal nicht einzuhalten ist, dann sollte er das auch ohne Murren akzeptieren, statt sich mit Kaskaden von Fehlermeldungen in überlaufenden Logs zu rächen.

Eigenverantwortung

Ein einfaches Lösungsszenario für dieses Problem könnte so aussehen: Der Rechner lässt sich über jedes An- und Abstöpseln eines USB-Geräts informieren. Dabei erkennt er selbstständig, wenn der Benutzer die Platte mit der Partition für Datensicherungen anschließt. Sobald sie greifbar ist, hängt er sie an einer exklusiven Stelle ins Filesystem.

Ein Backupjob startet asynchron mit festem Turnus und schaut zuerst auf den dedizierten Backup-Mountpoint: Findet er dort keine Platte, legt er sich klaglos wieder schlafen. Stößt er aber bei diesem Mountpunkt auf eine Disk, dann kann es nur die Sicherungsplatte sein, also startet er das Backup.

Erkennungsdienst

Im ersten Schritt geht es folglich um die Hardware-Erkennung und das automatische Mounten. Dafür gibt es eine ganze Palette möglicher Lösungen. Ausgangspunkt ist immer der Buscontroller, in dessen Hoheitsbereich die frisch angeschlossene Platte fällt.

Der erkennt das Anstecken an einem elektrischen Signal und reagiert darauf mit einem Interrupt. Verwendet die Linux-Distribution den Hardware Abstraction Layer (HAL, [1]) konvertiert dieser die Unterbrechung in einen Event, den der D-Bus (System Message Bus) anschließend aussendet. Dort lauschen Userspace-Programme, filtern die Nachrichten nach ihrem Bedarf und übernehmen Aktionen wie das Mounten.

Das Wissen über das hinzugekommene Gerät liefern in erster Linie dessen Product- und Vendor-ID, die auch die Verknüpfung mit dem passenden Treiber ermöglichen. Daneben lassen sich Einträge im Sys-FS auswerten, die der Kernel dort hinterlegt. Zusätzlich können auf der Ebene des Hardware Abstraction Layer noch weitere Hinweise zu Geräten gespeichert sein.

Bei der Auswertung dieser Infos in Reaktion auf den Anstöpsel-Event trennen sich allerdings die Lösungswege. Unter dem Gnome-Desktop kann der Gnome Volume Manager alles weitere in die Hand nehmen, unter KDE sind Kioslaves für diese Rolle prädestiniert. Daneben gibt es jedoch auch Desktop-unabhängige Lösungen wie Submount oder Ivman [2]. Ivman läuft im Gegensatz zu Submount im Userspace, ist Standard unter Gentoo Linux und lässt sich parallel zu KDE oder Gnome einsetzen, es taugt aber auch für Desktops wie XFCE. Der großen Vielseitigkeit wegen sei das Backup-Beispiel im Folgenden mit Ivman demonstriert.

Nach strengen Regeln

Ivman verfügt über ein Regelwerk, das Bedingungen mit Aktionen verknüpft. Es untersucht jeden HAL-Event daraufhin, ob eine der Bedingungen zutrifft, die in den Regeln enthalten sind. Sobald dem so ist, führt Ivman die zugehörige Aktion aus – das darf ein einfaches Kommando, aber auch ein komplexes Skript sein. Im Bedingungsteil können die Regeln jede Information verwenden, die der Hardware Abstraction Layer kennt. Welche das sind, ermittelt der Anwender am einfachsten mit dem Kommando »lshal« (Abbildung 1).

Abbildung 1: Das Kommando »lshal« listet alle Geräte und ihre Eigenschaften, die der Hardware Abstraction Layer (HAL) registriert hat. Zu sehen sind die Daten einer Partition. Deren Eigenschaften eignen sich als Filterkriterien für Ivman, um beim Einstecken automatisch auf diese Partition (»volume.uuid«) ein Backup zu schreiben.

Die Regeln finden sich im Wesentlichen in zwei Konfigurationsdateien: »IvmConfigActions.xml« definiert Aktionen, die beim Anschluss eines neuen Geräts oder beim Einlegen eines Mediums in ein Laufwerk auszuführen sind. »IvmConfigProperties.xml« dagegen sammelt Regeln, die eine Geräteeigenschaft zur Bedingung haben. Daneben existiert das File »IvmConfigBase.xml« mit allgemeinen Programmvorgaben. Beispielsweise legt diese Datei fest, unter welchem Nutzer und mit welcher Gruppenzugehörigkeit Ivman laufen soll.

Neuere Ivman-Versionen verfügen noch über die Datei »IvmConfigConditions.xml«, die besondere Bedingungen definiert. Sie müssen erfüllt sein, bevor Ivman eine bestimmte Aktion ausführt.

Das Backup-Beispiel soll auf das Anschließen einer bestimmten Platte reagieren, daher ist »IvmConfigActions.xml« der richtige Ort. Der Bedingungsteil jeder Regel kann mit dem Key »ivm:Match« eine HAL-Eigenschaft spezifizieren und dafür einen Wert vorgeben, der die Aktion triggert. Um einem bestimmten USB-Stick über seine Modellbezeichnung einen Mountpoint zuzuweisen, reicht die folgende Regel:

<!--Mounting an USBStick -->
<ivm:Match name="hal.storage.model" value="TS64MJFLASHA">
<ivm:Optionname="exec" value="mount
$hal.block.device$/media usbstick" />
</ivm:Match>

Dass der Mountbefehl hier nicht mit dem Namen, sondern mit dem Wert der HAL-Property »block.device« operieren soll, symbolisieren die umschließenden Dollarzeichen.

Mit Logbuch

Die Backup-Partition dagegen erfordert ein spezifischeres Merkmal als eine Modellbezeichnung. Deshalb kommt ihre unverwechselbare Volume-ID als Erkennungszeichen zum Einsatz. Außerdem soll Ivman die An- und Absteck-Events zusätzlich zum Ablauf des Backups loggen. Für all das ist nicht einmal ein Skript nötig, es reichen bereits wenige Zeilen im Aktions-Konfigurationsfile von Ivman dafür aus, wie das Listing 1 zeigt.

01<!-- Mounting the Backupdisk -->
02<ivm:Match name="hal.volume.uuid" value="e86236bb-d107-41cd-b8b1-9caf23a5ad91">
03   <ivm:Option name="exec"   value="echo 'Attaching backup disk: '`date` >> /var/log/backup.log" />
04   <ivm:Option name="exec"   value="mount $hal.block.device$ /media/backupdisk" />
05   <ivm:Option name="execun" value="echo 'Backup-Disk detached: ' `date` >> /var/log/backup.log" />
06</ivm:Match>

Serienaufnahme

Natürlich ließe sich an dieser Stelle auch gleich das Backup anstoßen, doch wäre es dann nur ein einmaliger Vorgang. Im vorliegenden Fall soll der Rechner jedoch – solange die Backupdisk gemountet ist – regelmäßig alle zwei oder drei Stunden Filesystem-Snapshots schießen.

Dazu startet Cron periodisch das Skript aus Listing 2, das zunächst prüft, ob eine Platte am Backup-Mountpoint angeschlossen ist. Wenn ja, muss es die richtige sein, der Rechner fertigt daraufhin einen Snapshot an. Die dabei anfallenden Terminal-Ausgaben landen im selben Logfile, das sich schon das Anschließen der Platte gemerkt hatte (Listing 3).

01 #!/bin/sh
02 if [ `grep backupdisk /etc/mtab | wc -l` -gt 0 ]
03 # ok, backup disk found
04 then
05   if [ -f /var/run/rsnapshot.pid ]
06     # rsnapshot is already running -> exit
07     then exit 1
08   else
09     # let's take a snapshot
10     echo -e "n ================================================== n" >> /var/log/backup.log
11     echo "Hourly snapshot started: `date`"  >> /var/log/backup.log
12     /usr/bin/rsnapshot hourly         2>&1 1>> /var/log/backup.log
13     echo "Hourly snapshot finished: `date`" >> /var/log/backup.log
14   fi
15 else
16   # backup disk is not mounted -> exit
17   exit 1
18 fi

01 Attaching backup disk: Thu Jun 22 11:00:52 CEST 2006
02 Backup disk /dev/sda2 mounted at /media/backupdisk:
03 Thu Jun 22 11:03:57 CEST 2006
04 
05 ==================================================
06 
07 Hourly snapshot started: Thu Jun 22 12:00:01 CEST 2006
08 echo 25958 > /var/run/rsnapshot.pid
09 [...]
10 mkdir -m 0755 -p /media/backupdisk/hourly.0/
11 /usr/bin/rsync -ax--delete--numeric-ids--relative--delete-excluded 
12     --exclude=media/backupdisk 
13     --link-dest=/media/backupdisk/hourly.1/localhost/ / 
14     /media/backupdisk/hourly.0/localhost/
15 [...]
16 rm -f /var/run/rsnapshot.pid
17 Hourly snapshot finished: Thu Jun 22 16:05:03 CEST 2006
18 [...]

Bitte lächeln

Den Snapshot selbst fertigt das bewährte Rsnapshot ([3], [4]) an. Es setzt SSH und Rsync voraus und ist für die meisten Distributionen in Paketform verfügbar. Es sorgt für außerordentlich platzsparende Sicherungen, für die sich außerdem sehr flexible Zeitpläne für Vollbackups und inkrementelle Sicherungen konfigurieren lassen. Letztere beanspruchen nur das Allernötigste an Plattenplatz, weil das Tool unveränderte Files lediglich hart verlinkt, aber nicht physisch kopiert.

Außerdem kann der Benutzer eine maximale Schnappschuss-Anzahl vorgeben, bei deren Erreichen Rsnapshot die ersten Aufzeichnungen automatisch wieder überschreibt. So läuft die Platte nicht über und dennoch ist immer eine länger zurückreichende Historie an Momentaufnahmen vorrätig.

Das Recovery beschränkt sich auf einfaches Zurückkopieren aus einem der gespeicherten Snapshots. So ist die ganze Installation oder nur eine bestimmte Version eines einzelnen File jederzeit restaurierbar. Einfacher geht\’s kaum.

Fazit

Das beschriebene Backup realisiert eine zuverlässige Sicherung, die bis auf das Anstecken der Backupdisk vollautomatisch abläuft, sich dabei flexibel an die Bedürfnisse mobiler Rechner anpasst und außerdem ein einfaches Recovery ermöglicht. Mehr noch: Nach dem beschriebenen Muster lassen sich fast beliebige Aktionen mit beliebigen Geräten verknüpfen. Nach demselben Prinzip könnte der MP3-Player seine Musikverwaltungssoftware starten oder die Kamera den Bildbetrachter.

Genauso eignet sich der Anschluss-Event, um externe Medien auf den Desktop zu holen, und so fort – der Phantasie sind kaum Grenzen gesetzt. Die über den Hardware Abstraction Layer auswertbaren Geräte-Eigenschaften erlauben eine sehr zielgenaue Steuerung und Action-Skripte können komplexe Handlungsabläufe übernehmen.