Verschlüsseltes Volume (Speicherpool, Thin) kann nicht gemounted werden...

  • Hy Leute,


    Nachdem auf meiner TS-1270 vor wenigen Tagen sich eine WD-RED 6TB verabschiedet hatte, habe ich das Storage herunter gefahren, die defekte Disk (SMART Error) ausgetauscht und das Storage wieder gestartet. Seitdem ist eines, von mehreren, Volumes nicht erreichbar und kann nicht mehr gemountet werden. Natürlich hat es eines der verschlüsselten Volumes betroffen. :cursing: Die Basis Konfiguration sieht aus wie folgt:
    Bay 1 - 6: Storagepool 1 (Raid 5) mit WDC WD60EFRX-68L0BN1
    Bay 7 - 12: Storagepool 2 (Raid 5) mit WDC WD40EFRX-68WT0N0


    Im Storagepool 2 meldet sich das Volume seit dem erneuten starten einfach ohne Namen und "entladen". Nachdem ich mich mittels SSH auf die Konsole verbunden hatte finde ich nur ein Volume welches nicht gemountet werden kann  /dev/mapper/cachedev8 . blkid auf das betroffene Volume gibt folgendes aus:


    [~] # blkid /dev/mapper/cachedev8/dev/mapper/cachedev8: UUID="M060F^He4M-^U^E37^U^T4bM-.1-9c8a-fbc1^T^A9398c0,<" TYPE="crypt_LUKS"


    Da ich mich, leider, bis zum heutigen Tage nicht mit den Verschlüsselungsmechanismen von QNAP beschäftigt hatte, habe ich mir zum Vergleich ein funktionierendes Volume herangezogen,  /dev/mapper/cachedev3 


    [~] # blkid /dev/mapper/cachedev3/dev/mapper/cachedev3: UUID="33343a17-e98d-4c25-8280-0917756a9031" TYPE="crypt_LUKS"


    Auf dem ersten Blick scheint die UUID von cachdev8 korrupt zu sein. Wenn ich versuche mittels cryptsetup Befehl das LW manuell zu aktivieren, erhalte ich folgenden Output:



    Wenn ich es also richtig verstehe, dann ist der Header des LUKS Volume defekt. Die Repair Option funktioniert ebenso wenig. ;( Die Snapshots liegen natürlich im gleichen Volume. Gibt es wirklich keine andere Möglichkeit als die Daten abzuschreiben und das Volume zu löschen? Warum weißt QNAP nicht irgendwo in der GUI daraufhin, oder führt es gar im Assistenten automatisch durch, dass man den Header als Single Point of Failure sichern kann? :cursing:


    Der Rebuild ist erfolgreich abgeschlossen, keine anderen Volumes weißen irgendwelche Probleme oder Datenschäden auf. Was ich aus meiner ersten Recherche bisher gelesen habe, lässt sich der Header ohne Backup nicht wieder herstellen. Und nachdem es noch dazu ein flexibles Volume ist, werde ich wohl kaum so einfach eine 1:1 Kopie bekommen?


    Hat noch irgendjemand eine Idee?


    Defektes Volume.JPG

  • Zitat von christian

    Darf ich fragen warum du das NAS runtergefahren hast und nicht im laufenden Betrieb die Platte gewechselt hast?

    Eine gute Frage. Ich wollte die Gelegenheit nutzen und die Kiste mal wieder sauber durchstarten.


    Wie ich nun durch Recherche erfahren habe, wahrscheinlich ein schwerer Fehler, da der Key zumindest beim geöffneten Laufwerk noch wiederherstellbar wäre. Aber einen Warn Mechanismus oder ähnliches gibt es halt nicht. Und wie durch Dr. Google festgestellt habe, bin ich Linux Distri unabhängig nicht der einzige, der mal einen defekten LUKS Header hatte... Aber ein definitives "geht" oder "geht nicht", habe ich noch nicht gehört bzw. gelesen. Geistig habe ich mich aber damit schon abgefunden, anscheinend ans Backup zu müssen... Wie gut, dass es LTO gibt.