IBM Tivoli Storage Manager

TSM und ZFS

ZFS ist cool, das Backup eines ZFS mit TSM erinnert an die Steinzeit. Warum kann IBM seinen Backup-Client nicht erweitern, sodass dieser auch in der Lage ist, ZFS zu backupen?

Der Fehler oder das Fehlen scheint länger bekannt zu sein, und seit zwei Versionen des Clients passiert nichts. Irgendwie ist es extrem merkwürdig, dass IBM zuerst ewig braucht, um den Backup-Client für Solaris 10 x64 zu portieren, und dann brauchen sie vergleichbar lange, um ein richtig nettes Dateisystem zu unterstützen.
Wirft man den TSM-Client für ein inkrementelles Backup an, so kann man dies mit „dsmc i“ oder „dsmc incremental“ tun. Der Client schaut darauf in seiner dsm.sys nach, was er so abarbeiten soll, verbindet sich mit dem Server und fängt an, die Daten der verschiedenen Dateisysteme zu senden.

Naja, fast. Er ignoriert dabei sämtliche ZFS-Dateisysteme. Selbst wenn man sie explizit in der dsm.sys drin stehen hat, weigert sich das Teil, auch nur eine einzige Datei ins Backup zu senden. IBM sagt dazu was sehr klares: ZFS wird nicht gebackupt, weil es nicht gebackupt werden soll. (LINK seit Mitte September nicht mehr funktionstüchtig, Dokument nicht mehr zu finden)

Kommt man allerdings auf die Idee, und probiert den Pfad, unter dem das ZFS eingehängt ist, direkt als Parameter an den dsmc zu übergeben, so funktioniert das ganze ohne Probleme. Auch der Restore-Prozess funktioniert so ausgezeichnet.

Also muss man das Backup der ZFS-Dateisysteme über einen Cronjob erledigen, in dem man die einzelnen Mountpoints der ZFS-Dateisysteme als Parameter übergibt – wenig elegant aber effektiv. Natürlich kann man auch ein kleines Skript schreiben, dass sich mittels zfs mount eine Liste der Dateisysteme zusammensucht, diese zusammenkürzt und daraus Parameter für dsmc bastelt.

for mount in `zfs mount | awk ‚$0 ~ /.*\/.*\/.*/ {print $2}’`; do

dsmc i ${mount} -subdir=yes

done

Gut, die paar Zeilen sorgen auch für ein funktionierendes Backup, aber man könnte es wahrlich einfacher haben!

Merkwürdig an der Sache ist, dass dies zum wiederholten Male Ärger mit dem Backup-Client unter Solaris ist. Zunächst brauchte IBM ewig, bis sie einen Client für Solaris 10 x64 (also die 64bit Intel-Variante) auf dem Markt hatten. Einige Admins behalfen sich mit einem historischen Stück Software, welches perfekt funktionierte. Und nun bringt die Konkurrenz ein nettes Dateisystem auf den Markt, dass IBM erstmal nicht verarbeitet. Die Bemerkung von IBM, ZFS können „planmäßig“ nicht gebackupt werden, stammt aus dem Dezember 2006, und im Februar wurde ein Rechtschreibungsfehler entfernt.

UPDATE 5. Oktober 2007:

IBM hat nicht nur den Hinweis entfernt, ZFS würde „planmäßig“ nicht gebackupt werden, sondern es scheint einen neuen Client zu geben, der mit ZFS klarkommt, so schreibt es zumindest mattdey in den Foren von Open Solaris und so kann ich es nach einem ersten Test auch bestätigen. Merkwürdig ist aber, dass IBM es in den Handbüchern zu dem Client nicht „zugibt“ .

OSI-Layer-8

Die Maus quietscht…

Totale Verzweiflung einer Sekretärin, IT-Problem der höchsten Priorität, wegen dessen man den Leiter der IT morgens um 10:00 Uhr anruft: Die Maus quietscht.
Ein weiterer Einsatz für die LART-Peitsche. Könnten Blicke töten, hätte gestern der Leichenwagen kommen müssen. Könnten Blicke zerstückeln, hätte eine große Tüte gereicht. Ich wurde zu einem absoluten IT-Notfall gerufen.

Gegen 10 Uhr ruft mich eine verzeweifelte Mitarbeiterin an: Die Maus ist defekt und sie kann daher nicht arbeiten. Hiwis waren keine da, daher bin ich selbst ausgerückt.

