2. Festplatte während Rebuild kaputt gegangen

L

lyn2k9

Member
Guten Abend liebes Forum,

heute morgen hatte ich bei einem Hetzner Server eine defekte Festplatte tauschen lassen. Neue wurde eingebaut, partitioniert und ich habe das Rebuild des Raid angeworfen.

Im laufe des Tages muss es dann wohl auch noch die zweite "alte" Festplatte erwischt haben. Ich bin mir jetzt nicht sicher ob bis dahin das Raid wieder vollständig syncronisiert hat!?

Was momentan passiert ist. Lara Console hatte ich am Server. Die zweite Festplatte ist definitiv hinüber. Im Rescue Modus komme ich noch auf die Daten vom Server. Ein sauberes Booten funktioniert nicht.

Backup ist vorhanden. Ich hoffe da fehlt nix :) Bzw. Ich kann ja theoretisch noch prüfen ob was fehlt, da ich Datenzugriff habe

Wie würdet ihr jetzt weiter vorgehen?

Ehrlich gesagt möchte ich den Server nicht unbedingt neu aufsetzen, nachdem ich die zweite Festplatte tauschen lassen habe.

Kann man prüfen ob der Rebuild vollständig war? Ich habe es gegen 9 Uhr gestartet. Wenn es mit 100MB/s gelaufen ist, dann müsste ich die 2,9 TB in 8h geschafft haben, wo ich mir aber unsicher bin!

Schönen Abend

Lyn

PS Ein Hoch auf Murphy's law
 
Ob er die 100MB/s durchweg halten konnte, wage ich zu bezweifeln. Sobald das System irgendwas von den Platten will und sei es nur ein Bild via Webserver auszuliefern, wird die Rebuild-Geschwindigkeit deutlich einbrechen.
Jenachdem wie oft dann andersweitige Zugriffe erfolgen ist es mehr oder weniger unwahrscheinlich, dass er die 100MB/s halten konnte. ;)

Das er nicht bootet, könnte 3 Ursachen haben:
  • Du hast vergessen den Boot-Loader neu zu schreiben, als du dich um die neue Platte gekümmert hast
  • Im Bios ist konfiguriert, dass er nur von einer Platte (der nun defekten) booten darf
  • Das RAID war wohl doch noch nicht fertig mit Syncen und nun fehlen ihm Daten

Was heißt denn "er bootet nicht"? Grub da? Kein Kernel da? Fehlermeldung? Lara/KVM hattest du doch nun schond ran. Da sollte etwas mehr bei rauskommen als "geht nicht". ;)

Was den Rest des Filesystems betrifft...
Noja, du könntest einen Filesystem Check drüber laufen lassen. Bei nicht vollständig gesynctem RAID, wird der dir die Konsole mit unendlichen Fehlern vollspammen. Wenn es da nichts ausser ein paar orphaned Inodes und vielleicht ein paar Inodes die beim Crash gerade geschrieben wurden, kommt, solltest danach mal mounten und schauen ob der Füllstand der Partitionen mit dem übereinstimmt, was vorher drauf war. :)
Auch ein "ls -laR" über / kann manchmal recht hilfreich sein. Ein FSCK findet nicht immer alle Fehler. Manchmal tauchen dann einfach im Betrieb Dateien auf, deren restlichen Meta-Daten wie Berechtigungen, Modification Time, usw. unbekannt/defekt sind und entweder völlig falsch wiedergegeben oder mit ??? angezeigt werden.
In diesen Fällen würde ich definitiv zum Backup-Restore raten. Solche Inkonsistenzen bei 3TB Daten zu finden, ist mühsam. ;)
 
Firewire2002 said:
  • Du hast vergessen den Boot-Loader neu zu schreiben, als du dich um die neue Platte gekümmert hast
  • Im Bios ist konfiguriert, dass er nur von einer Platte (der nun defekten) booten darf
  • Das RAID war wohl doch noch nicht fertig mit Syncen und nun fehlen ihm Daten

Was heißt denn "er bootet nicht"? Grub da? Kein Kernel da? Fehlermeldung? Lara/KVM hattest du doch nun schond ran. Da sollte etwas mehr bei rauskommen als "geht nicht". ;)
Click to expand...

Also den Boot Loader habe ich auf beide Festplatten geschrieben,

Vermute es liegt wirklich am Raid.

Grub kommt, Kernel läd er auch, dann bleibt er bei der Fehlermeldung (siehe Anhang md.PNG) stehen. So wie ich das sehe ist das Raid nicht fertig und somit die Patitionstabelle fehlerhaft.
 

Attachments

  • md.PNG
    md.PNG
    65.7 KB · Views: 251
  • grub.PNG
    grub.PNG
    57.9 KB · Views: 243
COMRESET Failed.. Den Fehler kenne ich doch. Die alte Platte ist hinüber.
 
oh mann. Ich scheine echt Glück gehabt zu haben.

Ich habe mich entschlossen die Platte tauschen zu lassen. Backup war ja vorhanden bzw. das eventuell inkonsitente von der neuen Festplatte.

Der Austausch ging fix. Partitionstabelle drauf, Rebuild gestartet, Reboot und ....

yeaahhh er läuft :D

Jetzt kipp ich restmal ein Bier! Euch einen schönen Abend

