Kostenlose Datenvernichtung Kostenlose Analyse anfordern →
Leistungen Mehrschichtige Wiederherstellung
+32 (0)800 11 400 Kostenlose Analyse anfordern

Enterprise und Rechenzentrum

Mehrschichtige Wiederherstellung (Multi-Layer Recovery)

Daten liegen kaum noch direkt auf einer Festplatte. Sie stecken in einer Datenbank, in einem virtuellen Datenträger, auf einem deduplizierten Volume, auf einem RAID. Ist eine Schicht beschädigt, nutzen wir die anderen Schichten, um sie zu rekonstruieren.

Was ist eine mehrschichtige Konfiguration?

In einer modernen Serverumgebung ist jede Schicht ein Container für die nächste: Das RAID stellt ein Volume bereit, das Volume erhält eine Partitionierung und ein Dateisystem, auf diesem Dateisystem liegen virtuelle Datenträger, darin steckt erneut ein Dateisystem, und darauf liegen die Dateien einer Anwendung, etwa einer Exchange- oder SQL-Datenbank.

Jede Schicht interpretiert die Bytes der darunterliegenden. Ist eine Schicht beschädigt, wird alles darüber unlesbar, obwohl die Daten selbst noch vollständig vorhanden sind. Dann gilt es, die beschädigte Schicht neu aufzubauen, damit die Schichten darüber wieder stimmen.

Eine beschädigte Schicht bedeutet selten, dass die Daten darüber verloren sind. Meist fehlt der Schlüssel, um sie zu lesen, nicht der Inhalt.

Die Schichten, von unten nach oben

SchichtBeispieleWas oft schiefgeht
Speicher und RAID Festplatten, RAID-Controller, NAS, SAN Defekte Platten, verlorene RAID-Konfiguration
Partitionierung MBR, GPT, LVM, Speicherplätze Überschriebene Partitionstabelle, versehentlich initialisierte Platte
Dateisystem (Native File System) NTFS, ReFS, ext4, XFS, ZFS, Btrfs, VMFS Beschädigte Metadaten, Formatierung, missglückte Prüfung
Deduplizierung (Deduplication) Windows-Server-Deduplizierung, ZFS-Dedup, Backup-Appliances Beschädigter Chunk Store oder Index
Virtualisierung VMware vSphere, Hyper-V, Proxmox und KVM Gelöschte virtuelle Maschine, abgerissene Snapshots
Virtueller Datenträger (Virtual Disk Image) VMDK, VHDX, qcow2, raw Über den Datastore verstreut, beschädigter Header oder Blocktabelle
Gast-Dateisystem (Guest File System) NTFS, ext4, XFS in der virtuellen Maschine Dieselben Probleme wie bei jedem Dateisystem
Anwendung Exchange (ESE), SQL Server, Oracle, Mailarchive Beschädigte Seiten, fehlende Logdateien
Backup Veeam® (.vbk, .vib, .vrb) und andere Backup-Software Beschädigte Backup-Kette, Backup-Dateien auf defektem Speicher
Technisch: wie virtuelle Datenträger ihre Blöcke verwalten

Ein virtueller Datenträger, der nicht vorab vollständig zugewiesen ist (Thin Provisioned, Sparse), führt eine Tabelle, in der steht, wo jeder Block des virtuellen Datenträgers in der Datei liegt: bei VMDK das Grain Directory und die Grain Tables, bei VHDX die Block Allocation Table (BAT), bei qcow2 die L1- und L2-Tabellen.

Snapshots und differenzierende Datenträger (VMware-Delta-Dateien, Hyper-V .avhdx) bilden eine Kette: Jede Datei enthält nur die geänderten Blöcke und verweist auf ihren Vorgänger. Ist ein Glied oder der Verweis darauf beschädigt, muss die Kette neu aufgebaut werden, um den aktuellen Zustand des Datenträgers zu erhalten.

Das Prinzip: Die anderen Schichten verraten, was fehlt

