Datenrettung von QNAP NAS TVS-1271U-RP Thin-Provisioning

Die Analyse des Umfangs der Beschädigungen erfolgte im Rahmen unseres High Priority Service - der Fall wurde prioritär und rund um die Uhr bearbeitet. Angesichts des schwerwiegenden Fehlerbilds und der immensen Forschungs- und Entwicklungsarbeit erfolgte die weitere Bearbeitung in der erweiterten Diagnose über mehrere Wochen hinweg.

30. Mai 2018 - Sebastian Evers

Ausgangssituation des Datenverlusts:

Speichermedium mit Datenverlust:

• QNAP TVS-1271U-RP (RAID 5)
  
• insgesamt zehn WD Red Pro Festplatten (Western Digital MDL: WD501FFWX-68Z39N0)
• VMWare / VMS / VMFS
• iSCSI LUNs
  

Zur Wiederherstellung spezifizierte Daten:

• eine Vielzahl virtueller Maschinen (*.vmdk, *.vmx)
  

Ein langjähriger Attingo Partner hat den Fall - das nicht mehr zu erreichende RAID 5 einer Werbeagentur - an Attingo übermittelt. Das NAS System enthielt ein iSCSI LUN mit einem VMFS Dateisystem über die gesamte RAID 5 Kapazität. Das betroffene RAID Array wurde mit fünf Festplattenlaufwerken spezifiziert.

Der ESXi Server gab die Meldung aus, dass das Dateisystem defekt sei und seitdem war kein Zugriff auf den NAS Server mehr möglich. Der Server wurde einige Male neugestartet. Die iSCSI Verbindungen wurden gelöscht und neu initiiert. Es wurde ebenfalls versucht die Shares neu einzubinden und nach dem VMS gesucht. Die Dateninhalte des Servers wurden als existenziell bezeichnet.

Analyse, Durchführung der Datenrettung:

Nachdem das vollständige QNAP NAS mit allen zehn verbauten Datenträgern bei Attingo eingetroffen war, machten sich die Techniker an die 1 zu 1 Kopien der fünf deklarierten Festplattenlaufwerke. Das RAID wurde virtuell simuliert und auf dem Volumen ein völlig intaktes Dateisystem diagnostiziert.

Dabei mussten unsere Techniker feststellen, dass es sich bei dem angegebenen RAID 5 mit den fünf Festplatten anhand der auffindbaren Datenbestände nicht um das betroffene Array handeln konnte. Nach Rücksprache mit dem Kunden wurden dann die sieben weiteren Festplattenlaufwerke kopiert. Bei der Analyse des auf dem System befindlichen LUN wurde festgestellt, dass dieses nur unvollständig vorhanden ist und nicht über die komplette Kapazität reichte.

Auf Basis der modifizierten Thin-Provisioning Variante der QNAP Hardware wurde geprüft, ob die logischen Laufwerke non-linear strukturiert sind und die für die Zuordnung erforderlichen Metadaten möglicherweise korrumpiert sind. Der Kernel, die Module und die LVM Tools des NAS wurden dem "reverse engineering" unterzogen und im weiteren Verlauf die Techniker mit Manipulationen der NAS Hardware das vermeintliche logische Volumen mounten.

Die darin enthaltenen virtuellen Maschinen waren nur bruchstückhaft vorhanden und großflächig überschrieben, während das VMFS Dateisystem intakt war. Die Ursachen dafür ließen sich anhand der bis dato rekonstruierten Thin-Provisioning Konfigurationsparameter und Logfiles nicht erschließen. Die als relevant spezifizierten virtuellen Maschinen wiesen durchweg die Merkmale gelöschter Daten auf. 

Angesichts des erheblichen Aufwands der weiteren Arbeiten wurde eine erweiterte Diagnose eingeleitet. Im Rahmen der mehrwöchigen erweiterten Diagnose hat die Forschungs- und Entwicklungsabteilung eine spezielle Datenbank programmiert. In dieser Datenbank wurden sämtliche bereits extrahierten Metainformationen und Zuordnungstabellen des Thin-Provisionings hinterlegt.

Auf Basis der Datenbank wurde ein Plausibilitätscheck bezüglich der möglichen Variationen durchgeführt. Des Weiteren wurde versucht die extrahierten Informationen der Indexstruktur mit eigens für den Zweck entwickelter Software zu evaluieren. Im Verlauf dessen wurde festgestellt, dass die existierenden Parameter für die Rekonstruktion einer validen Speicherstruktur nicht ausreichend waren. Angesichts der erheblichen logischen Beschädigungen musste Attingo den Fall schließen.

Besonderheit:

Von der relevanten virtuellen Maschine erstellte das NAS jeden Tag ein vollautomatisches Backup (Snapshot). Dieser Snapshot wurde zurück gespielt als die virtuelle Maschine einen Fehler aufwies. Bei dem Vorgang wurde das Backup über die auf dem Produktivsystem befindliche fehlerhafte virtuelle Maschine hinweg geschrieben.

Dabei bestanden unentwegt Benutzerzugriffe auf andere virtuelle Maschinen des Systems und der Server befand sich dauerhaft im Lese-/Schreibzugriff. Es stellte sich heraus, dass die Datensicherung ebenfalls fehlerhaft war. Des Weiteren wurde eine Vielzahl an LVM Grundkonfigurationen (lvcreate, lvchange, lvremove) ausgeführt, deren Umfang sich anhand fehlender Logfiles nicht restlos nachvollziehen ließ. Jedoch schienen diese Maßnahmen mutmaßlich mitverantwortlich für die im Endeffekt vorliegenden schwerwiegenden logischen Schäden.