RAID5 Volume lässt sich nicht mehr mounten

    Hallo Commuintors,


    da der Support nach 2 Wochen noch immer nicht geantwortet hat, hoffe ich, bei euch Hilfe zu finden.


    Ich habe ein TS-453A NAS mit bisher einem Data Thick Volume auf RAID5 mit 4 Seagate Platten.


    Nach einem nicht abgeschlossenen shutdown und einem 'harten' abschalten und neu booten, bekam ich vom QTS die Empfehlung eines Volume checks. Der lief aber nicht durch, bzw. bin ich mir da nicht sicher, denn ich konnte lange nicht flüssig auf das NAS zugreifen und bekam auch keinen Status des FSCheck angezeigt. Also habe ich nochmal einen reboot durchgeführt mit dem gleichen problem des nicht runterfahrens und 'hart' abschaltens.


    Nach dem wieder hochfahren, habe ich nun das problem, dass das Volume mit 'unmounted' im Storage Manager aufgeführt wird. Und das ist auch ganz klar so, da alle Datenpartitionen nicht mehr zur Verfügung stehen und viele Dienste nicht mehr laufen.


    Ein check des Raid 5 per SSH sieht soweit positiv aus. Es scheint aktiv und in ordnung zu sein. Aber die Daten Partition scheint nicht gemounted zu sein lässt sich aber auch nicht neu mounten.


    Ich habe hier im Forum bereits einige Beiträge zu dem Problem gefunden, aber leider passte keine Lösung ausreichend für mein Problem. Ich würde mich freuen, wenn mit mir jemand Schritt für Schritt hier durch die Analyse gehen könnte!


    Danke und Grüße
    Delil

    Eine Schritt für Schritt Anleitung gibt es so nicht da jeder Fehler und das, was man danach bereits gemacht habt, meist sehr individuell ist.

    Wieso bist Du Dir nicht sicher ob der Check durchgelaufen ist? Der Check kann mehrere Stunden dauern, im Log ist das auch ersichtlich.

    Was heisst "check per SSH sieht gut aus"? Was hast Du da genau gemacht?


    Wie ist der aktuelle Status wenn Du cat /proc/mdstat eingibst und md_checker ausführst?


    Gruss

    Hallo FSC830,


    mit Schritt für Schritt, meinte ich genau die Unterstützung durch jemanden, der da Kundig ist und mögliche Schritte mit mir durch geht.

    Mit kurzem Check meinte ich genau die von dir aufgeführten Befehle:






    Das Raid selbst scheint demnach OK zu sein.

    Zitat von Dilling

    ...Aber die Daten Partition scheint nicht gemounted zu sein lässt sich aber auch nicht neu mounten...

    Ok, es ist neueres QTS mit HAL Firmware.

    Was passiert wenn Du versuchst manuell zu mounten?


    Gruss

    Danke für deine Unterstützung!


    Blöderweise habe ich nach einem anderen Forumsbeitrag den Befehl /etc/init.d/init_lvm.sh durchgeführt, der aber mit einer Reihe Fehlermeldungen abgebrochen ist. Jetzt fehlt das bis dahin vorhandene /share/CACHEDEV1_DATA Verzeichnis, wohin das Volume ursprünglich gemounted war.

    Wenn ich

    Code
    mount -t ext4 /dev/md1 /share/CACHEDEV1_DATA

    ausgeführt habe als das Verzeichnis noch existierte, kam die Fehlermeldung '/dev/md1 already mounted or /share/CACHEDEV1_DATA busy'.


    Ich bin auch nicht ganz sicher, welcher mountbefehl richtig wäre. In einem weiteren Beitrag, war die rede davon, dass der LVM manager das mounting übernimmt und das nur über diesen machbar ist.

    Meinst Du evtl. diesen Beitrag bzw. diese Befehle?

    Evtl. musst Du den Ordner neu anlegen, ist schwierig jetzt nachzuvollzuziehen was Du schon alles versucht hast und wie sich das ausgewirkt hat.


    Obligatorische Frage: ein Backup ist hoffentlich vorhanden?


    Gruss

    Ne, den hier:


    TS-251 nach Stromausfall Volume verschwunden


    Ich denke Konfigurations ändernd war nur dieses Scrip.


    Ansonsten habe ich nur versucht etwaige Dienste zu beenden um das device frei zu bekommen, oder herrauszufinden, in welchem Zustand sich die Konfiguration und der aktuelle Status des NAS befindet.


    Wie auch immer. Weis man was das Script genau macht, oder meinst du also es reicht das Verzeichnis mit mkdir wieder anzulegen und darauf aufzubauen?

    Das Script sichert erst mal was weg und ruft dann eine executable auf (storage_util), was die genau macht weiss ich leider nicht.

    Wenn Du aber kein Backup hast wäre ich jetzt vorsichtig und würde auf den Support warten (kann leider dauern).


    Gruss

    Für das wichtigste gibt es Backups, aber für einen großen Teil nicht. Wäre nicht tragisch aber ärgerlich.

    Hallo Dilling,


    generell empfehle ich Dir auf den Support zu warten. Denn Du weist nicht an welcher Stelle das Volumen beschädigt ist.


    Scheint ja als wäre das RAID online. ALso könne wir das auslassen


    Kannst du mal den Auszug folgender Befehle posten?


    Code
    # pvs

# lvs -a 

# dmsetup ls