EDIT: Ich hoffe von euch hat keiner das Pech, dass zwei Festplatten an einem Tag wegsterben! Übrigens waren vor dem Ausfall zwei Seagate Platten verbaut. Jetzt eine Seagate und eine TOSHIBA
 
Last edited by a moderator:
Willkommen in der IT WELT!

Ist beim RAID völlig normal. Meistens verreckt mehr als eine Platte. Ich versthe immer noch nicht, dass wir im 21. Jahrhundert immer noch etwas so rückständisches verwenden. Hey, wir waren verdammt nochmal auf dem Mond!

Es gibt mittlerweile FS die eine RAID-Funktionalität beinhalten. Der Vorteil ist, dass das FS sein eignenes FS kennt und weißt wo Daten sind und wo nicht. Zusätzlich prüfen die FS sogar die geschriebenen Daten auf ihrer Intigrität.

zfs, btrfs

Aber im 21. Jahrhundert dümpeln wir immer noch mit HW/SW-Raid vor uns hin, dass vom FS nichts weiß..

In 20 Jahren haben wir dann vielleicht erkannt, dass diese Technik aus dem letzten Jahrhundert mehr als veraltet ist.

Bis dahin werden sich noch viele Admins mit der alten Technik beschäftigen und auch mit den Nachteilen leben müssen.
 
Hey, wir waren verdammt nochmal auf dem Mond!
Click to expand...
Ich denke folgendes Zitat über den Sourcecode von Apollo11 sollte das mal relativieren:
"Line 666 in the Lunar Module’s code has a comment identifying it as “NUMERO MYSTERIOSO” or the number of mystery while Lines 179 and 180 have both been commented by the programmer as “TEMPORARY I HOPE HOPE HOPE”."
=> http://apcmag.com/apollo-11-code-goes-open-source.htm

Aber im 21. Jahrhundert dümpeln wir immer noch mit HW/SW-Raid vor uns hin, dass vom FS nichts weiß
Click to expand...
Das basiert auf der UNIX-Mentalität und ist bis auf Performance generell nicht verwerflich. Statt 1 Tool zu bauen dass alles halbwegs kann wird jedem Programm oder Kernel-Modul genau 1 Arbeit zugeordnet und die Features können möglichst frei miteinander kombiniert werden.
Als Resultat können die Dateisystem-Autoren sich auf ihre Arbeit konzentrieren ohne sich den Kopf zu zerbrechen wann und wie man den Resync laufen lässt.

In 20 Jahren haben wir dann vielleicht erkannt, dass diese Technik aus dem letzten Jahrhundert mehr als veraltet ist.
Click to expand...
Wie du selber sagst gibt es bereits entsprechende Lösungen. Microsoft hat mit "Dynamic Drive" eine ähnliche Funktion übrigens auf Basis des NTFS laufen welche sogar im laufenden Betrieb eingestellt werden kann. Allerdings haben diese Features alle sehr experimentelle und teilweise gefährliche Stellen und führen öfter zu Fehler als Vorteilen.
 
Das FS von MS würde ich nicht einsetzen. Wenn dann eher btrfs und das ganz vorsichtig. Mit zfs wäre man auf der sicheren Seite. Das FS gibt es schon mehr als 10 Jahre im Produktiveinsatz.

Natürlich ergibt es Sinn, dass man die unterschiedlichen Aufgaben abstrahiert, wodurch sich z.B. das FS nur auf seine Aufgabe kümmern muss. Was mir dazwischen fehlt ist das Bindeglied.

Gibt es nicht auch HW-Raid-Controller, die das FS (ext3, ext4, ntfs) kennen, beim Schreiben mittels einer checksum nochmals prüfen und am besten noch ein Rebuild nur von echten Daten (leere Bereiche des FS auslassen)?

Es ist ja nicht so, dass die Medien von heute auf morgen kaputt gehen. Das ist eher ein langsamer Prozess, bei dem immer mehr Daten nicht mehr lesbar sind. Ein Controller mit dieser Logik könnte solche Probleme frühzeitig erkennen und Totalausfälle dadurch unwahrscheinlicher machen.
 
Das FS von MS würde ich nicht einsetzen. Wenn dann eher btrfs
Click to expand...
Meines Wissens ist BTRFS aber nicht Windows-kompatibel was nun mal Microsoft's Betriebssystem ist :D


Das ist eher ein langsamer Prozess, bei dem immer mehr Daten nicht mehr lesbar sind.
Click to expand...
Die Festplatte selber erkennt solche Fehler bereits und listet sie ausführlich via SMART. Controller und/oder System müssen die Daten nur auswerten und dabei warnen. Der Controller muss dabei gar nicht wissen was Daten sind oder nicht, sondern die Defekte treten auf Block-Ebene auf und müssen auch auf Blockebene korrigiert werden. Festplatten sowie SSD's "korrigieren" Ausfälle ganzer Blöcke ja sogar über dafür vorgesehene Reserve-Blöcke welche als Ersatz wirken.

Langsam würde ich den Prozess eines Ausfalles aber nicht nennen, oftmals bleiben allerhöchstens paar Stunden zwischen ansteigender Fehlerrate und Ausfall des Datenträgers. In einer hohen Anzahl von Fällen ist die Festplatte sogar absolut "gesund", beim nächsten Start meldet sie sich aber nicht mehr oder schafft es nicht den Kopf auf den Träger zu heben.
 
You must log in or register to reply here.
Back
Top