Datenrettung von QNAP NAS — Wiederherstellung, QTS, Thin Volume und RAID

Antwort sofort: Wenn sich Ihr QNAP NAS nicht mehr meldet und das Volume nicht verfügbar oder schreibgeschützt ist, schalten Sie das Gerät sofort aus. Klicken Sie auf keinen Fall in den Storage & Snapshots auf die Schaltfläche „Recover”, starten Sie keine Dateisystemprüfung und schließen Sie die Festplatten nicht direkt an einen PC an. Die Daten befinden sich in den allermeisten Fällen physisch noch auf den Plattern, aber unsachgemäße Reparaturversuche überschreiben die LVM-Thin-Metadaten oder bringen das RAID-Array durcheinander, wodurch die Rettung deutlich aufwändiger wird. Mit Ausstattung wie PC-3000 und DeepSpar-Klonstationen arbeiten wir regelmäßig an der Wiederherstellung von QNAPs und lösen auch kritische Szenarien wie „Volume is not active”. Die Diagnose ist bei uns kostenlos und den Preis nennen wir vorab.

Datenrettung von QNAP NAS im Labor ITHOPE Brünn – Vier-Bay-NAS, herausgezogene defekte Festplatte und Offline-Analyse des QTS-Speichers
Beim QNAP ist die LVM-Thin-Pool-Schicht kritisch. Wenn die Blockzuordnung beschädigt wird, kann „Recover" genau die Metadaten überschreiben, die das Labor benötigt.

Ein häufiges Problem beginnt nicht mit gerissenen Schreib-Leseköpfen, sondern mit einem einzigen Klick. Nach einem Stromausfall startet das NAS das Volume nicht, der Besitzer klickt panisch in den Storage & Snapshots auf „Recover” – und kann damit genau die Metadaten überschreiben, aus denen sich die Daten noch zusammensetzen ließen. Dasselbe Prinzip der „Online-Reparatur zerstört das Array” haben wir auch bei großen Arrays gesehen: Bei einem 20-Disk-RAID 6 brachte ein Rebuild-Versuch das Array zum Absturz, bei dem auf einer scheinbar intakten Platte fehlerhafte Sektoren auftraten. Beim QNAP ist das Prinzip dasselbe — jeder Schreibzugriff in ein zerfallenes Array ist ein Spiel mit dem Feuer. Wenn Sie sich mit der QTS-Architektur und der Arbeit mit LVM2 nicht auskennen, ist es daher besser, das Gerät Spezialisten für RAID- und NAS-Rettung anzuvertrauen.

Ausgeschaltetes QNAP NAS mit in Reihenfolge entnommenen Festplatten an einer Klonstation für Thin-Volume-Wiederherstellung
Bei einem Thin Volume reicht es nicht, das NAS erneut zu starten und auf „Recover" zu klicken. Die Festplatten werden außerhalb von QTS geklont, damit das Mapping des LVM-Thin-Pools nicht überschrieben wird.

Schnelle Orientierung anhand der QTS-Meldung

Wenn QTS einen Fehler des Volumes oder Storage-Pools anzeigt, ist es wichtig zu unterscheiden, was genau gemeldet wird. Dieselbe Administrationsseite kann eine völlig andere Art von Havarie verbergen.

  • Volume is not active / not mounted: oft nach Stromausfall oder Absturz des Thin-Pools. NAS ausschalten, kein Recover oder Check File System starten.
  • Storage Pool Error: kann ein beschädigtes RAID, beschädigte LVM-Metadaten oder ein Problem mit einer einzelnen physischen Platte sein. Ohne Klone lässt sich der Umfang nicht sicher abschätzen.
  • RAID Group Degraded: Festplatten nicht nach dem Prinzip Versuch und Irrtum tauschen. Schächte beschriften und den Zustand der anderen Platten vor einem Rebuild prüfen lassen.
  • Thin Volume warning: Thin Volume fügt eine Mapping-Schicht hinzu. Wird diese beschädigt, können Dateien verschwinden, obwohl die Daten auf den Sektoren noch existieren.
  • QuTS hero / ZFS-Pool lässt sich nicht importieren: Nicht versuchen, den Pool wiederholt mit verschiedenen Optionen zu importieren. ZFS benötigt einen konsistenten letzten Transaktionszustand.

