Achtung! Die Howtos stammen aus der Zeit vor 2006 und sind nur noch aus historischen Gründen online!

ADSM/TSM unter (Free|Open)BSD

Dies soll keine Einführung in die Verwendung von ADSM/TSM sein, sondern nur zeigen, wie man es auch unter *BSD nutzen kann. Grundlegende Informationen zu ADSM/TSM finden sich unter:

http://www.tivoli.com/products/index/storage_mgr/

ADSM/TSM ist ein Client/Server-Backup-System, das sich durch folgendes auszeichnet:

Automatisiertes, inkrementelles Backup
große Anzahl unterstützter Plattformen auf Clientseite
gute Performance durch Zwischenspeichern der Daten auf Diskvolumes
Flexibilität bei der Einrichtung unterschiedlicher Backupstrategien
undurchsichtige Lizensierung - sauteuer

Der zweite Punkt ist allerdings hinterfragbar - speziell für uns:

Für BSD gibt's nix. Als Lösung bietet sich nur die Verwendung eines Clienten für eine andere Plattform im jeweiligen Emulationsmodus der BSDs an. Aufgrund bestimmter Erfahrungen (davon später) habe ich mich für einen Uralt-Client (version 2) für sco entschieden. Wie der zum Laufen zu bringen ist, davon handelt die folgende Geschichte.

Installation

Das Programm kann von ftp://ftp.wu-wien.ac.at/pub/adsm/fixes/v2r1/sco/ bezogen werden, und befindet sich in den Dateien: ip21201.3d[1-3]bin.

Dies sind normale tar-Archive. Ausgepackt werden sie am besten nach /usr/adsm:

# cd /
# for i in <Pfad zu Archiven>/ip21*; do tar xvf ${i}; done

für sh, bzw. für csh:

# cd /
# foreach i ( <Pfad zu Archiven>/ip21* )
? tar xvf ${i}
? end

Die dabei enstandenen Dateinen in /tmp kann frau getrost ignorieren oder löschen.

Emulation

Vorweg: ibcs2-support muss eingeschalten sein. Also:
Freebsd: ibcs2_enable=YES in /etc/rc.conf
OpenBSD: im GENERIC-Kernel ist ibcs2-support fix integriert.

SCO speichert Informationen über gemountete Dateisysteme in der Datei /etc/mnttab, die sich mit folgendem perl-Skript:

ftp://vodka.wu-wien.ac.at/pub/adsm/mtab2mnttab.pl

aus /etc/fstab generieren lässt.

Dieses habe ich aus einem alten Linux-ADSM.HOWTO geklaut und ein paar Fehler mehr eingebaut. Eine Ungereimtheit darin ist allerdings original. Wer sie findet darf's mir per email mitteilen und nichts gewinnen. (Oder bis zu Ende lesen, wo sie noch eine Rolle spielen wird.)

