TS-859Pro+ RAID6 meldet Status entladen

  • Hallo Zusammen,


    nach einem Neuaufsetzen mit 8x4TB (Seagate freigegeben in der Kompatibilitätsliste) mit zwei Datenträgern als RAID6 meldet eines der Volume den Status entladen, vermutlich entstanden durch Probleme der Rücksicherung des alten Volumes von einer am NAS angeschlossenen 500GB USB Festplatte.


    Das NAS lief mit 8x2TB 6 Jahre ohne Probleme und jetzt das Problem.


    Leider habe ich keine Erfahrung mit Linux und konnte demnach mit dem Handling in anderen Threads beschrieben nicht viel anfangen.


    Eine Firmware Update von 4.2.6 2018/07/11 auf 4.2.6 2018/08/29 brachte keinen Erfolg.


    Ein Ticket habe ich beim QNAP Support noch nicht aufgemacht.


    Wie kann das Volume gerettet und vor allen das Problem für die Zukunft vermieden werden ?


    Für Eure Hilfe im Voraus vielen Dank.


    Gruß

    Dirk


    QNAP_TS859Pro+_Raid_entladen_01.png


    Update:


    Nachfolgend der Raid und den Blockdevice Status:



    Anscheinend fehlt im RAID md1 die Platte sda3. Vielleicht ist das das Problem.

  • Hallo Rio Bravo


    kannst Du bitte die Ausgabe von folgendem Befehl posten?


    Code
    # md_checker

    Danke

  • Die fehlende sda3 dürfte bei einem Raid 6 eigentlich nicht dazu führen das das Raid entladen ist, sondern als "degraded/herabgesetzt" gemeldet wird und Datenzugriff möglich ist.

    Damit der md_checker vorhanden ist müssen aber die QNAP-Diagnostic Tools vorhanden sein, die kann man aus dem App Store installieren.

    Ich verstehe noch nicht was Du damit meinst "Rücksicherung von einer 500GB USB Platte": meinst Du die Daten oder die Konfiguration des NAS was Du zurückgesichert hast?

    Bei Daten würde ich es noch weniger verstehen, denn dann muss das Ziel-Volume bzw. die Shares erreichbar gewesen sein.


    Erst mal wie gebeten den Output des md_checker posten.


    Gruss

  • Hallo Zusammen,


    bitte entschuldigt die späte Anwtort, aber ich war geschäftlich unterwegs.


    Erst einmal für Eure Antworten vielen Dank.


    Mit "Rücksicherung von einer 500GB USB Platte" war das Rückspielen der Dateien vom gelöschten Volume gemeint. Ich hatte ein Volume mit 11TB und musste vor dem Neuaufsetzen alle Daten sichern. Das wurde mit verschiedene Platten realisiert, die dann teilweise über den USB Port am RAID zum Rückspielen angeschlossen wurden. Dabei hatte sich die 500GB Platte aufgehängt.


    Anbei die gewünschte Auswertung.


    Ging allerdings nur über diesen unter Punkt III.


    http://qnapsupport.net/how-to-…stall-md_cheker-manually/


    Vielen Dank.


    Gruß

    Dirk

  • Aber md_checker meldet doch beide Raids als Online?

    Alle Platten bzw. Partitionen beider Raids sind vorhanden!

    Und die GUI meint immer noch das das erste raid "herabgesetzt" ist?


    Gruss

  • Wo steht das mit der 16TB Grenze?

    Meines Wissens gilt das nur für das expandieren wenn man von älterer FW kommt, nicht aber beim Neuanlegen eines Volumes.

    Meine Volumes sind auf beiden TS859 gringfügig > 16TB (6 * 2.73TB = 16.38TB).
    Ich hatte vorher allerdings ein Raid 5 mit ca. 19.11TB Volumegröße und bin nur aus sicherheitsgründen auf Raid6 gewechselt.


    Gruss

  • Die 16TB Grenze steht im GUI wenn man erweiteren möchte (siehe Bild, aber etwas verwirrend als Laufwerks statt Volumenerweiterung) und wurde telefonisch vom Support bestätigt. Des Weiteren konnte ich die 8x4TB nicht als ein Volume einrichten.


    Aber kommen wir zurück zum Thema.


    Was können wir jetzt noch unternehmen, um den Status Raid "Entladen" in "Bereit" umzuwandlen ?


    Oder muss ich das Volumen neu aufsetzen ? Die Daten habe ich noch als Sicherung. Wäre also kein Problem, aber zeitaufwendig.


    Des Weiteren möchte ich verstehen bzw. verhindern, dass das nicht noch einmal passiert.


    Vielen Dank.

  • Wenn das RAID aktiv ist aber nicht online, dann ist vermutlich das Dateisystem fehlerhaft und sollte überprüft und bereinigt werden. Leider lässt QNAP dies nicht über die Weboberfläche zu, wenn das Volume nicht gemountet ist. (eigentlich Unsinn, weil es zum Check eh unmountet werden muss)

    Hier bleibt nur der Weg über die Konsole mit e2fsck_64 -y -C 0 /dev/md1.

  • Hallo Dr_Mike,


    ich habe den Befehl gestartet allerdings in dieser From "e2fsck_64 -c -y /dev/md1" weil er wie oben geschreiben nicht funktioniert hat:


    Nachdem das Datei System geprüft wurde hängt der Befehl und es geht nicht weiter (siehe Bild).


    Das Raid ist weiterhin entladen.


    Was nun ?


    Vielen Dank.

    Prüfung ist beendet, kann aber auch sein, dass es beendet wurde weill ich mit Strg+C den Bild Schirm Inhalt kopieren wollte, siehe rote Markierung.


    Soll ich die Pürfung nochmals laufen lassen ?


    Volume ist immer noch entladen.


    Vielen Dank.

  • Der check sollte schon normal zum Ende kommen.

    Screenshot mit Strg+C???

    Das terminiert üblicherweise den laufenden Prozess wenn in der Linux Shell ausgeführt.


    Trotzdem wundert mich die unterschiedliche Ausgabe von md_checker und dem tatsächlichen Zustand.


    Lass den Check noch einmal laufen, länger als 30min. sollte das üblichweise nicht dauern, jedenfalls war das bei mir noch nie der Fall.


    Gruss

  • Laut der Ausgabe des md_checker: ja.

    Wie sieht denn die aktuelle Ausgabe von md_checker aus?


    Gruss

  • ich habe den Befehl gestartet allerdings in dieser From "e2fsck_64 -c -y /dev/md1" weil er wie oben geschreiben nicht funktioniert hat

    Was hat denn nicht funktioniert? Ausgabe?

    Du hast mit deinem Befehl einen readonly Badblockscan gemacht. Das war nicht mein Ansinnen. es sollte ein Filsystemcheck durchgeführt werden. Das -C 0 gibt eine Fortschrittanzeige aus und ist nicht mit -c indentisch.

  • Hallo,


    ich hatte übersehen, dass das "C" groß geschrieben werden muss.


    Hier das Ergebnis:

    Code
    [~] # e2fsck_64 -y -C 0 /dev/md1
    e2fsck 1.42.13 (17-May-2015)
    /dev/md1: clean, 4782/122046464 files, 1264992167/1952724768 blocks
    [~] #


    Das Volume ist immer noch entladen.


    Das Ergebnis des md_checker als Anhang.


    Wie geht jetzt weiter ?

  • Was ergibt die Ausgabe von mount?

    Wenn dort kein /dev/md0 auftaucht, kann man /dev/md0 per Befehl mounten?

    Wenn nicht, welche Fehlermeldung gibt es?


    Ich habe nur ein Raid, aber mount gibt bei mir folgendes zurück:


    Code
    /dev/md0 on /share/MD0_DATA type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,delalloc,noacl)

    Bei dir müsste auf alle Fälle /dev/md1 auftauchen, der Logik folgend nach /share/MD1_DATA gemountet.


    Gruss

  • MD1 fehlt.


    Ich habe MD1 wie folgt gemountet:


    mount -t ext4 /dev/md1 /share/MD1_DATA -> wichtig die Großschreibung für MD1_DATA


    Mount gibt diesen Status zurück:


    Das Volume ist wieder vorhanden und Zugriff auf die Daten möglich. Super...................


    Jetzt bleiben aber noch ein paar Fragen offen:


    1. Warum ist das Problem aufgetreten ?

    2. Hätte ein Mounten bereits am Anfang zum Erfolg geführt ?

    3. War die Überprüfung Bereinigung für den Erfolg notwendig ?


    Für Eure Geduld und die Tipps vielen Dank.


    Gruß

    Dirk

  • Upps, da hatte ich eben MD0 und MD1 vertauscht...


    Egal, am wichtigsten wäre jetzt ein Backup zu erstellen.

    Und ja, ich denke ein manueller mount nach dem Filesystemcheck hätte gereicht, der Filesystemcheck war wohl erforderlich.


    Nach dem Backup solltest Du das NAS noch einmal starten und prüfen das die beiden Raids auch verfügbar sind.


    Gruss

  • Beide Raids sind auch nach einem Neustart verfügbar. Backup ist nicht notwendig da ich aus der anderen Richtung gekommen bin.


    Backup -> NAS


    Aber ich sehe ein, das ein Backup auch von einem NAS notwendig ist. Ich dachte ein Plattenausfall ist das einzige Problem, aber anscheinend ist dem nicht so. Hardware und auch die Config kann Probleme machen. Daher werde ich die 16TB regelmäßig auf externe Festplatten sichern. Habe mir dazu bereits ein 4Bay Festplattengehäuse gekauft.


    Also nochmals vielen Dank.

  • Nabend zusammen,


    nachdem ich mein QNAP durch einen Austausch der BiOS-Batterie wieder zum booten überreden konnte, ist nun nach einem Update das Volume entladen (analog zum TE).


    Interessanterweise betreibe ich auch ein 859Pro+ mit einem Raid6 (8x 3TB).


    Anbei ein Screenshot vom md_checker.


    Edit: Ich lasse über Nacht schon mal e2fsck_64 -y -C 0 /dev/md0 laufen...


    Edit: Über Nacht hat sich nicht wirklich was getan. Siehe Bild 2. Scheint nicht normal zu sein, oder?