Kurzversion: QNAP gibt nicht nur Auskunft über eine „Festplatte”. Es gibt Auskunft über eine ganze Kette aus mdadm, LVM2, ext4 oder ZFS. Daher ist das sichere Vorgehen zuerst Klonen und erst dann Analysieren.

1. Anatomie des QNAP-Speichers: Warum es nicht nur „Festplatte an PC anschließen” ist

Die größte Falle ist die falsche Vorstellung, dass die Daten auf den Festplatten in einem universellen Format vorliegen. Die Realität ist viel vielschichtiger – und genau diese Komplexität ist der Grund, warum Laienversuche im totalen Verlust enden.

QTS: mdadm → LVM2 → Volume

Das klassische QTS-System baut den Speicherplatz in drei Schichten auf:

  1. RAID-Array (mdadm): Die unterste Schicht, die physische Festplatten zu einem Array (RAID 1, 5, 6, 10) zusammensetzt. QTS nutzt Software-Linux-RAID (mdadm). Degradiert das Array, sind die Daten ohne Reparatur der mdadm-Metadaten nicht lesbar.
  2. LVM2 (Logical Volume Manager): Über dem RAID läuft LVM2, das den physischen Speicherplatz in einen Storage Pool abstrahiert. Hier entstehen die meisten Probleme.
  3. Volume: Erst hier befinden sich die eigentlichen Daten.
    • Static Volume: einfach, direkt auf RAID/Partition, meist ext4. Für die Rettung am ungefährlichsten.
    • Thick Volume: auf einem logischen LVM-Volume, Daten in ext4. Die Rettung erfordert das korrekte Zusammensetzen von LVM.
    • Thin Volume: Thin-Provisioning auf einem LVM-Thin-Pool. Der Benutzer sieht ein 10-TB-Volume, aber physisch belegen die Daten vielleicht nur 4 TB. Das spart Platz, fügt aber eine fragile Schicht Thin-Provisioning-Metadaten hinzu. Deren Beschädigung ist die häufigste Ursache für katastrophalen Datenverlust beim QNAP.

QuTS hero: ZFS

Die modernere Reihe QuTS hero löst mdadm + LVM ab und verwendet ZFS. Sie bringt Vorteile wie Copy-on-Write und Snapshots, hat aber eigene Besonderheiten – internes Disk-Labeling, ZFS Intent Log (ZIL) und die Notwendigkeit des Pool-Imports. Standardwerkzeuge zur Wiederherstellung von ext4 versagen hier vollständig.

2. Die häufigsten Ausfallszenarien beim QNAP NAS

Im Labor begegnen uns spezifische Havariebilder, die Anwender mit denselben Worten beschreiben.

„Volume is not active / not mounted” nach Stromausfall

Der tückischste Fehler, typisch für Thin Volumes. Bei einem unerwarteten Stromausfall kann der QNAP die LVM-Thin-Metadaten nicht mehr korrekt schreiben. Nach dem Neustart läuft der Storage Pool zwar, aber das Volume bleibt mit der Meldung „Not active” ausgegraut. Ein Klick auf „Check File System” oder „Recover” überschreibt in diesem Moment oft die beschädigten Metadaten mit leeren, wodurch die Daten auch für das Labor unsichtbar werden. Dasselbe gilt für Beschädigungen nach einem fehlgeschlagenen Firmware-Upgrade, das I/O-Operationen unterbrochen hat.

Degradierter Storage Pool und Rebuild-Ausfall

Der QNAP piept und meldet eine defekte Festplatte, aber Anwender unterschätzen oft Alter und Verschleiß der übrigen Platten. Der Austausch einer Platte und das Starten des Rebuilds ist eine massive Belastungsoperation. Während stundenlangem Lesen alter Platten treten oft fehlerhafte Sektoren zutage (URE — Unrecoverable Read Error). Befindet sich das RAID-5- oder RAID-6-Array im degradierten Zustand, führt ein einziger fehlerhafter Sektor auf der verbliebenen gesunden Platte zum Absturz des gesamten Arrays — genau wie in unserer Case Study zum 20-Disk-RAID 6. Bei kleinen QNAPs mit RAID 5 ist dieses Risiko enorm.