Jede Schicht enthält, gewollt oder nicht, Informationen über die Schichten um sie herum. Diese nutzen wir in drei Richtungen:

  1. Von oben nach unten. Der Inhalt einer höheren Schicht verrät, wie eine tiefere aufgebaut war. Eine Datei in der virtuellen Maschine, die über zwei Fragmente des virtuellen Datenträgers läuft, bestätigt, dass diese Fragmente zusammengehören; so lässt sich ein verstreuter virtueller Datenträger in die richtige Reihenfolge bringen, auch wenn seine Blocktabelle fehlt. Und das Dateisystem in einer Partition nennt seine eigene Größe, woraus folgt, wo die Partition lag, selbst wenn die Partitionstabelle überschrieben wurde.
  2. Von unten nach oben. Eine intakte tiefere Schicht grenzt die Suche in der höheren ein. Weiß das Dateisystem des Datastores noch, welche Blöcke zu welchem virtuellen Datenträger gehören, suchen wir die Strukturen eines beschädigten Gast-Dateisystems nur in diesen Blöcken, und in der richtigen Reihenfolge.
  3. Innerhalb der Schicht. Viele Formate bestehen aus Blöcken oder Seiten fester Größe mit eigener Kennung oder Prüfsumme (Checksum). Eine SQL-Server-Datenbankseite nennt zum Beispiel ihre eigene Seitennummer. So lassen sich einzelne Teile erkennen, prüfen und in die richtige Reihenfolge bringen.
Technisch: Beispiele für Sicherungskopien und Kennungen

GPT speichert eine Sicherungskopie des Headers und der Partitionstabelle am Ende der Platte. NTFS hält eine Kopie des Bootsektors am Ende des Volumes sowie eine Teilkopie der MFT (MFTMirr). ext4 und XFS speichern Kopien ihres Superblocks über das Volume verteilt.

SQL Server arbeitet mit Seiten von 8 KB, mit Datei- und Seitennummer im Header. Exchange (ESE) nutzt seit Exchange 2010 Seiten von 32 KB, jede mit eigener Prüfsumme. Solche Kennungen ermöglichen es, Seiten zwischen anderen Daten wiederzufinden.

Deduplizierung: eine Schicht, die alles zerstückelt

Deduplizierung (Deduplication) speichert jedes eindeutige Datenstück (Chunk) nur einmal. Eine Datei ist dann keine zusammenhängende Folge von Blöcken mehr, sondern eine Liste von Verweisen auf Chunks in einem gemeinsamen Speicher (Chunk Store). Bei der Windows-Server-Deduplizierung bleiben die Dateien als Verweise (Reparse Points) sichtbar, während ihr Inhalt im Chunk Store liegt.

Ist der Index oder der Chunk Store beschädigt, scheinen die Dateien noch da zu sein, lassen sich aber nicht öffnen. Dabei enthält der Chunk Store den vollständigen Inhalt. Die Schicht darüber, etwa ein virtueller Datenträger mit erkennbarer Struktur, hilft dann, die Chunks wieder richtig zu ordnen.

Backups als zusätzliche Schicht

Oft ist das Backup selbst die letzte Schicht, auf die es ankommt: Die Backup-Dateien von Veeam®, Backup Exec, Macrium Reflect oder anderer Software liegen auf einem NAS, einem RAID oder einem deduplizierten Volume, das ausgefallen ist. Dann holen wir zuerst den Speicher zurück, danach die Backup-Dateien und erst dann die Daten darin, auch wenn die Backup-Dateien selbst beschädigt sind.

Alles zur Wiederherstellung unzugänglicher Backups →

Szenarien aus der Praxis

Gelöschte virtuelle Maschine

Eine virtuelle Maschine wurde von einem VMFS-Datastore gelöscht. Der Platz ist freigegeben, aber die Blöcke des virtuellen Datenträgers sind oft noch da; mit der Struktur des Gast-Dateisystems werden sie gefunden und zusammengesetzt.

Abgerissene Snapshot-Kette

Eine Hyper-V- oder VMware-Umgebung mit Snapshots, von denen ein Glied beschädigt ist. Die virtuelle Maschine startet nicht mehr; der Neuaufbau der Kette bringt den letzten Zustand zurück.

