Bei Firmwareupdate Platten (Raid 1) korrupt

    Also um es kurz zu machen: Beim letzten Firmware update gab es einen Fehler, dass das NAS (QNAP TS 253 Pro | 2x WD Red 3 TB | Raid 1 LVM thin provisioning) über die Weboberfläche und Samba-Share nicht mehr erreichbar war.

    Relativ schnell hatte ich den Eindruck, dass die Firmware nicht richtig geupdatet wurde, weshalb ich mit dem QFinder die Firmware erneut draufspielte.

    Nun wollte das NAS aber die Platten nicht mehr akzeptieren (wenn ich eine der beiden einstecke schaltet sich das NAS bzw mein PC aus. Je nach dem im welchen Gerät ich die Platte einstecke).


    Werkseinstellungen wiederherstellen funktioniert leider nicht - das NAS startet wieder in der Initialisierungs-Seite.


    Am Ende habe ich nur noch 1 HDD aus dem Raid Verbund, welche im QNAP steckt,

    Ich komme an LogicalVolume relativ einfach dran, jedoch lässt es sich einfach nicht mounten. Mein Ziel ist, die Daten zu sichern und das NAS komplett neu aufzubauen. Wenn ich also mit einem Dump des LogicalVolumes und einem entsprechenden Programm den Restore schaffe, wäre das auch okay. Lieber wäre mir ein sauberer mount und ein Copy via Rsync,

    Hat jemand eine Idee, wie ich hier weiter komme?

    Zitat von Q-Snapper

    wenn ich eine der beiden einstecke schaltet sich das NAS bzw mein PC aus. Je nach dem im welchen Gerät ich die Platte einstecke).

    OK, wenn sogar der PC mit der Platte hinunter fährt ist sie definitiv defekt, also ab in den Müll (oder ist sie noch neu?). Wie alt ist den die zweite Platte?


    Was das NAS angeht, das sollte auch mit nur 1 Platte eines RAID1 (herabgestuft) laufen können. Also musst du zuerst schauen, dass das NAS wieder läuft …


    Backup hast du sicher, oder?

    Eine Ersatzplatte (oder gleich zwei) in gleicher Größe ist auch da?


    Wenn das NAS mit der Initialisierungsseite startet, schaut das ohnehin nach Werkseinstellung aus, oder wolltest du das nicht?


    (M)Eine Sofortmaßnahme wäre jetzt das Klonen der zweiten Platte auf dem PC, mit Clonezila oder ähnlichem Tool, falls kein Backup vorhanden … :whistling:

    Dann würde ich eine neue (!) leere Platte in das NAS geben und dafür sorgen, dass es wieder hochkommt und die FW meiner Wahl sauber läuft.

    Erst danach würde ich mich um das Wiederherstellen des RAID1 bemühen ...

    Hi Q-Snapper


    schaut so aus als wäre das Filesystem zerschossen.


    NOrmlerweise kommt nach dem lv noch ein devicemapper. Sollte aber keinen unterschied machen.


    Kannst Du mal den die Ausgane aus


    Code
    # dmsetup ls


    posten? Ich denke nicht dass das cachedev1 online ist.


    Du kannst es mir einem init script online bringen, das sollte noch gehen.


    Code
    /etc/init.d/init_lvm.sh


    Danach denn eine Filesystemcheck evtl mit Backup Superblock


    Code
    # e2fsck_64 -fp -C 0 /dev/mapper/cachedev1

bzw.

# e2fsck_64 -fp -C 0 -b 32768 /dev/mapper/cachedev1

oder einen anderen Backupsuperblock


    Ich denke aber du wirst zum gleichen Ergebnis kommen wir bei deinem versuchten FS-Check.

    Vielen Dank für Eure Antworten,


    die Platten sind fast 3 Jahre alt. Backup ist natürlich wieder zu alt.


    Ich werde mir heute kurzfristig eine große Platte von der Arbeit borgen, um eine Sicherung des Laufwerksinhalt durchführen zu können.Es wird ein paar Tage dauern, bis ich hier wieder voran komme.


    Der e2fsck mit einem Backupsuperblock hatte leider auch kein Ergebnis gebracht.

    Könnt Ihr ein Tool zur ForensikAnalyse / Datenextraktion etc empfehlen?

    Heute sind die neuen HDDs angekommen - ich habe die Arbeit wieder aufgenommen.


    Leute Leute Leute... Ich verliere langsam mein Vertrauen in unsere Technik.

    Warum? Bis auf den unvollständigen mdadm --readwrite Befehl habe ich alles so ausgeführt wie beim letzten Mal, als ich diesen Thread begann.


    Was soll ich sagen: Die Partition wurde erfolgreich gemountet, ist lesbar und ich ziehe gerade die Kopie von den Prio1 Daten.



    Ich überlege gerade, ob der unvollständige "mdadm --readwrite" Befehl mein Fehler war und daher das Journal nicht abgearbeitet werden konnte...

    Ich werde nach erfolgreicher Kopie das nochmal testen und Bescheid geben, ob sich der Fehler mit dem fehlerhaften Kommando reproduzieren lässt.