Um weitere Informationen zu den logischen Schäden zu erhalten, wurde ein virtuelles Layout der RAID-Blöcke konstruiert. Dafür waren fehlende oder beschädigte Blöcke neu zu berechnen oder zunächst zu überspringen. Darauf aufbauend konnte dann die Rekonstruktion der Windows Storage Spaces-Ebene erfolgen. Laut DataRecovery gehört das zu den aufwändigsten Abläufen bei einer Datenrettung, weil es sich bei den WSS um eine proprietäre und nicht dokumentierte Technologie handelt. »Nach aktuellem Stand sind uns keine öffentlich verfügbaren Datenrettungstools oder Unternehmen bekannt, die eine Wiederherstellung von Daten innerhalb einer defekten Windows Storage Spaces-Umgebung erfolgreich durchführen können«, betont Jan Binding, CEO von DataRecovery.
Das Unternehmen begann ein vollständiges Re-Engineering der WSS und konnte so ermitteln, dass diese auf mehreren Virtualisierungsschichten basieren. Das bietet eine hohe Flexibilität bei Speicherveränderungen, verkompliziert aber auch den Datenrettungsprozess massiv. Insgesamt gab es durch die Windows Storage Spaces vier zusätzliche virtuelle Ebenen. Die niedrigste wies 117.843 Speicherfragmente auf, die zusammengesetzt werden mussten. Erst danach konnte der virtuelle Storage-Pool nachgebildet werden, aus dem die virtuellen Festplatten rekonstruiert wurden. Dabei galt es laut DataRecovery, über zehn Millionen Informationen innerhalb von Metadaten zu analysieren.
Mit wiederhergestellten Windows Storage Spaces konnten die Speicherbereiche extrahiert werden, welche die virtuellen Festplatten zuvor verwendeten. Alle virtuellen Datenträger, die sich im RAID6-Verbund mit den zuvor fehlerhaft ausgeführten Rebuilds befanden, waren durch die Sc4hreibzugriffe logisch beschädigt. Daher mussten im nächsten Schritt deren interne Datenträgerstruktur und das Dateisystem rekonstruiert werden. Erst dann war es möglich, die eigentlichen Daten – alles in allem mehr als 25 Terabyte – zu extrahieren und alle virtuellen Datenträger wiederherzustellen.