Virtualisierter Exchange-Server

RAID, VMFS, VMDK, NTFS und eine Exchange-Datenbank übereinander. Eine beschädigte Schicht genügt, um die Postfächer unerreichbar zu machen; die anderen Schichten helfen, sie zu reparieren, bis die Datenbank wieder lesbar ist.

Warum Standardsoftware hier hängen bleibt

Gewöhnliche Wiederherstellungssoftware arbeitet mit einer Schicht nach der anderen und setzt voraus, dass die Schichten darunter in Ordnung sind: Ein Dateisystem-Werkzeug erwartet eine korrekte Partition, ein VMDK-Werkzeug einen lesbaren Datastore, ein Datenbank-Werkzeug einen intakten virtuellen Datenträger. In einer mehrschichtigen Konfiguration mit Schäden auf mehr als einer Ebene stimmt diese Annahme nicht mehr.

Deshalb betrachten wir den ganzen Stapel auf einmal und bestimmen je Schicht, welche Informationen aus den anderen Schichten für die Rekonstruktion nötig sind.

Was Sie tun sollten

Das sollten Sie tun

  • Stoppen Sie die virtuellen Maschinen und alles, was auf den betroffenen Speicher schreibt.
  • Bewahren Sie die Konfiguration auf: VM-Einstellungen (.vmx oder die Hyper-V-Konfiguration), eine Übersicht der Datastores und Snapshots.
  • Notieren Sie den ganzen Aufbau: RAID, Volumes, Deduplizierung, Virtualisierung, Anwendungen.
  • Bewahren Sie die Logs von Hypervisor, Speicher und Anwendung auf.

Das sollten Sie lassen

  • Keine Snapshots zusammenführen (Consolidate) oder löschen.
  • Keinen Datastore und kein Volume neu anlegen oder formatieren.
  • Keine Wartungsaufgaben der Deduplizierung laufen lassen, etwa die Bereinigung (Garbage Collection).
  • Keine Reparaturwerkzeuge in der virtuellen Maschine oder auf der Datenbank ausführen, etwa chkdsk oder eseutil /p.

So läuft ein Auftrag ab

  1. Analyse je Schicht. Wir erfassen den gesamten Aufbau und bestimmen, welche Schichten beschädigt sind.
  2. Kopien. Von jeder Platte erstellen wir eine vollständige Kopie; physisch beschädigte Platten reparieren wir zuerst in unserem Class-1-Labor.
  3. Rekonstruktion. Wir beginnen bei der tiefsten beschädigten Schicht und nutzen die Informationen aus den anderen Schichten, um sie aufzubauen, Schicht für Schicht, bis zur Anwendung.
  4. Kontrolle auf Anwendungsebene. Eine Datenbank muss nicht nur zurück sein, sondern sich auch öffnen lassen. Wir prüfen das Ergebnis auf der Ebene, auf der Sie es nutzen.
  5. Lieferung. Als Dateien, als virtueller Datenträger, den Sie wieder einbinden können, oder als Datenbank. Sie sehen das Ergebnis, bevor Sie bezahlen.

Bei sehr großen Volumes kombinieren wir dies mit unserem Ansatz in drei Prozessen.

Mehr zur Wiederherstellung großer Volumes →

Warum es bei uns gelingt

Mehr über unser Labor →
  • Fast 20.000 Spenderfestplatten Das passende Teil liegt meist bereit.
  • Röntgen im eigenen Haus Erst sehen, dann eingreifen.
  • Rework und Reballing Chips sicher aus- und eingelötet.
  • Eigene Software Bis zu Hunderten Terabyte.
  • Mobiler Reinraum Der Datenträger bleibt in Ihrem Gebäude.
  • Seit 1988 Fast vierzig Jahre Ausrüstung und Erfahrung.

Eine virtuelle Umgebung, die nicht mehr startet?

Hören Sie auf zu schreiben, notieren Sie den Aufbau und rufen Sie uns an oder fragen Sie eine Analyse an. Gemeinsam prüfen wir, welche Schichten beschädigt sind und was möglich ist.