Seite 4: Schnell entsorgt

Inhaltsverzeichnis

Altlasten

Lotus-Domino-Server haben einen Adminp-Prozess, der sämtliche administrativen Aufgaben in eine Datenbank schreibt und diese später ausführt. Lange vor meiner Zeit hatte mein Vorgänger einige Postfächer falsch angelegt und deren Löschung wieder über Adminp in Auftrag gegeben. Adminp-Aufgaben müssen Admins jedoch bestätigen, was für diese Aufgaben nicht passierte – letztlich standen sie in den kommenden drei Jahren in der Warteschlange.

Diese Woche habe ich den Adminp-Prozess per Hand angestoßen und somit alle ausstehenden Verwaltungsanfragen ausgeführt. Leider habe ich versäumt, den Inhalt der Warteschlange zu überprüfen: Die alten Verwaltungsaufgaben taten, was sie sollten und löschten ungefähr zehn Mail-Datenbanken, leider auch einige der Chefs.

Spiegelei

Jeder Administrator entwickelt eigene Strategien, die dem laufenden Rechnerpark vor den Unbilden von Updates sichern sollen. Arbeitet beispielsweise ein Server mit zwei per RAID-1 gespiegelte Platten, lässt sich eine davon vor Updates entfernen. Schlägt die Software-Aktualisierung fehl oder geht sonst irgendetwas daneben, baut der Admin die zweite Platte aus, legt sie beiseite, schraubt die erste Platte wieder ein und startet den Rechner neu. Anschließend kommt die zweite Platte wieder ins RAID, das sogleich die von Platte 1 auf Platte 2 spiegelt und damit den Zustand vor dem Update wiederherstellt. Diese Verfahren klingt praktikabel, stößt jedoch dann an Grenzen, wenn man gleichzeitig zwei Server mit identischen Platten aber unterschiedlichen RAID-Controllern aktualisieren will.

Nun kam der Tag, an dem zwei Systeme in Abhängigkeit voneinander aktualisiert und getestet werden mussten. Aus beiden Systemen wurden je eine Platte entfernt und mehr oder minder erfolgreich aktualisiert. Ein nachfolgender Funktionstest ging schief, sodass das Restore-Szenario durchgeführt werden musste. So kam es, wie es kommen musste: Die Platten wurden vertauscht und in das jeweils andere System installiert. Das Problem: die Server waren zwar vom gleichen Hersteller, hatten auch das gleiche Chassis, allerdings völlig unterschiedliche RAID-Controller, die mit den anderen Platten nichts anfangen konnten.

Eins plus eins gleich eins

Eine Uni Mitte der 80ziger, drei Rechner mit Apollo Domain OS und ich, ein recht frischer Administrator. Meine erste Aufgabe: Zwei Maschinen mit 512 MByte Speicherplatz gegen eine neue mit einem (!) GByte tauschen. Die Daten der beiden alten sollen zusammen auf dem neuen landen, damit die alten für andere Arbeitsgruppen eingesetzt werden können. Ich sollte das nachts erledigen, damit am morgen die Arbeit ohne Unterbrechung weitergehen kann.

Als alle auf dem Heimweg waren, tippte ich in einem Fenster mit eingefrorenem Eingabepuffer folgende Befehle untereinander weg:

cp -r //node_a/DATA/* //node_c/DATA/  
cp -r //node_b/DATA/* //node_c/DATA/
rm -r //node_a/DATA/*
rm -r //node_b/DATA/*

Damals gab es noch nicht so viele Sicherheitsmaßnahmen, wie die auf "rm -i" gealiasten rm-Kommandos in den heutigen Linux Distributionen. Ein Kommando tat genau das, was man schrieb. Nicht mehr, aber auch nicht weniger.

Ich warf noch einen zweiten Blick auf die Kommandos, war zufrieden und hob die Einfrierung auf. Das erste Kopierkommando lief, und die wiederholte Ausmessung des geringer werdenden Plattenplatzes in einem zweite Fenster ergab eine restliche Ausführungsdauer von etwa einer Stunde. Also genügend Zeit für ein Weizenbier und eine Pizza. Gerade da, als das Bier bestellt war, blitze mir ein Gedanke durch den Kopf: "Was macht cp eigentlich, wenn eine Datei schon vorhanden ist?" Ich wusste es nicht, zahlt die Rechung und bewegte mich in Richtung Campus. Wenige Minuten später las ich die Antwort, die sinngemäß etwa so lautete:

> cp -r //node_a/DATA/* //node_c/DATA/	
successful
> cp -r //node_b/DATA/* //node_c/DATA/	
error "Keine Methode zur Behandlung von Zielkonflikten angegeben. Befehl wird 
abgebrochen."
> rm -r //node_a/DATA/*  
successful
> rm -r //node_b/DATA/*  
successful

Ich hatte also eine saubere Kopie des ersten Servers und einen sauberen zweiten Server. Die Nächte der nächsten Wochen verbrachte ich damit, ein Vollbackup und die über 100 darauf aufbauenden inkrementellen Backups einzuspielen. Ich habe von diesem Tage an nie wieder einen rm-Befehl über den Kommandozeilenpuffer abgeschickt, bevor alle vorangehenden Aktionen überprüft und erfolgreich abgeschlossen waren.