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. 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:
[~] # cryptsetup luksOpen --debug /dev/mapper/cachedev8 /dev/mapper/ce_cachedev8
# cryptsetup 1.5.1 processing "cryptsetup luksOpen --debug /dev/mapper/cachedev8 /dev/mapper/ce_cachedev8"
# Running command luksOpen.
# Locking memory.
# Allocating crypt device /dev/mapper/cachedev8 context.
# Trying to open and read device /dev/mapper/cachedev8.
# Initialising device-mapper backend library.
# Trying to load LUKS1 crypt type from device /dev/mapper/cachedev8.
# Crypto backend (gcrypt 1.4.3) initialized.
# Reading LUKS header of size 1024 from device /dev/mapper/cachedev8
# Invalid offset 3090939912 in keyslot 0 (beyond data area offset 5120).
LUKS keyslot 0 is invalid.
# Invalid offset 2483028232 in keyslot 1 (beyond data area offset 5120).
LUKS keyslot 1 is invalid.
# Invalid offset 4227924488 in keyslot 2 (beyond data area offset 5120).
LUKS keyslot 2 is invalid.
# Invalid offset 1882784520 in keyslot 3 (beyond data area offset 5120).
LUKS keyslot 3 is invalid.
# Invalid keyslot size 4215034 (offset 1032, stripes 1543835552) in keyslot 4 (beyond data area offset 5120).
LUKS keyslot 4 is invalid.
# Invalid offset 742130952 in keyslot 5 (beyond data area offset 5120).
LUKS keyslot 5 is invalid.
# Invalid offset 3422750216 in keyslot 6 (beyond data area offset 5120).
LUKS keyslot 6 is invalid.
# Invalid offset 1882785544 in keyslot 7 (beyond data area offset 5120).
LUKS keyslot 7 is invalid.
# Releasing crypt device /dev/mapper/cachedev8 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command failed with code 22: LUKS keyslot 7 is invalid.
Alles anzeigen
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?
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?