Gelöschte gemeinsame Ordner und Ransomware

QTS unterstützt Snapshots und einen Papierkorb über den Ordner @Recycle. Bei einem Ransomware-Angriff (z. B. DeadBolt, Qlocker) verändert die Verschlüsselung die Dateiheader. Das Ausschalten des NAS ist kritisch, um die weitere Verschlüsselung zu blockieren. Anschließend können aus den Plattenklonen nicht verschlüsselte Reste extrahiert oder ältere Dateiversionen aus Snapshots wiederhergestellt werden (sofern der Angreifer diese nicht gelöscht hat).

3. Was Sie mit einem havarierten QNAP niemals tun sollten

Die spezifische QNAP-Architektur erfordert spezifische Vorsicht. Die folgenden Schritte zerstören mit höchster Wahrscheinlichkeit auch die letzte Chance auf Rettung:

  • Klicken Sie nicht auf „Recover” oder „Check File System”. Diese Funktionen führen auf beschädigtem Thin/Thick-LVM Schreiboperationen in die Metadaten durch. Sind die Metadaten beschädigt, „reparieren” sie diese so, dass sich das Volume abhängt oder leert.
  • Bauen Sie die Platten nicht um und versuchen Sie keinen willkürlichen Rebuild. Die Position der Platte in der Backplane ist für mdadm entscheidend. Das Vertauschen von Platten beim Versuch der „Wiederbelebung” führt zu einer erzwungenen Reinitialisierung und Verlust der Superblöcke. Beschriften Sie die Platten immer vor dem Ausbau.
  • Schließen Sie QNAP-Platten nicht direkt an einen Windows-PC an. Windows versteht mdadm RAID, LVM2 oder ext4/ZFS nicht. Es bietet sofort „Datenträger initialisieren” oder „Formatieren” an — eine einzige Bestätigung überschreibt die Plattenanfänge und zerstört die RAID-Metadaten.
  • Lassen Sie keine „Data-Recovery”-Software (R-Studio, UFS Explorer) blind auf dem laufenden Array los. Diese Tools sind nach der Erstellung von Bit-für-Bit-Kopien der Datenträger einzusetzen, nicht auf einem angeschlossenen und zerfallenen Array. Das Scannen eines zerfallenen Thin Pools kann weitere Metadatenschäden verursachen.
  • Aktualisieren Sie die Firmware nicht und starten Sie nicht wiederholt neu. Wenn das NAS nach einem Absturz hochfährt, befindet es sich in einem fragilen Zustand. Ein Firmware-Upgrade schreibt auf den DOM (Disk-on-Module) und kann die Konfiguration zurücksetzen. Wiederholte erzwungene Neustarts verschlimmern die physische Beschädigung defekter Platten.
  • Erstellen Sie keinen neuen Storage Pool. Der Versuch, „es einfach neu einzurichten”, überschreibt zuverlässig die LVM-Header auf den Platten.

4. Wie das Labor ITHOPE das löst

Unsere Vorgehensweise basiert auf der Beherrschung aller drei QTS-Schichten (mdadm, LVM2, ext4) und der Besonderheiten von ZFS. Wir arbeiten rein passiv, ohne einen einzigen Schreibzugriff auf die Originalmedien.

Schritt 1: Kostenlose Diagnose und Klonen

Jede Platte aus dem Array (typischerweise 2–8 Stück) schließen wir an Hardware-Kloner DeepSpar Disk Imager an. Diese arbeiten auf Sektorebene und lesen auch Platten mit instabilen Köpfen oder fehlerhaften Sektoren, wobei sie das Lese-Timeout steuern. Mit PC-3000 reparieren wir die interne Firmware beschädigter Platten, um den Service-Bereich (SA) zugänglich zu machen und die langsame Sektorneuzuweisung zu deaktivieren. Das Ergebnis ist ein Satz Bit-für-Bit-Kopien auf unserem Staging-Array (120 TB SATA RAID 10).

