Speicherpools nicht mehr sichtbar

    Hallo allerseits,


    Ich habe hier, quasi als Premiere, eine Kunden QNAP auf dem Tisch liegen seit heute. Eine TS-1680 R2. Soweit so gut. Der Kunde hat diese Woche einige Umbauten an den RAID Gruppen vorgenommen an dessen Ende anscheinend der Verlust sämtlicher Daten steht. Und der Klassiker natürlich: Es gibt nur partiell ein aktuelles Backup von wichtigen Daten... :X Ich habe mir alles soweit schildern lassen und versuche eine Lösung zu finden (sofern es überhaupt eine geben sollte). Da ich mein Geld aber mit VMware und Firewall Lösungen verdiene, bitte ich um Nachsicht wenn mir die QNAP Terms nicht ganz geläufig sind. Ich habe versucht es soweit wie möglich zu rekonstruieren, bin aber durch meine limitierten Kentnisse schnell ans Ende der Fahnenstange gelangt und möchte durch einen irrtümlichen Schreibzugriff nicht die wage Chance auf eine Lösung komplett runieren.


    Folgendes ist in der Historie passiert:

    • Ursprünglich waren es 13 Platten (1 x neue Seagate Ironwolf 12 TB und 12 x WD Red 8 TB). Diese waren in zwei Speicherpools aufgeteilt. Einen mit 6 und einen zweiten mit 7 Platten. Es kam eine SSD auf Slot 16 hinzu, die in Folge zu einem RAID1 ausgebaut werden sollte (für System und sonstige Dinge)
    • Nun hatte man anscheinend die Idee geboren, das alles in 3 RAID Gruppen umzugruppieren.
    • Zuerst wurden vom ersten Speicherpool (Slot 1 bis 6) alle Daten (Freigabe Shares) auf den zweiten Speicherpool kopiert. Als dies erfolgt ist, ist der erste Speicherpool aufgelöst worden und mit einer zusätzlichen Platte (bereits aufgeführte Seagate Ironwolf) wurden 2 neue RAID Gruppen erstellt. Zweimal RAID5 über die Platten 1-4 und 5-7.
    • Dann wurden die Daten von der alten "2ten" Gruppe auf die neuen beiden aufgeteilt, damit man die zweite alte ebenfalls umgruppieren konnte.
    • Man hat die alte zweite Speichergruppe auswerfen und löschen wollen, dabei scheint es aber zu einem Fehler in Konfiguration gekommen sein - Sie hat sich nicht vollständig löschen lassen und blieb lt. Kunden im Speicher Manager sichtbar als "Inaktiv" und Fehlerhaft.
    • Man hat es mit Neustart und Firmware Upgrade versucht (von 4.4.1 1086 auf 4.4.1 1101) - aber nichts hat geholfen. Der leere Speicherpool blieb fehlerhaft hängen und hat sich entfernen lassen. Die Freigaben auf den neuen Shares haben aber ordnungsgemäß funktioniert zu diesem Zeitpunkt.
    • Nach mehreren Löschversuchen (und Restarts) hat man sich anscheinend entschlossen das NAS anhand der folgenden Anleitung zu resetten: https://www.qnap.com/de-de/how…beordnerpfade-wieder-her/
    • Seit diesem zurücksetzen, bei dem mir glaubhaft versichert worden ist (der Kunde ist seit Jahren grundsätzlich durchaus vertrauenswürdig bei seinen Angaben), dass alle Platten abgezogen worden waren, sind die beiden neuen Speicherpools nicht mehr ersichtlich. Sie werden nicht erkannt und auch nicht mehr gemounted.

    Ich habe das Gerät nun bei mir mit allen Platten einmal so übernommen, einen Case bei QNAP erstellt und suche nun nach einer Lösung. Durch Recherche (und oberflächliche Kentnisse mit mdadm) habe ich mich mittels SSH auf die Box verbunden und konnte sowohl Superblocks der RAID Gruppen problemlos finden, als auch die Gruppen fehlerlos mit "mdadm -AfR" zusammensetzen. Bei meinen Recherchen stieß ich auch auf das Tool "md_checker", dessen Output ich hier angehängt habe. Für mich als absoluter QNAP Laie stellt es sich also dar, dass die RAID Gruppen grundsätzlich vorhanden wären und auch problemlos zusammengefügt werden können. Doch wie kommt man weiterführend an die Daten? Das Kommando "/etc/init.d/init_lvm.sh", hat hier keine Abhilfe geschaffen.

    Auch wenn die RAID-Gruppen noch da sind, wird das NAS sie wahrscheinlich nicht ohne Weiteres willkommenheißen, denn es kennt sie ja nicht.

    Ich hatte kürzlich einen Speicherpool sicher getrennt. Das ist eine Spezielle Option im Speichermanager. Danach war das NAS aber in der Lage nach dem Speicherpool zu suchen und ihn erneut einzubinden.

    Das Dumme ist, ohne vorher die RAID-Gruppen zu finden, bringt das auch nichts. :/


    QNAP nutzt doch sicher ein Software-RAID. D.h. es muss einen Manager dafür geben. Vielleicht kann man den per Konsole ansprechen und hat dann eventuell mehr Optionen.

    Habe ich aber auch noch nie probiert.


    Sorry.

    Ich bin nun durch Zufall einen riesigen Schritt weiter. Warum auch immer, aber als ich nach der Übernahme die beiden RAID Gruppen mittels mdadm zusammen gesetzt und "/etc/init.d/init_lvm.sh" laufen habe lassen, waren sie nicht sichtbar. Als ich nun die Box neu gestartet habe, ich habe sie nach der ersten Analyse abgeschalten, sind nun beide Speicherpools sichtbar und die Volumes haben sich mit den vom Kunden gelieferten Passphrases aufsperren lassen. Höchst spannend für mich. :/:handbuch: Eigentlich wollte ich nur die vom QNAP Support geforderten Log Dateien etc. dumpen.


    Vielleicht hat einer der QNAP Profis hier eine Idee warum oder ob das Verhalten "normal" ist. Sicherlich war letztendlich der vollständige Reset "schuld" am nicht mehr erkennen der Speichergruppen. Da ich aber nicht weiß, was das Skript alles an Mechanismen triggert, kann ich auch nichts wirklich sinnvolles beitragen.


    Nach einer ersten Stichprobe scheinen die Daten innerhalb der RAID Gruppen konsistent und funktionell zu sein. :thumbup:


    Lediglich die System SSD auf Port 16 lässt sich nicht mounten, die wird als "Legacy-Volume" angezeigt. ?( Und dann bleibt noch die Frage, ob man die verschlüsselten Shares einfach durch neu anlegen des Shares wieder entsperren kann. Die Volumes zu entschlüsseln hat ja wunderbar geklappt und einige Freigaben darunter sind unverschlüsselt gewesen.

    Oha, eine glückliche Fügung! :)

    Vielleicht war aber ein Neustart nach Deinen Maßnahmen, dass was noch gefehlt hatte.


    Also ich muss ehrlich zugeben, dass ich mich nicht traue die Datenträger zu verschlüsseln, da ich nichts weiß wie das passiert (auf Dateisystemebene oder wie auch immer).

    Als ich testweise einen einzelnen Ordner verschlüsseln wollte, habe ich Blut und Wasser geschwitzt, weil die ganze Kiste anfing zu rödeln. :D

    Ja, durchaus eine glückliche Fügung, keine Frage. Vielleicht denkt man nach dem ersten Schock auf Kundenseite nach endlich die Backuplösung zu überarbeiten und vor allem zuverlässiger zu gestalten. :ziped:


    Das "Legacy-Volume", sprich die SSD auf Port 16, habe ich elimiert und neu angelegt. Da war nichts drauf als das "System" Volume, welches sich ja neu anlegen lässt, und ein Volume für 3 VMs. Für die gibt es aber einen täglichen Export auf ein anderes Storage, also war es am wenigsten Aufwand dieses Volume einfach neu anzulegen.


    Jetzt stellt sich eben für mich nur mehr die Frage nach der Vorgangsweise für die verschlüsselten Verzeichnisse (nicht die Volumes, die funktionieren wunderbar). Ich habe mit LUKS keinerlei Erfahrung. Von jedem verschlüsseltem Share scheint es zwei zugehörige Verzeichnisse zu geben. Nämlich jeweils ein ".__En__" und ein ".@__lock__". Wäre es wirklich so einfach, einfach eine neue Freigabe mit der richtigen Passphrase anzulegen? Und welchen der beiden Folder muss man als Basis für die Freigabe nutzen?

    Bevor Du weitere Versuche unternimmst, würde ich jetzt erstmals 3 Dankes-Stoßgebete - an wen auch immer ;) - richten und SOFORT ein vollständiges Backup aller Daten vornehmen.

    Danach kannst Du munter weiter arbeiten und zur Not alles neu aufsetzen.

    Erst recht, wenn Du als Dienstleister das für den Kunden wieder zurecht biegst.


    Gruss

    Zitat von Tonictrinker1

    Also ich muss ehrlich zugeben, dass ich mich nicht traue die Datenträger zu verschlüsseln, da ich nichts weiß wie das passiert (auf Dateisystemebene oder wie auch immer).

    Ich bin auch kein Fan davon, ehrlich gesagt. Denn eine Verschlüsselung verkompliziert die Datenrettung und Wiederherstellung immer ungemein. Mir reicht es schon, dass einige Hersteller für ihre proprietären Filesysteme keine ausführlichen Tools mitliefern... Aber ich schätze, ich muss mich mit diesem LUKS intensiver beschäftigen, da ich hier beim mounten natürlich keinen Fehler machen möchte...