# df
    Code
    [~] # pvs
  Found duplicate PV chXItZ1EuD1eFuQypxW3qmkZHb4erjYR: using /dev/drbd1 not /dev/md1
  Using duplicate PV /dev/drbd1 from subsystem DRBD, ignoring /dev/md1
  Found duplicate PV chXItZ1EuD1eFuQypxW3qmkZHb4erjYR: using /dev/drbd1 not /dev/md1
  Using duplicate PV /dev/drbd1 from subsystem DRBD, ignoring /dev/md1
  PV         VG   Fmt  Attr PSize  PFree
  /dev/drbd1 vg1  lvm2 a--  10.89t    0
    Code
    [~] # dmsetup ls
vg1-lv1312    (252:1)

    Wie man unter lvs -a sehr gut sehen kann sind fast alle lv´s der Volume Group 1 (vg1) Offline.


    Bitte versuch mal folgenden Befehl und gib uns den Output. Wird höchstwahrscheinlich ne Fehlermeldung sein.


    Code
    # vgchange -ay vg1

    Hallo ColorfulDude,


    danke fürs übernehmen!


    Woran genau erkennt man, dass die offline sind? Weil nicht vorhanden? Also sieht man es nur, wenn man weis welche aufgeführt werden müssten?


    Und warum ist da von Thin Volume die Rede? Zumindest das vermisste Volume ist ein Thick Volume.

    Gibt es noch Hoffnung?

    Für mich sieht das reperabel aus. Scheint "nur" die ID des Thinpools flasch zu sein. NOrmalerweise kann man das in der Config einfach korrigieren. Allerdings ist der Storage Stack von QNAP modifiziert. Maybe geht das anders.


    Und was den Thinpool angeht. Das ist eine der modifizierungen die ich meine. Jedes Gerät das einen Storagepool hat, hat als erste lvm schicht nen Thinpool. Ich schätze das hat was mit der Snapshotfunktionalität zu tun. Aber so genau weiß ich das nicht.


    Hat sich der Support schon gemeldet? Bin mir fast sicher dass das fixbar ist. Zumindest das mit der ID. Kein Plan ob evtl. noch weitere Schichten beschädigt sind.

    Danke fürs Hoffnung machen, nein der Support hat sich nach 3 Wochen leider noch immer nicht gemeldet.
    Es gibt ja den Punkt 'Priority' im Ticket. Den kann man aber selbst nicht modifizieren oder? Steht bei mir auf 'Normal'

    Ich häng mich hier mal an, ich habe aktuell, genau das gleiche Problem. Nur das ich es auch schon vor ca. 2 Wochen vom Support beheben habe lassen und es jetzt nach einem neustart erneut aufgetreten ist.


    Leider musste ich nebenbei selbst arbeiten als der support es bei mir repariert hat, also kann ich jetzt leider auch nicht genau sagen wie es funktioniert. Und letztlich will ich das auch nicht nach jedem neustart machen müssen.

    Hallo Zusammen


    Bei einem Kunden (mit einem TVS-473) scheint ein ähnliches Problem aufgetreten zu sein. Da meine Linux Kenntnisse aber sehr dürftig sind, konnte ich bisher nicht viel erreichen. Sämtliche Mount und Unmount Versuche scheiterten, lediglich die Dienste konnte ich stoppen.


    Folgende Ergebnisse kamen raus:

    Code
    [~] # pvs
  Found duplicate PV g4t4ejxA75gfdGjzddwzsailODfzb49J: using /dev/drbd1 not /dev/md1
  Using duplicate PV /dev/drbd1 from subsystem DRBD, ignoring /dev/md1
  Found duplicate PV g4t4ejxA75gfdGjzddwzsailODfzb49J: using /dev/drbd1 not /dev/md1
  Using duplicate PV /dev/drbd1 from subsystem DRBD, ignoring /dev/md1
  PV         VG   Fmt  Attr PSize  PFree
  /dev/drbd1 vg1  lvm2 a--  21.80t    0
    Code
    [~] # dmsetup ls
vg1-lv544       (251:0)

    Jemand eine Idee?


    Der Support hat sich natürlich noch nicht gemeldet, das Problem tauchte erst Freitag auf.


    Vielen Dank für euer Feedback!

    Das scheint so, als seien die Metadaten des Thinpools beschädigt. Kein Plan ob das reparierbar ist. Vom Gefühl her würde ich sagen ja, aber ich kenne das ausmaß der Beschädigung nicht.


    Was war denn der Auslöser? Stromausfall? Gerät nicht auber heruntergefahren? HDD defekt?

    Scheinbar war schon seit einiger Zeit die 4te Festplatte "rausgezogen". Am Freitag Morgen kam dann die Meldung, dass eine der 3 restlichen Festplatten "entfernt" wurde. Gemäss dem Kunden habe aber niemand etwas daran gemacht.


    Ich vermute, dass die Fehlermeldungen auf der einen Platte zu hoch waren, anschliessend hat das NAS das Volume wohl deaktiviert.


    Leider wurde vor Ort wohl auch mehrmals seither der Stecker gezogen...

    Also bei mir hat alles mit einem Firemware Update angefangen. Seit dem reboot danach hat es die Platten nicht mehr gefunden, bzw. genauer gesagt das Raid eben nicht eingehängt und damit eben das Verzeichnis /share/CACHEDEV1_DATA/ nicht mehr gefunden.