Ich nahm mir also eine Maus aus der Kiste „Mäuse, alt, noch brauchbar“ und ging zu der verzweifelten Dame. Dort angekommen, präzisierte sie das Problem: Die Maus gebe bei Bewegungen sehr laute Quietschgeräusche von sich, welche sie nervlich nicht aushalten könne, sodass sie dringend eine neue Maus benötige.

Ich schaute mir die Maus genau an: Logitech Pilot mit einem Aufdruck „Fujitsu Siemens“ – die muss bei ihrem Rechner dabeigewesen sein, und den hat sie vor vier Wochen bekommen. Eigentlich ein Standartmodell, wie es millionenfach im Einsatz ist. Ich bewegte die Maus; keine Geräusche. Daher bat ich um eine Vorführung: Die Dame drückte daraufhin die Maus derartig stark zusammen, dass es sehr leise, krächzende Geräusche vom Gehäuse gab. Wäre der Drucker angeschaltet gewesen, hätte ich nichts gehört.

Ich versuchte, das Geräusch beim Benutzen der Maus zu reproduzieren. Wenn die Dame echt so stark drückt, und zwar ständig, dass die Maus dabei solche Geräusche von sich gibt, sollte die Damen Unterarme wie Arni haben.

Wie kommt man also auf die Idee, nur weil man gerne eine andere Maus möchte, solch einen Schwachsinn zu machen? Und wieso macht man deswegen so einen Aufstand? Ein Auftrag mit absolut höchster Priorität, nur weil man eine neue Maus will?

Ach ja:Um die Vermutung, das Quitschen sei jenseits meiner Hörschwelle, auszuschließen, habe ich das Teil einem guten Freund aus dem Schall-Labor gegeben. Nichts. Das Gehäusekrächzen hatte übrings 23dB(A), gemessen aus 10cm Abstand.
In Zukunft schicke ich nur noch eine Anleitung: Windows ohne Maus bedienen für Anfänger!

IBM Tivoli Storage Manager

Scheduling von TSM

Der Admin des TSM-Servers der Uni bat mich, unsere Maschinen am Scheduling durch den Server teilnehmen zu lassen und in Zukunft nicht mehr per Cronjob die Daten ‚rüberzuschieben. Die Idee gefällt mir, insbesondere nachdem ich die Lastverteilung des TSM-Servers gesehen habe. Was ist eigentlich so attraktiv an 4:00 Uhr morgens als Zeit für’s Backup? Naja, jedenfalls war er ein wenig entsetzt, als er gelesen hat, dass ZFS und TSM nicht so richtig kooperieren. Damit war die Idee für einige Maschinen erst mal vom Tisch: Alle Maschinen, die irgendwo ein ZFS haben, müssen weiter per Cronjob ihr Backup schieben. Ich war aber so frei, und haben Termine ausserhalb der Spitzenzeiten gewählt.

Die ZFS-freien Maschinen stellen wir jetzt langsam, also eine nach der anderen, auf ge-schedule-tes Backup um. Eigentlich sind dafür nur zwei-drei zusätzliche Zeilen in der dsm.sys notwendig. Anschließend startet man einen kleinen Daemon names dsmcad, der sich dann die Backupzeiten mit dem Server vereinbart und entsprechend den dsmc startet. Ein guter Grund, sich endlich mal mit den Service-Definitionsfiles für das SVC zu beschäftigen, damit dieser Daemon automatisch bei Systemstart gestartet wird.

Schick ist auch, dass man vor und nach dem eigentlichen Ausführen des ge-schedule-ten Backups mit den Paramentern preschedulecmd und postschedulecmd irgendwelche Skripte ausführen lassen kann, beispielsweise um das Viele-MB-Logfile sich zurechzustutzen und als Mail kommen zu lassen.

Zu meiner großen Freude waren diese Optionen auch mal in der Doku sauber erklärt. Daher diesmal ein Lob an IBM, die Doku scheint zumindest an dieser Stelle was zu taugen (unser TSM-Server-Admin fluchte aber über einige andere Kapitel).

Update 31. Oktober 2007:

Da TSM jetzt ZFS anscheinend richtig unterstützt, werden wir nach um nach auch die übrigen Maschinen auf ein Scheduled Backup umstellen. Der Test auf den übrigen Maschinen war sehr erfolgreich, durch das Scheduling haben sich die Backup-Dauern stark verkürzt.