Schritt 2: Virtuelle Rekonstruktion von RAID und LVM

Aus den Platten-Images setzen wir das mdadm-Array softwareseitig zusammen (virtuell, ohne Beteiligung des QNAP-Controllers). Wir analysieren die Superblöcke und ermitteln Datenoffset und Stripe-Größe. Anschließend setzen wir die LVM2-Konfiguration zusammen – Physical Volumes (PV), Volume Groups (VG) und Logical Volumes (LV).

Schritt 3: Reparatur der Thin-Pool-Metadaten

Bei Thin Volumes sind die Daten im LV in Datenblöcke und eine Metadaten-Map in einer separaten Partition unterteilt. Wir verwenden spezialisierte Werkzeuge (thin_dump, thin_repair, thin_delta). Wenn QTS den Pool beschädigt hat, parsen wir die Metadaten manuell, um das Mapping zwischen logischen und physischen Blöcken wiederherzustellen. Genau dieser Schritt ist der Grund, warum „Recover” in QTS fehlschlägt und warum Software-Tools keine Dateien sehen, obwohl die Sektordaten auf den Platten vorhanden sind. Bei ZFS reparieren wir die internen Strukturen (Uberblock) und machen einen Rollback auf die letzte konsistente Transaktionsgruppe.

Schritt 4: Datenextraktion

Nach dem erfolgreichen virtuellen Mounten der intakten Partition (ext4/ZFS) kopieren wir die Daten auf ein gesundes Kundenmedium. Wir überprüfen die Verzeichnisstruktur und die Integrität wichtiger Dateien.

Der gesamte Prozess läuft im Modus „Festpreis nach Diagnose”. Sie wissen genau, wie viel die Wiederherstellung kosten wird, wie lange sie dauert und was Sie zurückbekommen. Sollte sich herausstellen, dass die Daten aufgrund vorheriger Eingriffe nicht zu retten sind, zahlen Sie nichts. Für Ihren konkreten Fall nutzen Sie unsere unverbindliche Beratung.

Häufig gestellte Fragen

Das Volume wird nach einem Stromausfall nicht eingebunden, habe ich meine Daten verloren?

Mit hoher Wahrscheinlichkeit nicht. Auf den Plattern der Festplatten sind die Daten noch vorhanden, beschädigt sind nur die Betriebsmetadaten von LVM oder des Thin Pools. Es ist kritisch, das Gerät nicht einzuschalten und keine Reparatur durch Klicken in QTS zu versuchen. Im Labor holen wir die Daten aus Klonen und reparieren das Mapping.

Kann ich die Platten aus dem QNAP ausbauen, in einen PC stecken und die Daten lesen?

Nein. Ein gewöhnlicher Windows-PC enthält keine Treiber für Linux-mdadm-RAID, LVM2 oder ext4. Der Anschlussversuch führt zur Aufforderung, die Festplatte zu initialisieren, was die Daten sofort zerstört. Die Platten müssen zuerst geklont und in einer geeigneten Umgebung analysiert werden.

Hilft die Software QNAP Data Recovery oder TestDisk?

QNAP Data Recovery ist ein Tool zur Wiederherstellung gelöschter Dateien von einem funktionierenden Volume, nicht zur Reparatur eines zerfallenen RAIDs oder beschädigten LVMs. TestDisk ist nützlich, aber zu einfach für die komplexen LVM-Thin-Provisioning-Strukturen von QNAP. Der Start dieser Programme auf einem laufenden, halb zerfallenen Array birgt das Risiko von Schreibzugriffen und der Zerstörung von Konsistenzresten.

Ich hatte ein Thin Volume, ist das schlimmer als Thick?

Ja. Thin Volume ist viel anfälliger für Totalausfälle bei unsauberem Herunterfahren. Seine Metadaten bilden eine Karte, wo auf den Platten die einzelnen Blöcke liegen. Wird diese Karte beschädigt, erscheinen die Daten in Rohform als ein Gewirr zufälliger Blöcke ohne Ordnerstruktur. Ihr Zusammensetzen erfordert tiefgehende Kenntnisse des QTS-Thin-Metadatenformats.