Doch nun zu Heiterem:
SCO ist ein Abkömmling des Hauses SystemV, und als solcher socketlos. (Die haben da 'was anderes: Streams.) - Nun, nicht ganz. Es existiert ein Socket-API, eine Schnittstelle zu Streams. Und es existieren spezielle devices für diese Schnittstelle, von denen für uns nur /dev/socksys wichtig ist.

Ich habe mir die IBCS2-Emulation nicht wirklich angesehen, weiß daher nicht, was wie wirklich geschieht, sondern nur, dass sco-Programmen, soferne sie netzig aktiv werden wollen, dieses device brauchen. Richten wir es also ein

# ln -s /dev/null /(emul|compat)/ibcs2/dev/socksys

(/emul: OpenBSD; /compat: FreeBSD)

Was immer von diesem device sonst noch erwartet wird: Null reicht für den Betrieb völlig aus (Nichts wäre zuwenig).

Konfiguration

Unter /usr/adsm finden sich nun sowohl die binaries, als auch Beispiele für Konfigurationsdateien: dsm.sys.smp und dsm.opt.smp. Die werden nach (erraten!) dsm.sys und dsm.opt kopiert und könnten nach Bearbeitung in etwa so aussehen:

dsm.sys:

SErvername  <Irgendein schmucker Name>
   COMMmethod         TCPip
   TCPPort            1500
   TCPServeraddress   <Hostname des ADSM-Servers>
   nodename           <dein Nodename>
   passwordaccess     generate
   inclexcl           /usr/adsm/excl.list
   virtualmountpoint  /usr/ports
   virtualmountpoint  /usr/src

dsm.opt:

domain / /usr /var /home

excl.list (die verhindert, dass der Client jeden Schrott sichert):

exclude /.../*
include /etc/.../*
include /var/.../*
include /home/.../*
exclude /.../tmp/.../*
exclude /.../.netscape/cache/.../*
exclude /.../*core

Zu allen möglichen weiteren Optionen fragen Sie Ihr Manual oder Ihre ADSM-Administratorin (wir freuen uns immer, wenn wir zur Clientkonfiguration befragt werden).

Betrieb und seltsame Erscheinungen

Aber jetzt:

# cd /usr/adsm
# ./dsmc incremental

Passwort wird korrekt eingegeben, alle in dsm.opt angegebenen Dateisysteme werden durchforscht und wenn nötig gesichert. Nach einer bis 60 Minuten (oder mehr) sollte der Spuk vorbei sein.

Sehen wir, was er gesichert hat:

# cd /usr/adsm
# ./dsmc query filespace

Und das sieht dann so aus:

Num     Last Incr Date      Type    File Space Name
---     --------------      ----    ---------------
  1   05/28/2001 00:11:17   ¤Ú¿ßÌÉ¿ßèÉ¿ß£`   /           
  2   05/28/2001 00:14:55   
                            º¿ßÅA   /home       
  3   05/28/2001 00:12:40   P·¿¿ A   /usr        
  4   05/28/2001 00:13:17   P·¿¿¤A   /var

Davon abgesehen, dass ich wieder einmal sichern sollte, scheint der Client seltsame Ansichten darüber zu hegen, was ufs/ffs sein sollte. Das Problem ist: er weiss es wirklich nicht. Auch nach im Web einsehbaren man-pages wird diese Information in /etc/mnttab nicht gespeichert, zumindest wurde es dies früher nicht, die Manuals neuerer OpenServer- und UnixWare-Versionen scheinen auf anderes hinzudeuten. Warum diese Information trotzdem von mtab2mnttab.pl ausgelesen wird, habe ich den Autor nicht gefragt.

Unbrauchbar ist das Ergebnis des Backups trotzdem nicht: Der Client holt die Daten auf jeden Fall auch wieder zurück, liefert sie ans Dateisystem aus, dem es wiederrum schnurz ist, was der Client glaubt, das er da zurückliefert. Da ich nicht weiß, ob SCO über ufs/ffs überhaupt Bescheid wissen kann, bin ich auch nicht imstande an dieser Stelle anzugeben, ob diese Prozedur trotz oder wegen Tarnen und Täuschen funktioniert - es klappt auf jeden Fall.

Gibt's da nix besseres - für Linux etwa?

Gut, der Linuxclient läuft auch, jedoch hatte ich damit unter FreeBSD3x eine etwas unerfreuliche Erfahrung. Das Problem war, dass der gute ADSM-Client (version 3.1) zwar sauber lief, jedoch irrigerweise annahm, meine hübschen mountpoints / /usr /home /var zunächst unterhalb von /compat/linux, wo er sich nicht ganz zu unrecht zu Hause wähnte, suchen zu müssen. Fand er dort ein gleichlautendes Verzeichnis, was so schwer nicht war, pfiff er auf das System, das ihm Wohnrecht gab, lies die Dateien, deren Sicherung ihm eigentlich anempfohlen war, wo auch immer liegen, und hinterlies am Server ein nicht gerade üppig ausgestattetes Linuxsystem.

Tja, so war das. So bin ich auf den SCO-Client gekommen.