Die vermeintliche Sicherheit

... oder warum ein RAID das Backup NICHT ersetzt.

oder warum ein RAID das Backup nicht ersetzt.

Da habe ich nicht schlecht gestaunt, als sich mein E-Mail-Client vorgestern meldet, und ich eine Nachricht von einem meiner Root-Server "im Kasten" habe. - Schon der Betreff ist höchst beunruhigend: Von einem  "degraded RAID-Array" ist dort die Rede.
 

RAID?!? - kurz für Nicht-Techniker: 

In einem RAID werden mehrere Festplatten zusammengeschlossen, um die
Kapazität zu vergrößern oder (der Hauptgrund) Datenverlust vorzubeugen,
indem alle Daten z.B. redundant gespiegelt auf den Platten liegen.
Fällt eine Platte komplett aus, sind die Daten noch vorhanden und die
Maschine kann sogar weiterlaufen.

Mit anderen Worten, teilte mir mein Server mit, dass soeben eine der zwei Festplatten wegen eines Fehlers aus dem RAID-Verbund entfernt wurde. :O

-

Nun gut, das lässt mich natürlich nicht kalt. Schließlich handelt es sich um meinen Cloud- und Mailserver!
Da es auch harmlose Gründe geben kann, weshalb eine Festplatte aus dem Verbund entfernt wird, will ich via Konsole übers Netz nach der Ursache forschen ... *PLING* noch drei E-Mails, die mir mitteilen, dass auch die restlichen drei Partitionen der Festplatte aus ihren jeweiligen Verbünden gekickt wurden.

Schweiß auf der Stirn 

Etwas hektisch parallel im Browser gecheckt, ob der Server noch online ist und via SSH auf dem Server eingeloggt. Sieht alles noch OK aus. Schnell die Logs checken: Yo, die Festplatte ist raus aus dem Verbund (Warum sollte mich der Server auch anlügen ...). 

Kurzerhand die Partitionen wieder in denn Verbund eingefügt. *PLING* ... noch während ich am Einfügen bin, fliegt die erste Partition wieder raus.

Mehr Schweiß ... nicht nur auf der Stirn

Da liegt etwas "ernstes" vor! Schnell mal den S.M.A.R.T.-Status auslesen. *GULP* - Der Status kann "aus Gründen" nicht angezeigt werden! :O

... hektisches Tastengeklapper ... mehrfache Wiederholung der Anfrage (die Hoffnung stirbt zuletzt) ... AH! endlich ... der Status:
Diverse Fehler bei Schreib-/Lesezugriffen innerhalb der letzten Stunden. ... irgendetwas mit IO (Input / Output)

ui ... ui ... ui   ... mit jedem Aufruf des S.M.A.R.T.-Monitors steigt die Fehlerzahl. - Die Platte dürfte im Eimer sein! 


Was jetzt?!? - Den Server mit einer Platte weiterlaufen lassen? - Schlechte Idee.

Zum Einen synchronisieren sich permanent diverse Mail-Clients und Kalender mit meiner Cloud und zum Anderen laufen permanent Statistikdaten dort ein. -> andauernder HD-Zugriff = LAST.

OK, schnelle Entscheidung: Alle Serverdienste stoppen, den Backup-Mechanismus manuell anstoßen und schon werden per rsync alle Daten und Konfigurationen auf zwei andere Server gesichert, zusammen mit einem Datenbank-Dump. Das BackUp synchronisiert ohne Fehler.

Da ich ein Fauli bin, versetze ich den Server in den sog. "Rescue-Modus" um "mal eben" ein Image der einzelnen Partitionen zu schreiben, damit ich den Ersatzserver "ohne Arbeit", also in weniger als 30 Minuten wieder ans Netz bringen kann.

... *rödel* *rödel* *rödel* (Images über das Netz auf einen anderen Server schreiben)

... uuuuups! ... IO-Error ... F#CK ... hm, ein Image fehlgeschlagen ... neuer Versuch ... uuups! .... wieder fehlgeschlagen ... negativ belegter Gesichtsausdruck

Der Aufruf des S.M.A.R.T.-Monitors für die zweite Platte bringt es an den Tag ... auch hier treten die ersten Schreib-/Lesefehler auf. ... die Images kann ich vergessen und damit die enthaltenen Daten auch!


Nach ein paar weiteren Versuchen gebe ich, angesichts steigender Fehlerzahl, auf und richte den Ersatzserver mit einem Betriebssystemsabbild ein. Da mir etwas die Zeit fehlt, verschiebe ich das Einrichten der Dienste und Import aller Daten auf den nächsten Morgen (eingehende E-Mails sollten nicht verlorengehen, da Mails i.d.R. fünf Tage lang zugestellt werden).

Durch das BackUp der Konfigurationsdateien (und die regelmäßigen Updates des Servers) kann ich den kompletten Server und alle Dienste in 2 - 3 Stunden wieder an den Start bringen. - Puuuh! Kriese abgewendet! :D 

Natürlich haben mir die BackUps nicht die Arbeit der Neueinrichtung erspart, aber zumindest brauchte ich bei der Konfiguration nicht von vorne zu beginnen und nur ein paar Werte anpassen ... und viel wichtiger: KEIN DATENVERLUST!!!

Was lehrt uns das? - Auch ein RAID befreit nicht von der Pflicht zum BackUp.


Natürlich ist es total unwahrscheinlich, dass alle Disks eines RAIDs innerhalb kürzester Zeit ausfallen

... ABER ... UNWAHRSCHEINLICH heißt NICHT UNMÖGLICH (z.B. wenn der Controller defekt ist)!

Hätte ich das BackUp nicht nochmal synchronisieren können, dann hätte ich maximal die Daten seit dem letzten BackUp-Zeitpunkt verloren ... das wäre schon ärgerlich genug gewesen.

Tut euch selbst einen Gefallen und richtet automatische BackUps, z.B. via rsync ein und vertraut nicht darauf, dass ihr die Daten noch kopieren könnt, wenn ein RAID-Laufwerk ausfällt. ... bei mir hätte es nicht mehr geklappt! - Der Ratschlag gilt übrigens auch für Desktop-Rechner, Laptops oder mobile Devices.

Ein kleines Erlebnis aus dem Alltag eines "IT-Typen"

In diesem Sinne

Maik

Ehe die Frage kommt: Ich hab meine Root-Server bei der Hetzner AG und bin äußerst zufrieden.
(Ja, es gibt billigere ... und nein, ich bekomme für den Satz GAR NICHTS)

Stichwörter: , , , , , , ,

Noch kein Kommentar

(optionales Feld)
(optionales Feld)
Persönliche Informationen speichern?
Hinweis: Alle HTML-Tags außer <b> und <i> werden aus Deinem Kommentar entfernt. URLs oder Mailadressen werden automatisch umgewandelt.