Hallo zusammen!
Dieser Artikel richtet sich hauptsächlich an die Systemadmins unter euch:
Ich suche für ein Referat an meiner HTL für EDV ein paar Infos über Desaster. Es wär nett wenn ihr mir ein paar Beispiele geben könntet, was euch so passiert ist, warum es passiert ist, und welchen Schaden es angerichtet hat, bzw. es anrichten hätte können.
mfg Ewald Moitzi
Dann fang’ ich mal an
Natürlich ohne jeden Anspruch auf Vollständigkeit:
Was: Beim Umzug von Mailkonten unter einer alten GroupWise-Version wurde Konto bearbeitet, bevor der Server mit dem Umschaufeln fertig war.
Warum: Schlechte Dokumentation, Bedienungsfehler, untauglicher Backup
Schaden: Komplettverlust aller Termin- und Maildaten.
Was: Nach Server-Headcrash wurde beim Recovery-Versuch festgestellt, dass sämtliche Bänder unbauchbar waren.
Warum: Aus Zeitgründen war bei Sicherung auf Verify verzichtet worden (Streamer zu lahm, „Nacht“ zu kurz). Im Backup-Prozess waren zwar Bandgenerationen, aber keine Lifetime-Zyklen definiert. Dies führte dazu, dass Bänder jahrelang genudelt sind…
Schaden: Komplettverlust Daten auf diesem Server.
Was: Totalausfall externes Raid-Array
Warum: Bei der Auslegung des Array war ein einziger single-point-of-failure übersehen worden - und natürlich fiel just dieses Teil aus und musste aus Amerika eingeflogen werden.
Schaden: 3 Tage Systemstillstand
Was: Misslungene Datensicherung auf Datenbank-Server
Warum: Bedienungsfehler: Software verlangte „Bitte legen Sie das nächste Band ein und drücken sie eine beliebige Taste“. User drückte aber NUR die Taste („Es lief dann doch…!“).
möglicher Schaden: Komplettverlust Datenbank
Wie du siehst, hauptsächlich „Unfälle“ die mit Backup zu tun haben.
Gruß
Stefan
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hab ich noch ein schönes Beispiel:
Novellserver: Platten laufen seit 5 Jahren, Dientleister weist darauf hin, dass der Austausch überfällig ist, Kunde reagiert nicht, da ja Datensicherung vorhanden…
Ca. 6 Monate später Plattenausfall (Kein Raid…).
Just seit zwei Wochen läuft der Backup nicht mehr, was der Administartor übersehen hat…
Schaden: 40 'Stunden Dauereinsatz von zwei Technikern des Dienstleisters (Schicht rund um die Uhr) um die Daten von der defekten Platte herunter zu holen, zwei Tage Systemausfall, Verlust von (zum Glück nur) 5 Dateien.
Also aus Kostengründen gescheut die Platten auszutauschen + menschliches Versagen, => ca. 20-fache Kosten (rein Techniker und Hardware im Vergleich zum Plattentausch) durch GAU verursacht + die Ausfallkosten von 50 Mitarbeitern, die alles per Hand machen mussten, was bei diesem Kunden zum Glück noch möglich war (ich möchte nicht dran denken wenn…)
Aber (nur ?) durch Schaden wird man klug…???
Bernd
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Ich suche für ein Referat an meiner HTL für EDV ein paar Infos
über Desaster. Es wär nett wenn ihr mir ein paar Beispiele
geben könntet, was euch so passiert ist, warum es passiert
ist, und welchen Schaden es angerichtet hat, bzw. es anrichten
hätte können.
Hallo Ewald!
Noch zwei Fälle für Deine Statistik:
Was: Ausfall einer Platte in einem RAID-5 (eigentlich kein Problem). Absturz des Systems nach Austausch der Hot-Swap Platte beim Versuch, die „verlorenen“ Daten zu rekonstruieren.
Warum: Fehler auf dem RAID-Controller
Schaden: Datenverlust bis zum letzten Backup (1 Tag), Serverausfall für zwei Tage - danach hat der Techniker das RAID inkl. Controller ausgetauscht und die Daten abgeschrieben.
Was: Ausfall eines Novell-Servers nach Abschalten der USV. Der Server sollte wegen bevorstehender Stromabschaltung heruntergefahren werden. Ein Admin entschied sich, die USV zuerst auszuschalten. Obwohl noch Netzspannung vorhanden war, schaltete der Server unkontrolliert ab und zeigte bei einem Neustartversuch keine Reaktion mehr.
Warum: Schlechte Dokumentation der USV, Ursache für die Startprobleme des Servers bis heute unbekannt. Alle Komponenten überprüft, Mo Abend wieder zusammengebaut: läuft.
Schaden: Serverausfall von Fr-Mo
CU
Markus
Hi,
Also:
Nur als Hinweis: Diese Faelle habe ich nicht live erlebt, aber als Supportmitarbeiter wurde ich natuerlich von den Technikern dann angerufen (also nicht mich beschimpfen 
Ausfall der Klimaanlage im Rechnerraum
Danach waren ca 70 grad im Serverraum. Zum Glueck fuhren die
Sun Server runter. (Mit viel Glueck haben es auch die MODs ueberlebt) Aber der Techniker hat sich am Tuergriff die Hand
verbrannt
Der Oops Faktor : Techniker gibt sql statement in datenbank ein. Dies wird vom Entwickler ueber telefon diktiert !
Natuerlich wartet er nach dem „delete from XXX“ nicht auf die where clause und drueckt return (oops)
Danach war ein gutes Backup gefragt. Der Entwickler brauchte trotzdem 3 Tage um das System wieder richtig am laufen zu haben.
Servercrash ruiniert Oracle Datenbank. Backup wurde natuerlich immer nur sporadisch auf ein Band gemacht und noch dazu fehlten wichtige Dateien. Selbst Oracle brauchte 1 woche um die datenbank wieder zum laufen zu kriegen
Hier noch allgemeine Beispiele die einem im Cluster Kurs erzaehlt werden:
Olli
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Ha! Einen hab’ ich noch:
Eher was zum Schmunzeln aus der Reihe „Anekdoten und Schmonzetten“:
War in grauer Vorzeit. Wir hatten unser erstes AIX-System im Produktionsbetrieb - ca. 200 User. Alles etwas hemdsärmlig und an allen Ecken und Enden improvisiert.
Beispiel: Eine selbstgestrickte „Hackersicherung“. Nur Benutzer, deren IP-Adresse in der hosts stand, wurden akzeptiert. Dazu wurde per Skript ein entsprechender Abgleich mit der Datei durchgeführt. So weit so gut…
Es begab sich zu dieser Zeit, dass wir das erste Mal von DNS hörten. Das wäre doch eine Super-Idee - gleichmal ausprobieren. Leider hat unser AIX-Admin aus Versehen nicht den DNS-Server gestartet sondern das System auf DNS-Client umgestellt. Woraufhin das schlaue System meinte: „Ach, wenn ich jetzt meine Namen über DNS beziehe, brauche ich ja keine hosts mehr…“ Gesagt, getan: Weg war die Datei (ehrlich! selbstständig!). Die Konsequenzen in Bezug auf die „Hackersicherung“ kann sich der geneigte Leser selber ausmalen. Natürlich kam der Admin erst drauf, als er sich selber testweise neu anmelden wollte.
Schaden:
* ca. 2 Stunden lang konnte sich niemand mehr anmelden
* Admin erlebte die hektischsten 2 Stunden seines Lebens, bis er (über die serielle Konsole) alles wieder restauriert hatte
* Admin bekommt auch heute noch Flecken im Gesicht, wenn der Begriff „DNS“ fällt (u.a. weil dann jeder in der Abteilung prustet…)
Gruß
Stefan
ein herzliches Schankedön!
Danke für die Beispiele, wird mir sicher helfen
mfg Ewald Moitzi