Wie lange dauert die Wiederherstellung und wie sind die Chancen?

Die Dauer hängt vom Schadensumfang ab. Logische Fälle (beschädigte Metadaten, Array-Absturz nach Stromausfall) lösen wir innerhalb weniger Tage nach Anlieferung im Labor. Komplexere Fälle mit physisch defekten Platten und umfangreicher Thin-Pool-Fragmentierung dauern länger. Die realistische Chance und den Umfang der wiederherstellbaren Daten in Ihrem konkreten Fall kann erst eine kostenlose Diagnose bestimmen – bei einem zerfallenen Thin Pool kann das ohne Klone und Offline-Analyse seriös niemand abschätzen.

Was jetzt zu tun ist

Wenn Ihr QNAP gerade einen Fehler meldet, handeln Sie besonnen:

  1. Trennen Sie die Stromversorgung. Halten Sie den Netzschalter gedrückt, bis sich das Gerät ausschaltet, oder ziehen Sie das Netzkabel.
  2. Entnehmen Sie die Platten und markieren Sie die Positionen. Notieren Sie sich sofort mit einem Permanentmarker oder Aufkleber die ursprüngliche Position („Einschub 1”, „Einschub 2”…). Ohne diese Information wird das RAID zu einem unlösbaren Puzzle.
  3. Führen Sie keine Tests durch. Versuchen Sie nicht, die Platten in einem anderen Computer oder NAS zu starten.
  4. Kontaktieren Sie das Labor. Rufen Sie die Nonstop-Leitung +420 775 556 063 an oder nutzen Sie die unverbindliche Beratung.
  5. Übergeben Sie sie an Fachleute. Wir organisieren die Abholung, oder Sie liefern die Platten persönlich in unserem Brünner Labor ab. Bei der kostenlosen Diagnose klonen wir die Platten hardwaretechnisch und nennen Ihnen den genauen Preis und Umfang der wiederherstellbaren Daten, bevor Sie irgendetwas bezahlen.

Zusammenfassung in Stichpunkten

  • Ein QNAP-Ausfall äußert sich am häufigsten als „Volume is not active” nach Beschädigung der LVM-Thin-Metadaten bei einem Stromausfall.
  • Die QTS-Architektur besteht aus mdadm RAID + LVM2 + Thin/Thick/Static Volume (QuTS hero = ZFS) — daher funktioniert das bloße Ausbauen der Platten und Anschließen an einen PC nicht.
  • Der größte Fehler ist das Auslösen von „Recover” oder „Check File System” in der Administration, wodurch Daten oft unwiderruflich überschrieben werden.
  • Die Rettung erfolgt ausschließlich von Bit-für-Bit-Kopien der Platten, um weitere Schäden zu vermeiden.
  • Verfahren des Labors: Hardware-Klonen (DeepSpar/PC-3000), Offline-Zusammenbau von RAID und LVM, spezialisierte Reparatur der Thin-Provisioning-Metadaten.
  • Allgemeine Regeln für Arrays siehe RAID- und NAS-Rettung.

Ihr QNAP Volume startet nicht oder meldet „Volume is not active”? Klicken Sie nicht auf Recover — es überschreibt genau das, woraus sich die Daten zusammensetzen lassen. Unverbindliche Beratung · Kostenlose Diagnose · Kontakt · +420 775 556 063 (NONSTOP)

Siehe auch: Datenrettung von RAID-Arrays · Synology NAS · Server-Datenrettung · RAID & NAS Rettung (Dienstleistung) · Case Study: 20-Disk RAID 6

Über den Autor

Ing. Miroslav Jaroš ist Inhaber und Senior-Techniker der ITHOPE s.r.o. in Brünn. Er widmet sich der Datenrettung seit 2008 – in 18 Jahren durchliefen über 2.500 Aufträge das Labor, von einzelnen Festplatten bis hin zu NAS und Enterprise-RAID-Arrays. Der Artikel wurde einem technischen Faktencheck (Tomáš Kopřiva) anhand der realen Praxis des ITHOPE-Labors unterzogen.