TS-859 Pro+ RAID 6 Rebuild gegen die Wand gefahren

    Hallo zusammen,


    mein altes TS 879 Pro+ hatte vor ein paar Tagen eine Platte mit SMART Fehlern und dem Zustand Normal WD RE 4TB WD4000FYYZ ich hab diese gegen eine WD Gold 4TB WD4003FRYZ ausgetauscht. Der Rebuild ist gestartet und lief zwar langsam aber stätig. Hatte gestern Abend nach etwa 3 Tagen 35% Rebuild durch. Leider ist das System dann gestern Nacht durchgestartet. Stromausfall ist ausgeschlossen, da es an einer USV hängt, die mir einen Fehler protokolliert hätte.

    Nun sind die Freigabeordner nicht mehr verfügbar weil das RAID 6 im Speichermanager zwar sichtbar ist, aber nicht eingehängt. Der erste Versuch das Raid über die GUI per Wiederherstellen zu beleben scheiterte mit "Raid Recovery failed.


    Nun habe ich mich per SSH verbunden:


    /dev/md0 ist nicht nach /share/MD0_DATA eingehangen


    Code
    # mdadm --detail /dev/md0
mdadm: md device /dev/md0 does not appear to be active.

    mdam bringt für md0 auch keine infos


    Code
    # e2fsck_64 -fp -C 0 /dev/md0
e2fsck_64: Invalid argument while trying to open /dev/md0
/dev/md0:
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>

    Dateisystemcheck auf md0 ist erfolglos


    mdstat bringt die obrige Ausgabe



    Code
    # e2fsck_64 -fp -C 0 /dev/md0
e2fsck_64: Invalid argument while trying to open /dev/md0
/dev/md0:
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>

    Filesystem Check auf md0 ist nicht möglich


    Code
    # mdadm --examine /dev/md0
mdadm: No md superblock detected on /dev/md0.


    Hat jemand eine Idee wie ich hie über die Shell weiter komme und das RAID wieder zum laufen bekomme?


    Ich habe in einem Forum noch ein ähnliches Thema gefunden bei dem jemand ein RAID 5 mit 4 Platten nach einem ähnlichen "Rebuild failed" wieder an den Start gebracht hat, schreibt aber nicht dazu, ob die Daten noch da waren mit dem madam --create Kommando

    Code
    #mdadm --create -v --force --run --assume-clean /dev/md1 --raid-devices=4 --level=5 --metadata=1.0 --chunk=64 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3
# /etc/init.d/init_lvm.sh

    Der init_lvm.sh dürfte nur auf HAL Firmware funktionieren, bei Legacy Geräten habe ich den noch nicht gefunden.

    Von was für einem NAS reden wir eigentlich, im Titel ist es ein TS 859, im Thread ein TS 879?


    Mir ist während eines Rebuilds auch mal ein NAS rebootet, das war mit Sicherheit ein FW Bug, denn das NAS hängt an einer USV. Zufällig war ich auch gerade anwesend und es gab keinen Stromausfall. Da das NAS mit dieser FW aber sowieso alle 2-4 Tage ohne erkenntlichen Grund rebootet hat, habe ich es in den Ruhstand geschickt.


    Ich habe zusammengefasst, wie ich das Raid bei mir wieder herstellen konnte. Du musst das auf Deine Konfiguration anpassen.


    Gruss


    Danke für Die ausführliche Doku. Der md_checker war nicht auf dem System, konnte den aber nachladen:

    Ich werde nun mal abwarten ob der Rebuild erfolgreich ist. Dann werde ich das Array erst wieder einhängen, oder das NAS rebooten und schauen was passiert.


    Gruss

    Zitat von 1x1speed

    Hatte gestern Abend nach etwa 3 Tagen 35% Rebuild durch. Leider ist das System dann gestern Nacht durchgestartet. Stromausfall ist ausgeschlossen, da es an einer USV hängt, die mir einen Fehler protokolliert hätte.

    Zitat von FSC830

    Mir ist während eines Rebuilds auch mal ein NAS rebootet, das war mit Sicherheit ein FW Bug, denn das NAS hängt an einer USV. Zufällig war ich auch gerade anwesend und es gab keinen Stromausfall. Da das NAS mit dieser FW aber sowieso alle 2-4 Tage ohne erkenntlichen Grund rebootet hat, habe ich es in den Ruhstand geschickt.

    Das braucht kein FW-Bug zu sein. Eine andere mögliche Ursache könnte eine Überlastung sein. Gerade bei schwächeren QNAP NAS mit begrenzten Hauptspeicherressourcen habe ich spontane Reboots erlebt. Wenn ich zu jenem Zeitpunkt eine GUI-Sitzung offen hatte, sah ich eine entsprechende Warnmeldung, entweder dass die CPU überlastet sei oder wegen hoher Speicher- und Swapbelegung das System einen Neustart durchführe. Das scheint an einem Heartbeatmonitor in QTS zu liegen. Habe diesen aber noch nicht näher identifizieren können, geschweige denn Konfigurationsmöglichkeiten desselben kennengelernt. Eine typische Begleiterscheinung, wenn diese Warnung auch umgesetzt wird, ist kein klassischer Reboot, sondern ein Kaltstart ohne vorherigen Shutdown! Das führt dann zur Warnung beim Booten, dass auch noch ein Dateisystemcheck empfohlen wird, was wieder zur Gefahr einer temporären Überlastung führt. Von daher stufe ich dies nicht als einen FW-Bug ein sondern als eine Inkonsistenz im Design (von QTS). Und naja, dass dieser Heartbeat nicht wenigstens versucht, zunächst einen Shutdown durchzuführen, lässt sich m.E. durchaus als FW-Bug einstufen. Das ist aber nur ein Teil des von mir beobachteten Verhalten. Wenn also der von Euch beobachtete Reboot nicht die von Euch erwartete Notiz in Systemprotokollen hinterlassen hat, gab es dann Einträge über nicht ordentlich herunter gefahrenes System und empfohlenen Dateisystemcheck im Zusammenhang mit Euren Reboot-Beobachtungen?