So lautet unserer Meinung nach, die wichtigste Regel für alle, die in der IT Branche tätig sind. Dies ist absolutes A und O für alle Systemadministratoren. Und genau diese Regel wird meistens in der heutigen IT-Umgebung missverstanden oder sogar bewusst ignoriert.
Mehr als 60% aller RAID-Systeme, die wir zur Diagnostik und Datenrettung erhalten, werden mitten in der Nacht zu uns ins Labor geliefert. Dies hängt damit zusammen, dass oft aufgrund falscher Vorgehensweise der IT-Techniker bei RAID-Systemen anstatt einer saubereren Fehlerbehebung zu den weiteren Schäden kommt.
Ein Beispiel, das vor ein paar Monaten wir hatten, betraf ein RAID 10 System. Die Administratoren einer Webhosting Firma wollten an einem späten Abend den Server mit 4 Festplatten (Striping – Mirror) in ein neues Server-Rack übertragen. Damit zahlreiche Webseiten weiter online abzurufen wären, haben sich die Administratoren entschieden, den RAID-Server im laufenden Betrieb zu übertragen. Ziemlich viele, die schon für die Administration von betriebsrelevanten Systemen verantwortlich waren, kennen aus eigener Erfahrung, dass solche Aktionen nicht immer gut enden können. So war es auch. Bei dem Umzug ist der Server einem der Administratoren von der Hand abgerutscht und auf den Boden gefallen. Die Festplatten waren in dieser Zeit im laufenden Betrieb.
Bei RAID 10 System handelt es sich um eine Kombination aus zwei RAID 0 Striping Systemen, die zu einem RAID 1 Mirror System zusammengefasst wurde. Zwei Festplatten aus dem laufenden Array wurden mechanisch beschädigt. Auf den beiden 1000 GB Festplatten wurde Head Crash übelster Sorte diagnostiziert.
Das schlimme daran, dass 2 Festplatten (1 und 2) aus genau einer RAID 1 Array nicht mehr betriebsfähig wurden. So hatten wir mechanische Beschädigung nicht einfach von einem RAID Mirror, das ohne die Datenrettung verschmerzt werden konnte, sondern ein Ausfall vom essenzielen RAID-0 Stripe. Somit wurde eine komplette Datenwiederherstellung von einem RAID-10 vorgenommen, der nicht nur mechanisch, sondern auch anschließend vom RAID-Controller logisch degraded wurde.
Ein Glück, dass die magnetischen Oberflächen nach dem Head Crash fast unbeschädigt geblieben sind. Erst nach dem Sturz wurde der Server ausgeschaltet.
In 12 Stunden konnten wir beide Festplatten erfolgreich auslesen, dass RAID 10 Level softwaremäßig implementieren und anschließend alle Daten extrahieren bzw. sichern. So schnell und erfolgreich endet aber nicht jede Datenrettung von physisch beschädigten Raid (0, 5, 6, 10, 20) Verbunden.
Eine wichtige und gute Sendung Eine kurze Beschreibung, wie ich es deiahm mit Datenhaltung halte was wahrscheinlich ffcr viele Anwendugsfe4lle ausreichen sollte:Mein kleines mini-NAS (bisher 250 GB inzwischen 1 TByte) stellt einen FileShare zur Verffcgung, auf den ich von jedem Arbeitsplatz zugreifen kann.Weder die PCb4s noch der NAS-Server haben eine direkte WEB-Verbindung. WEB gibts nur in einer VMWare. Datenmaustausch nur per Drag und Drop. Das ist zwar nicht fcberme4dfig schnell Aber: Sex ohne Gummi ist auch immer schf6ner, daffcr aber gefe4hrlich ;-)Ffcr ein WEB-Game muss dan halt ein separates Betriebssystem ohne Datenzugriff her Zurfcck zur Sicherung vom NAS-Server:Die Daten, die selbst nur Kopien sind (z.B. Backups von einem Transportablen Datentre4ger oder Notebook) werden nicht mehr gesichert.Nicht sicherungswfcrdige Daten (z.B. Images und VMWares) bleiben lokal und werden ggf. nur sporadisch manuell als Backup auf das Fileshare fcbertragen.Alle sicherungswfcrdigen Daten werden per robocopy-Script (ggf. auch mehrmals te4glich) auf einen geeigneten Arbeitsplatz zurfcckkopiert, der dies selbst initiiert (Scheduled Task). Das kann sogar meine Frau manuell starten, wenn sies will (;-). Damit sind regelme4dfig alle Daten gesichert und der Ausfall von Platten ist damit zwar e4rgerlich, aber nicht mehr irre teuer.Mit diesem Szenario kf6nnen auch aus Versehen gelf6schte Dateien wieder vom Backup-Pfad schnell einfach und sicher wieder hergestellt werden. (Wer schnelle Finger hat, wie ich , braucht das hin und wieder shcon mal – man muss nur wenn was passiert ist gleich ran und darf dies nicht auf die lange Bank schieben)Ffcr wirklich wichtige Daten, die nicht wiederhergebracht werden kf6nnen (eigene Dokumente), werden dann hin und wieder DVDb4s gebrannt und extern gelagert, damit bei einem Gott bewahre uns davor Brand oder vergleichbarem dcbel -wenigstens das Wichtigste zwar nicht unbedingt tagesaktuell aber doch noch brauchbar vorhanden ist.Einmal im Monat wird das Share per Miror-Script auf das Backup geschrieben und damit die File-Struktur erneuert und alle fcberflfcssigen Files dann entfernt. Dann hat man wieder einen konsistenten Stand. Im ungfcnstigen Fall hat man beim Ausfall dann ggf. ein paar Daten zuviel im Backup und ein paar Stunden Arbeit damit kann man in der regel aber gut leben. (dcblicherweise gibts bei solchen Gelegenheiten ein Budget ffcr ne grf6dfere neue PLatte ;-)Meine Backup-PLatte hat fcbrigens nur 250 GByte und reicht locker daffcr aus und ffcr wen das nicht reicht, der kauft einen zweiten NAS-Server mit gleicher Platte und repliziert zwischen diesen beiden direkt. (Gute NAS-Serverleinchen kf6nnen das wohl)dcbrigens ist m.E.n. Ordung im Filesystem mindestens genau so wichtig wie eine regelme4dfige Datensicherung Ich wfcnsche allen, die regelme4dfig sichern, dass sie die Backups nicht oder seltenst benf6tigen {und die die dies nicht tuen werden es irgendwann bereuen und daraus lernen)