Zwei Fragen, zwei Aufträge

Datenrettung beantwortet eine Frage: Sind die Daten noch da, und wie kommen sie zurück? IT-Forensik beantwortet andere Fragen: wer, was, wann und von wo. Beide Disziplinen arbeiten am selben Datenträger, aber mit gegensätzlichen Prioritäten. Bei der Wiederherstellung zählt das Ergebnis, bei der forensischen Sicherung zählt der unveränderte Zustand. Wer den zweiten Auftrag braucht und den ersten erteilt, bekommt seine Dateien zurück und verliert dabei möglicherweise die Spuren, mit denen sich der Hergang belegen lässt.

Ob ein Fall forensisch ist, entscheidet sich an wenigen Anzeichen. Daten fehlen, ohne dass ein Laufwerk Symptome zeigt. Die Löschung fällt zeitlich mit einem Personalwechsel, einer Kündigung oder einem Streit um Kundendaten zusammen. Im Ereignisprotokoll tauchen Anmeldungen zu ungewöhnlichen Uhrzeiten auf, neue Administratorkonten oder Zugriffe von unbekannten IP-Adressen. Eine Erpressernachricht liegt auf dem Desktop. Trifft eines davon zu, ändert sich die Reihenfolge: erst sichern, dann wiederherstellen.

Warum der erste Zugriff Spuren überschreibt

Ein Dateisystem vergisst nichts sofort, aber es räumt ständig auf. Wird unter Windows eine Datei gelöscht, bleibt ihr Eintrag in der Master File Table (MFT) von NTFS zunächst als frei markiert stehen, mit Namen, Zeitstempeln, Größe und Verweisen auf die Datenblöcke. Diese Einträge vergibt das System an die nächsten neuen Dateien. Jede Installation und jedes Update belegt einige davon, ein Backup, das auf dasselbe Volume zurückgespielt wird, belegt sie in großer Zahl. Mit jedem neu beschriebenen Sektor verschwindet ein Stück des gelöschten Bestands.

Dazu kommen die Protokolle. Das Änderungsjournal von NTFS und das Transaktionsprotokoll des Dateisystems sind Ringpuffer mit fester Größe, ältere Einträge werden überschrieben, sobald neue nachkommen. Das Sicherheitsprotokoll von Windows verhält sich in der Standardkonfiguration ähnlich. Ein Server, der nach dem Vorfall noch Tage im Normalbetrieb läuft, schreibt die Nacht der Löschung Stück für Stück aus seinem Gedächtnis.

Bei SSDs kommt ein Effekt hinzu, den viele Administratoren unterschätzen. Nach dem Löschen meldet das Betriebssystem dem Laufwerk per TRIM-Befehl, welche Blöcke frei sind, und der Controller kann sie im Hintergrund leeren, um sie für neue Schreibvorgänge vorzubereiten. Wie schnell das geschieht, hängt von Betriebssystem, Dateisystem, Controller und Laufwerk ab, in ungünstigen Fällen setzt der Vorgang kurz nach dem Löschen ein, ohne dass jemand eine Datei anfasst. Eine SSD, die nach einer verdächtigen Löschung weiterläuft, verliert damit unter Umständen Beweise, die auf einer klassischen Festplatte noch Monate lesbar wären.

Wie ein forensisches Duplikat entsteht

Die forensische Sicherung dreht die Logik der Datenrettung um. Am Anfang steht die Zusage, dass sich am Original nichts mehr ändert. Dafür wird der Datenträger in der Forensik hinter einem hardwareseitigen Schreibschutz angeschlossen, der jeden Schreibbefehl des Analyserechners abfängt, und anschließend bitweise kopiert: Sektor für Sektor, einschließlich der freien Bereiche und des Slack Space, in denen gelöschte Daten liegen können und die ein normaler Dateikopierer auslässt.

DATA REVERSE® fertigt für die Auswertung solche 1:1-Kopien an und berechnet direkt nach dem Kopieren einen Hashwert über das Original und über die Kopie, einen digitalen Fingerabdruck, der sich schon bei einem einzigen veränderten Bit ändert. Stimmen beide Werte überein, ist belegt, dass das Duplikat vollständig und unverändert ist. Die Werte werden dokumentiert, alle weiteren Analysen laufen ausschließlich auf der Kopie, das Original bleibt im Ausgangszustand und kann als Beweismittel dienen. Ist das Laufwerk physisch beschädigt, geht die Datenrettung der Forensik voraus: Der lesbare Bestand wird zunächst unter dokumentierten Bedingungen gesichert, und erst diese Sicherung geht in die Auswertung.

Was die Auswertung liefert und was sie braucht

Auf dem Duplikat rekonstruieren die Forensiker anschließend, was sich auf dem Datenträger befand und was damit geschah: gelöschte Dateien und Fragmente mit ihren Metadaten, Zeitstempel, Protokolleinträge, Spuren angeschlossener USB-Geräte, Anmeldungen und Zugriffe. Das Ergebnis ist ein zeitlicher Ablauf des Vorfalls in einem Analysebericht, der für interne Untersuchungen, Versicherer, Aufsichtsbehörden oder ein Gerichtsverfahren aufbereitet wird.

Damit das gelingt, braucht der Forensiker vorab eine Zielstellung. „Finden Sie heraus, was passiert ist" reicht dafür nicht aus, weil dann Tausende Einträge ohne Filter durchsucht werden müssen. Tragfähig sind Fragen wie: Wurde der Ordner „Projekte 2026" zwischen dem 5. und dem 8. September gelöscht, und von welchem Konto? Wurde in diesem Zeitraum ein externer Datenträger angeschlossen, und welche Seriennummer hatte er? Je präziser die Frage, desto belastbarer die Antwort. Der Aufwand wird nach Stunden abgerechnet, das Budget vorab abgesteckt.

Meldepflicht und Versicherung hängen am Hergang

Ist nach einem Vorfall eine Meldung nach Artikel 33 DSGVO erforderlich, muss sie unter anderem die Art der Verletzung, die betroffenen Datenkategorien, die ungefähre Zahl der Betroffenen und die wahrscheinlichen Folgen beschreiben. Wer nach einem Backup-Restore nur noch weiß, dass Daten fehlten, kann diese Angaben nicht machen. Versicherer verlangen für die Regulierung eines Cybervorfalls in der Regel ebenfalls eine nachvollziehbare Dokumentation. Beides setzt voraus, dass die Spuren am ersten Tag gesichert wurden.

Was vor dem ersten Wiederherstellungsversuch geschehen sollte

– Das betroffene System vom Netzwerk trennen und nicht weiter bedienen. Ob es eingeschaltet bleibt oder kontrolliert heruntergefahren wird, sollte der Forensiker im Einzelfall entscheiden, weil sowohl der Arbeitsspeicher als auch Hintergrundprozesse des Laufwerks für die Analyse eine Rolle spielen können.
– Kein Backup auf dasselbe Volume zurückspielen, keine Reparaturwerkzeuge, kein chkdsk, keine Recovery-Software.
– Die Backup-Rotation anhalten, damit die letzte Sicherung vor dem Vorfall nicht turnusmäßig überschrieben wird.
– Jeden Zugriff seit dem Vorfall notieren: wer, wann, was, mit welchem Konto.
– Nicht selbst nach Spuren suchen. Das Durchsuchen der Freigaben durch Administratoren erzeugt neue Protokolleinträge und verdrängt alte.
– Eine konkrete Zielstellung formulieren, bevor der Datenträger das Haus verlässt.

DATA REVERSE® bietet IT-Forensik ergänzend zur Datenrettung an, mit Schwerpunkt auf Dateisystem-, Betriebssystem- und Smartphone-Forensik. Das Unternehmen ist nach ISO 9001 und ISO/IEC 27001 zertifiziert, arbeitet mit Geheimhaltungsvereinbarung und Vertrag zur Auftragsverarbeitung und beschäftigt einen eigenen Datenschutzkoordinator. Aufträge mit der Einstufung „VS-Vertraulich" werden von Mitarbeitern mit Sicherheitsüberprüfung Ü1 nach § 8 SÜG bearbeitet. Ob ein Vorfall am Ende arbeitsrechtlich, strafrechtlich oder gar nicht weiterverfolgt wird, entscheidet sich oft erst Wochen später. Diese Entscheidung bleibt nur offen, wenn die Beweise am ersten Tag gesichert wurden.

Transparenzhinweis: Die Datenrettung erfolgte im Rahmen einer Medienkooperation ohne Berechnung. Esther Graf dokumentiert den Fall dafür auf ihren offiziellen Künstlerkanälen und verweist dort auf DATA REVERSE®.

Auf dem Gerät lag die Arbeit eines Jahres: Sprachmemos mit Songideen, von denen es einige auf das fertige Album geschafft haben, Songtexte in den Notizen, Musikvideos, Fotos und die kurz zuvor produzierten Acoustic Sessions, die für die Kampagne eingeplant waren. Dazu Videos, die auf TikTok bereits viral gegangen waren. Für eine Künstlerin ist so ein Gerät Archiv und Notizblock in einem.

Im Apple Store konnte Graf niemand weiterhelfen. Ihr Team schlug vor, die Acoustic Sessions noch einmal neu zu drehen, was mitten in einer laufenden Kampagne Tage an Studio- und Drehzeit gekostet hätte. In ihren Videos beschreibt Graf, dass sie stattdessen gezielt nach Spezialisten für Datenrettung gesucht und bei DATA REVERSE® angerufen habe. Ausschlaggebend war für sie nach eigener Aussage der Umgang mit ihren persönlichen Daten.

Ziel des Auftrags waren die Daten, das Gerät selbst spielte nur als Träger eine Rolle. Graf sendete das iPhone ein und bekam während der Analyse täglich eine Rückmeldung zum Stand. Eine Erfolgsgarantie gab es vorab nicht. Nach rund einer Woche gingen das Gerät und eine externe Festplatte mit den wiederhergestellten Daten an sie zurück, der Bestand war in diesem Fall vollständig.

Warum ein iPhone aufwendiger ist als eine Festplatte

Bei dem betroffenen iPhone 15 Pro Max war nach dem fehlgeschlagenen Systemstart kein regulärer Zugriff auf die gespeicherten Daten mehr möglich, das Gerät befand sich dauerhaft in einer Bootschleife. Die technische Analyse zeigte Probleme bei der Speicher- und Systeminitialisierung und dazu ein auffälliges elektrisches Startverhalten im Bereich der Logic-Board-Elektronik.

Bei aktuellen iPhones sind die Benutzerdaten hardwaregebunden verschlüsselt. Den Speicherchip separat auszulesen führt deshalb nicht zum Ziel: Für einen verwertbaren Datenzugriff müssen zentrale Komponenten der originalen Gerätearchitektur weiterhin korrekt zusammenspielen.

Das Labor analysierte zunächst die für den Startvorgang relevanten Speicher- und Systemstrukturen, darunter temporäre System-, Cache- und Auslagerungsbereiche, die den Start beeinträchtigten. Anschließend ließ sich die kritische Initialisierungsphase gezielt stabilisieren und genug Systemressourcen für einen kontrollierten Start bereitstellen. In dem so entstandenen Zugriffsfenster initialisierte sich die Sicherheits- und Speicherarchitektur des Geräts wieder vollständig, erst dadurch ließen sich die verschlüsselten Benutzerdaten regulär entschlüsseln und sichern.

Bei modernen Smartphones entscheidet das Zusammenspiel von Speicher, Prozessor, Sicherheitsarchitektur und Systemsoftware darüber, ob ein Datenzugriff überhaupt möglich wird. Der physische Speicherchip allein führt nicht ans Ziel. Ein Zugriffsfenster entsteht in der Laborpraxis erst dann, wenn diese Komponenten wieder kontrolliert zusammenarbeiten, und ob sich dieser Zustand herstellen lässt, zeigt sich in jedem Fall neu.

In ihren Videos schildert Graf, wie sie die Daten auf ihr neues Gerät übertragen hat und dass der Bestand vollständig war. Sie beschreibt außerdem, dass ihr der Wert dieser Daten erst bewusst geworden sei, als sie nicht mehr erreichbar waren.

Was Betroffene vorbeugend tun können

Der freie Speicher auf dem Gerät und in der Cloud gehört regelmäßig kontrolliert, ebenso das Datum der letzten erfolgreichen Sicherung. Bei iOS steht es unter Einstellungen, Apple-Konto, iCloud, iCloud-Backup. Eine zweite Sicherung außerhalb der Cloud, lokal auf dem Rechner oder auf einer externen Festplatte, fängt genau den Fall ab, in dem der Cloud-Speicher voll läuft.

Fällt ein Gerät aus, raten die Spezialisten von wiederholten Startversuchen ab und vor allem von einer Wiederherstellung über Finder oder iTunes. Ein Restore setzt das Gerät zurück und kann dabei die Daten überschreiben, um die es geht. Wer die Daten braucht, klärt vor der Abgabe ausdrücklich, dass der Auftrag den Daten gilt und nicht der Reparatur.

Esther Graf dokumentiert den Fall in mehreren kurzen Videos auf ihren offiziellen Kanälen, die Links stehen unter dieser Meldung.

Verschlüsselt, ohne es zu wissen

Windows aktiviert die Geräteverschlüsselung bei geeigneten Geräten inzwischen häufig automatisch. Bei Neuinstallationen von Windows 11 ab Version 24H2 wird die automatische Geräteverschlüsselung vorbereitet und nach Anmeldung mit einem Microsoft- oder Entra-Konto aktiviert; der Wiederherstellungsschlüssel landet dann automatisch im jeweiligen Konto. Bei lokalen Konten greift diese automatische Aktivierung nicht. Risiken entstehen vor allem bei Geräten, deren Schlüssel nicht zentral dokumentiert wurde – etwa nach manueller BitLocker-Aktivierung, bei übernommenen Bestandsgeräten oder nach Änderungen an der Geräteverwaltung. In Unternehmen ohne zentrale Verwaltung über Active Directory oder Microsoft Entra ID weiß häufig niemand, welche Geräte im Bestand überhaupt verschlüsselt sind und wo die zugehörigen Schlüssel liegen.

Wann BitLocker den Schlüssel verlangt

Bei Systemlaufwerken prüft das Trusted Platform Module (TPM) beim Start, ob die Startumgebung unverändert ist. Registriert das Modul eine Abweichung, gibt es den Schlüssel nicht frei, und Windows fragt den Wiederherstellungsschlüssel ab. Auslöser können UEFI- und Firmware-Updates sein, Änderungen an Secure-Boot-Einstellungen, ein zurückgesetztes TPM oder der Einbau des Laufwerks in einen anderen Rechner. Nach einem Mainboard-Defekt steht auch das bisherige TPM nicht mehr zur Verfügung. Dann wird ein außerhalb des Geräts gesicherter Wiederherstellungsmechanismus entscheidend – in typischen Konfigurationen der 48-stellige Recovery-Key.

Was das Labor leisten kann und wo die Grenze liegt

Physisch beschädigte, verschlüsselte Datenträger untersucht DATA REVERSE® im eigenen Labor in Leipzig. Elektronik- und Controllerfehler bei SSDs werden unter kontrollierten Laborbedingungen diagnostiziert, mechanisch beschädigte Festplatten unter Reinraumbedingungen geöffnet. Von den lesbaren Bereichen entsteht eine sektorbasierte Arbeitskopie. Auf diesem Abbild wird das Volume rekonstruiert und die BitLocker-Metadatenstruktur lokalisiert. BitLocker legt diese Strukturen redundant auf dem Laufwerk ab, was bei teilweise beschädigten Datenträgern zusätzliche Ansatzpunkte für die Rekonstruktion bieten kann.

Die Entschlüsselung selbst setzt in jedem Fall vorhandenes Schlüsselmaterial voraus: den 48-stelligen Wiederherstellungsschlüssel, das Kennwort oder einen gesicherten Startschlüssel. Liegt nichts davon vor, bleiben die Daten verschlüsselt. Die eingesetzte AES-Verschlüsselung lässt sich mit heutiger Technik nicht umgehen, auch nicht in einem spezialisierten Labor. Zu einer seriösen Beratung gehört, das vor Auftragsbeginn klar zu benennen.

Was Unternehmen jetzt prüfen sollten

Erstens: Welche Geräte im Bestand sind verschlüsselt? Der BitLocker-Status lässt sich unter Windows je Gerät auslesen.

Zweitens: Liegt für jedes verschlüsselte Gerät ein Wiederherstellungsschlüssel an zentraler Stelle vor, etwa im Active Directory, in Microsoft Entra ID oder in einer dokumentierten, zugriffsgeschützten Ablage?

Drittens: Passt der hinterlegte Schlüssel zum Gerät? Die Wiederherstellungsabfrage zeigt eine Schlüssel-ID an. Ob der dokumentierte Schlüssel zu dieser ID gehört, sollte vor dem Ernstfall geprüft werden.

Viertens: Werden vor Firmware-Updates, Mainboard-Reparaturen und TPM-Änderungen die Schlüssel bereitgelegt? Und existiert unabhängig davon eine getestete Datensicherung, die nicht auf demselben verschlüsselten Laufwerk liegt?

DATA REVERSE® ist nach ISO 9001 und ISO/IEC 27001 zertifiziert und behandelt verschlüsselte Datenträger sowie übergebenes Schlüsselmaterial nach dokumentierten Sicherheitsprozessen.

Kleinere Kanzleien betreiben ihre IT häufig ohne externe Betreuung. Die Administration übernimmt ein technisch versierter Mitarbeiter im Nebenamt, der Server läuft über Jahre ohne systematische Überwachung.

DATEV, Mandantenakten, Lohnabrechnung: ein Server für alles

DATEV-Anwendungen arbeiten mit anwendungsspezifischen Datenbeständen, darunter Datenbanken des Microsoft SQL Server (DATEV). Eine einfache Kopie einzelner Dateien genügt deshalb nicht zwingend für eine funktionsfähige Wiederherstellung. Datenbankdateien, Transaktionsinformationen, Dokumentablagen und die zugehörige DATEV-Umgebung müssen zusammenpassen und in einem verwertbaren Zustand vorliegen.

Bei lokalen Installationen liegen Finanzbuchhaltung, Lohnabrechnung, Jahresabschlüsse, die elektronische Mandantenakte und das Dokumentenmanagementsystem auf einem einzigen Server. Das unterscheidet den DATEV-Datenbestand von einer einfachen Dateiablage und macht die Wiederherstellung anspruchsvoller als bei einer reinen Ordnerstruktur.

Aufbewahrungspflichten, die keinen Datenverlust verzeihen

Steuerberater arbeiten mit Unterlagen, für die unterschiedliche gesetzliche Aufbewahrungsfristen gelten. Bücher, Jahresabschlüsse und die zu ihrem Verständnis erforderlichen Organisationsunterlagen sind zehn Jahre aufzubewahren. Für Buchungsbelege gilt seit dem 1. Januar 2025 eine Frist von acht Jahren, für Handels- und Geschäftsbriefe eine Frist von sechs Jahren. Diese Fristen gelten unabhängig davon, ob die Unterlagen auf Papier oder digital geführt werden.

Wer digitale Belege führt, muss deren Unveränderbarkeit, Nachvollziehbarkeit und maschinelle Auswertbarkeit über den gesamten Aufbewahrungszeitraum sicherstellen. Ein Datenverlust kann die Kanzlei daran hindern, ihre Mandate ordnungsgemäß zu bearbeiten und aufbewahrungspflichtige Informationen bereitzustellen. Die originäre Verantwortung für die Ordnungsmäßigkeit der Buchführung verbleibt zwar beim jeweiligen Steuerpflichtigen. Die Kanzlei muss jedoch sicherstellen, dass die ihr überlassenen Daten im Rahmen der Mandatsbearbeitung geschützt, verfügbar und nachvollziehbar verarbeitet werden.

Hinzu kommt das berufsrechtliche Mandantengeheimnis nach § 57 des Steuerberatungsgesetzes. Es verpflichtet Steuerberater zur Verschwiegenheit über alle Tatsachen, die ihnen im Rahmen der Berufsausübung bekannt geworden sind. Muss eine Kanzlei einen externen Datenrettungsdienstleister einschalten, gelten darüber hinaus die Anforderungen des § 62a StBerG: Der Dienstleister ist sorgfältig auszuwählen, vertraglich zur Verschwiegenheit zu verpflichten und darf nur in dem Umfang auf Mandantendaten zugreifen, der für die Wiederherstellung erforderlich ist. Zusätzlich ist zu prüfen, ob eine Vereinbarung zur Auftragsverarbeitung nach DSGVO erforderlich ist, soweit personenbezogene Daten verarbeitet werden.

Warum die Kanzlei-Datensicherung im Ernstfall versagen kann

Für lokale DATEV-Installationen stellt DATEV konkrete Verfahren zur Sicherung der relevanten Dateien und Datenbanken bereit, darunter Verfahren für die vollständige Sicherung der DATEV-Daten und für den Microsoft SQL Server (DATEV). Alternativ können Kanzleien ihre IT in einer gehosteten Umgebung wie DATEVasp betreiben, bei der Betrieb, Wartung und regelmäßige Datensicherung im DATEV-Rechenzentrum erfolgen.

In der Praxis setzen Kanzleien mit lokaler Installation jedoch oft auf einfache Sicherungskonzepte: eine USB-Festplatte, die abends angeschlossen und morgens mitgenommen wird, oder ein NAS im selben Raum. Risiken entstehen, wenn das Sicherungsmedium physisch neben dem Server steht und bei einem Wasserschaden oder Überspannungsereignis mitbetroffen ist. Oder wenn die eingesetzte Backup-Software die laufenden DATEV-Datenbanken nicht anwendungskonsistent erfasst und entsprechende Fehlermeldungen im Sicherungsprotokoll unbemerkt bleiben. Ob aus einem vorhandenen Backup ein funktionsfähiger DATEV-Arbeitsplatz rekonstruiert werden kann, wurde in vielen Fällen nie getestet.

Was im Schadensfall möglich ist

Bei RAID-Verbünden mit mechanisch beschädigten Festplatten untersucht DATA REVERSE® die Laufwerke einzeln im eigenen Labor in Leipzig. Von den noch lesbaren Bereichen entstehen sektorbasierte Arbeitskopien. Mechanisch beschädigte Laufwerke, etwa mit defekten Schreib-Lese-Köpfen, werden unter Reinraumbedingungen geöffnet. Nach dem Austausch der betroffenen Bauteile können weitere Sektoren kontrolliert ausgelesen werden. Elektronik- und Controllerfehler werden gesondert diagnostiziert und erfordern nicht automatisch das Öffnen des Datenträgers.

Bei einem RAID-1-Verbund werden die Daten aus den gewonnenen Abbildern abgeglichen. Dabei werden die jeweils lesbaren und aktuellsten Datenbereiche zusammengeführt, bevor das Dateisystem rekonstruiert wird. Der kritische Schritt folgt danach: Die DATEV-Datenbankdateien müssen in einem transaktionskonsistenten Zustand extrahiert werden. Datenbanken, die während eines laufenden Schreibvorgangs durch den Serverausfall abgebrochen wurden, können inkonsistente Einträge enthalten. Nach der Rekonstruktion werden die wiederhergestellten Datenbestände in einer geeigneten DATEV-Umgebung geprüft. Ob Finanzbuchhaltung, Lohnabrechnung und Mandantenakten anschließend wieder geöffnet und weiterverarbeitet werden können, hängt wesentlich davon ab, ob die Originaldatenträger unverändert geblieben sind.

DATA REVERSE® ist nach ISO 9001 und ISO 27001 zertifiziert. Ein nach ISO 27001 zertifiziertes Informationssicherheits-Managementsystem kann Kanzleien bei der sorgfältigen Auswahl eines Dienstleisters unterstützen. Es ersetzt jedoch weder die vertragliche Verschwiegenheitsverpflichtung nach § 62a StBerG noch die datenschutzrechtliche Prüfung des konkreten Auftrags.

Was Kanzleien jetzt prüfen sollten

Erstens: Erfasst die Datensicherung die DATEV-Datenbanken anwendungskonsistent, und weist das Sicherungsprotokoll einen erfolgreichen Abschluss aus?

Zweitens: Wurde jemals getestet, ob sich aus der vorhandenen Sicherung ein funktionsfähiger DATEV-Arbeitsplatz wiederherstellen lässt, einschließlich Finanzbuchhaltung, Mandantenakte und Dokumentenmanagement?

Drittens: Liegt das Sicherungsmedium physisch am selben Standort wie der Server? Falls ja, ist es bei Feuer, Wasser oder Überspannung mitgefährdet.

Viertens: Wer überwacht RAID-Status, Controller-Meldungen und den Zustand der eingesetzten Datenträger? SMART-Werte und Ereignisprotokolle können auf wachsende Probleme hinweisen, ersetzen aber keine getestete Datensicherung.

DATA REVERSE® analysiert und rekonstruiert ausgefallene Enterprise-SSDs im eigenen Labor in Leipzig. Was diese Datenträger von mechanischen Festplatten unterscheidet und warum ihre Rettung eigene Verfahren erfordert, zeigt ein Blick auf die Technik hinter der Ausfalllogik.

Was in einer SSD passiert, das von außen unsichtbar bleibt

Im Inneren einer SSD arbeiten NAND-Flash-Bausteine, ein Controller und je nach Modell ein zusätzlicher DRAM-Puffer. Der Controller verwaltet die Flash Translation Layer (FTL), die logische Blockadressen des Hostsystems den physischen Speicherbereichen im NAND zuordnet. Er steuert Wear Leveling, führt Fehlerkorrektur durch und verarbeitet TRIM- beziehungsweise Deallocate-Befehle.

Teile der Mapping-Informationen können während des Betriebs im flüchtigen Speicher vorgehalten werden. Kann die Firmware die persistent gespeicherten Metadaten nicht mehr lesen oder korrekt verarbeiten, initialisiert die SSD unter Umständen nicht mehr, obwohl noch Nutzdaten auf den NAND-Bausteinen vorhanden sein können.

Mit zunehmender Zahl der pro Zelle gespeicherten Bits – etwa bei TLC mit drei oder QLC mit vier Bit – liegen die auszuwertenden Spannungsbereiche enger beieinander. Dadurch steigen die Anforderungen an Fehlerkorrektur, Read-Retry-Verfahren und die korrekte Verarbeitung durch Controller und Firmware. Ohne die internen Mapping- und Verwaltungsinformationen lassen sich die ausgelesenen Rohdaten nicht unmittelbar wieder zu einer logischen Datenstruktur zusammensetzen.

SMART- beziehungsweise Health-Daten können Verschleißindikatoren anzeigen. Einen Firmware-Absturz kündigen sie in der Regel nicht an, weil es sich nicht um einen graduellen Verschleißprozess handelt, sondern um einen punktuellen Fehler im Controller oder in der Firmware.

Wann TRIM die Wiederherstellung erschwert

In Serverumgebungen können TRIM-, UNMAP- oder Deallocate-Befehle aktiv sein, sofern der gesamte Speicherpfad – Betriebssystem, Dateisystem, Controller, Treiber und SSD-Firmware – sie unterstützt und an die SSD weiterreicht. Für die Datenrettung sind sie insbesondere bei zuvor gelöschten Dateien oder freigegebenen Datenbankbereichen relevant: Wurden diese Blöcke als nicht mehr benötigt gemeldet, können ihre Inhalte durch die interne Speicherbereinigung bereits physisch entfernt worden sein. Aktive Daten, die seit dem letzten Backup neu geschrieben oder verändert wurden, sind davon nicht automatisch betroffen.

Ob TRIM aktiviert ist, sollte dokumentiert sein. Im Schadensfall beeinflusst diese Information die Einschätzung, welche Daten physisch noch auf dem Laufwerk vorhanden sein können.

Was ein SSD-Ausfall für den Geschäftsbetrieb bedeutet

Wenn eine Enterprise-SSD als alleiniger Datenbankdatenträger in einem Produktivserver ausfällt, steht je nach Systemarchitektur der gesamte Geschäftsbetrieb still. ERP, Produktionsplanung, Auftragsverwaltung, Rechnungsstellung – alles, was auf dieser Datenbank liegt, ist nicht mehr erreichbar.

Die Bezeichnung Enterprise-SSD beschreibt die vorgesehene Einsatzklasse und Belastbarkeit eines Laufwerks. Sie ersetzt jedoch weder redundante Datenträger noch eine überwachte und getestete Datensicherung. Eine einzelne SSD ohne unabhängige Wiederherstellungsmöglichkeit bleibt ein Single Point of Failure, unabhängig von ihrer Leistungsklasse.

Ein verbreitetes Risiko dabei: Sicherungsjobs, die nach einem Systemupdate nicht mehr korrekt starten und deren Fehlermeldungen im Ereignisprotokoll unbemerkt bleiben. Im Schadensfall stellt sich dann heraus, dass das letzte verwertbare Backup mehrere Wochen alt ist.

Wie DATA REVERSE® ausgefallene SSDs untersucht

Im Labor wird eine ausgefallene SSD zunächst darauf geprüft, ob sie sich über controller- und modellspezifische Diagnoseverfahren ansprechen lässt. Abhängig von der verbauten Controller-Familie können solche Zugänge ermöglichen, interne Metadaten auszulesen oder Teile der regulären Initialisierung zu umgehen. Auf diesem Weg lässt sich die Zuordnung zwischen logischen Blöcken und physischen NAND-Seiten rekonstruieren, sofern die Metadaten auf den NAND-Bausteinen noch intakt sind.

Führt dieser Weg nicht zum Ziel, bleibt als letztes Mittel das Auslöten der NAND-Flash-Chips und deren direkte Auslesung über spezialisierte Lesegeräte. Die ausgelesenen Rohdaten müssen anschließend abhängig von der Controller-Architektur fehlerkorrigiert, entscrambelt, zusammengeführt und anhand der internen Mapping-Strukturen rekonstruiert werden. Bei hardwareverschlüsselten SSDs hängt die Wiederherstellbarkeit zusätzlich davon ab, ob die benötigten Schlüssel und Metadaten noch zugänglich sind. Dieser Prozess setzt die Kenntnis der jeweiligen Controller-Architektur voraus und ist erheblich aufwendiger als bei Flash-Medien mit einfacherer Controllerlogik.

DATA REVERSE® ist nach ISO 9001 und ISO/IEC 27001 zertifiziert.

Was jetzt geprüft werden sollte

Backup-Jobs sollten täglich auf erfolgreichen Abschluss kontrolliert werden, idealerweise durch automatisierte Monitoring-Benachrichtigungen, die bei ausbleibender Bestätigung alarmieren.

SMART- beziehungsweise Health-Daten regelmäßig auswerten. Je nach Schnittstelle und Hersteller können Verschleißindikatoren, verfügbare Reserveblöcke, Medienfehler und die bereits genutzte Lebensdauer Hinweise auf den Zustand des Laufwerks geben. Sie ersetzen jedoch keine Redundanz und keinen getesteten Wiederherstellungsprozess.

Bei einem SSD-Ausfall den Server abschalten und weitere Einschaltversuche unterlassen. Die SSD sollte nicht initialisiert, formatiert, mit Firmware- oder Reparaturprogrammen bearbeitet oder wiederholt in anderen Systemen getestet werden. Modell, Seriennummer, Einbauposition und vorhandene Fehlermeldungen sollten für die Analyse dokumentiert werden.

In Arztpraxen, Zahnarztpraxen und therapeutischen Einrichtungen sind solche Ausfälle keine Seltenheit. Anders als in größeren Unternehmen mit eigener IT-Abteilung fehlen dort oft die Ressourcen für eine professionelle Überwachung der Speicherinfrastruktur. Das NAS, einmal eingerichtet, läuft häufig über Jahre ohne technische Kontrolle.

Praxissoftware, Befunde, Abrechnung: wenn das zentrale System ausfällt

Viele niedergelassene Praxen betreiben ihr Praxisverwaltungssystem weiterhin lokal oder serverbasiert. Je nach eingesetzter Lösung befinden sich die Daten auf einem Praxisserver, einem NAS, in einem Rechenzentrum oder in einer Cloudumgebung. Kritisch wird es vor allem dann, wenn ein lokales Speicher- oder Serversystem zum zentralen Zugriffspunkt geworden ist und keine unabhängig getestete Wiederherstellungsmöglichkeit existiert.

Bei lokal betriebenen Umgebungen können sich auf dem NAS beispielsweise gescannte Befunde, Bildbefunde, Dokumente oder Sicherungen der Praxissoftware befinden. Fällt das zentrale System aus, sind unter Umständen sämtliche Arbeitsbereiche der Praxis betroffen: vom Patientenempfang über die Behandlung bis zur Quartalsabrechnung.

Backup vorhanden, aber im Ernstfall wertlos

Ein wiederkehrendes Muster bei Datenverlusten in medizinischen Einrichtungen: Ein Backup existiert, hilft im konkreten Fall aber nicht weiter. Die Gründe dafür sind vielfältig.

Häufig sichert eine externe USB-Festplatte die Daten automatisch, steht aber direkt neben dem NAS. Bei einem Überspannungsschaden oder Wassereintritt sind dann beide Geräte betroffen. In anderen Fällen lief das Backup-Programm zwar im Hintergrund, hat aber seit Monaten keine vollständige Sicherung mehr abgeschlossen, weil Fehlermeldungen unbemerkt blieben. Oder die Sicherung enthält zwar Datenbankdateien, wurde jedoch nicht anwendungskonsistent erstellt oder erfasst nicht alle für die Wiederherstellung benötigten Komponenten. Dann lassen sich die gesicherten Daten nicht ohne Weiteres in das Praxisverwaltungssystem zurückspielen.

Hinzu kommt: In Praxen mit mehreren Arbeitsplätzen werden Backups selten unter realen Bedingungen getestet. Ob sich aus einer Sicherung ein funktionsfähiger Praxisbetrieb wiederherstellen lässt, zeigt sich oft erst im Schadensfall.

Medizinische Daten unterliegen besonderen Schutzpflichten

Patientendaten zählen nach der Datenschutz-Grundverordnung zu den besonderen Kategorien personenbezogener Daten. Für Praxisinhaber ergibt sich daraus eine erhöhte Verantwortung: Sie müssen angemessene technische Maßnahmen treffen, um die Verfügbarkeit und Integrität dieser Daten sicherzustellen.

Ein NAS-Ausfall kann auch die Verfügbarkeit personenbezogener Daten beeinträchtigen und damit eine Verletzung des Schutzes personenbezogener Daten darstellen. Ob eine Meldung an die Datenschutzaufsicht erforderlich ist, muss im Einzelfall anhand des Risikos für die Rechte und Freiheiten der betroffenen Personen bewertet werden. Wird der Vorfall als Datenschutzverletzung eingestuft, sind sowohl der Vorfall als auch die vorgenommene Risikobewertung zu dokumentieren. Zusätzlich können ärztliche Aufbewahrungs- und Dokumentationspflichten sowie datenschutzrechtliche Nachweispflichten betroffen sein.

Was im Schadensfall möglich ist

DATA REVERSE® analysiert beschädigte NAS-Systeme aus medizinischen Einrichtungen im eigenen Labor in Leipzig. Der Ablauf entspricht dem bei anderen Speichersystemen: Die einzelnen Datenträger werden zunächst diagnostiziert und nach Möglichkeit sektorweise ausgelesen. Die weitere Analyse und logische Rekonstruktion erfolgt auf Basis der erzeugten Abbilder, damit zusätzliche Schreibzugriffe auf die Originaldatenträger vermieden werden.

Bei NAS-Geräten mit RAID-Konfiguration wird geprüft, ob die logische Struktur des Verbunds noch rekonstruierbar ist. Bei mechanischen Schäden an Festplatten, etwa an den Schreib-Leseköpfen, kann eine Bearbeitung unter Reinraumbedingungen erforderlich sein. Elektronik- und Controllerfehler werden dagegen gesondert diagnostiziert und erfordern nicht automatisch das Öffnen des Datenträgers.

Besondere Aufmerksamkeit gilt den Datenbankdateien der Praxissoftware. Diese müssen nicht nur als Dateien wiederhergestellt, sondern in einem konsistenten Zustand extrahiert werden, damit das Praxisverwaltungssystem sie wieder einlesen kann. Das gelingt nicht in jedem Fall, hängt aber wesentlich davon ab, ob der Originaldatenträger unverändert geblieben ist.

DATA REVERSE® ist nach ISO 9001 und ISO 27001 zertifiziert und unterliegt strengen Vertraulichkeitsanforderungen. Gerade bei medizinischen Daten ist die lückenlose Dokumentation des Umgangs mit den Datenträgern ein fester Bestandteil des Prozesses.

Was Praxen jetzt prüfen sollten

Ein NAS-Ausfall trifft Praxen am härtesten, wenn er ohne Vorwarnung kommt und die Sicherung versagt. Drei Punkte, die sich kurzfristig prüfen lassen:

Erstens: Liegt die Backup-Festplatte am selben Standort wie das NAS? Falls ja, ist die Sicherung bei physischen Schadensereignissen mitgefährdet.

Zweitens: Wann wurde zuletzt geprüft, ob sich aus dem Backup ein funktionsfähiger Praxisbetrieb wiederherstellen lässt, also nicht nur einzelne Dateien, sondern die vollständige Datenbank der Praxissoftware?

Drittens: Überwacht jemand regelmäßig den Zustand des NAS, einschließlich RAID-Status, Festplattengesundheit und Speicherauslastung? Viele NAS-Geräte melden Probleme per E-Mail, aber nur, wenn diese Funktion eingerichtet und die hinterlegte Adresse noch aktiv ist.

Ransomware-Angriffe auf VMware-ESXi-Umgebungen treffen nicht zwangsläufig nur eine virtuelle Maschine. Gelingt Angreifern der Zugriff auf den Host oder die zentrale Verwaltungsumgebung, können sie mehrere virtuelle Server herunterfahren und die zugehörigen Dateien direkt auf dem Datastore verschlüsseln. Für betroffene Unternehmen entsteht dadurch innerhalb kurzer Zeit ein umfassender Systemausfall.

Der Hypervisor bündelt zentrale Systeme

Virtualisierung ermöglicht es Unternehmen, zahlreiche Server auf einer gemeinsamen physischen Infrastruktur zu betreiben. Jede virtuelle Maschine verfügt dabei über eigene Konfigurationsdateien und virtuelle Datenträger. Bei VMware werden die Daten dieser virtuellen Festplatten üblicherweise in VMDK-Strukturen gespeichert.

Für den laufenden Betrieb ist diese Bündelung effizient. Bei einem erfolgreichen Angriff kann sie jedoch dazu führen, dass mehrere geschäftskritische Systeme gleichzeitig betroffen sind. Werden VMDK-Dateien, Konfigurationen oder Teile des Datastores verschlüsselt, fehlen nicht nur einzelne Dokumente. Unter Umständen lassen sich ganze virtuelle Maschinen nicht mehr starten oder korrekt in die Virtualisierungsumgebung einbinden.

Der Schaden kann sich damit auf zahlreiche Unternehmensbereiche auswirken. Eine einzige kompromittierte Plattform kann gleichzeitig Verzeichnisdienste, Datenbanken, Kommunikationssysteme, Produktionsanwendungen oder virtuelle Arbeitsplätze außer Betrieb setzen.

Eine virtuelle Maschine besteht aus mehreren Abhängigkeiten

Eine virtuelle Maschine ist nicht nur eine einzelne Datei. Zu ihrem funktionsfähigen Zustand gehören die virtuelle Festplatte, die Konfiguration sowie gegebenenfalls Snapshot- und Delta-Dateien. Werden einzelne Bestandteile verschlüsselt, gelöscht oder beschädigt, kann die gesamte Maschine unbrauchbar erscheinen.

Besonders anspruchsvoll wird die Rekonstruktion bei vorhandenen Snapshot-Ketten. Ein Snapshot enthält nicht einfach eine vollständige unabhängige Kopie der virtuellen Maschine. Nach seiner Erstellung werden Änderungen in zusätzlichen Delta-Dateien gespeichert, während die ursprüngliche virtuelle Festplatte als Basis bestehen bleibt.

Damit die aktuellen Daten wieder vollständig zusammengesetzt werden können, müssen Basismedium und nachfolgende Änderungen korrekt zueinander passen. Fehlt ein Teil der Kette oder stimmen interne Zuordnungen nicht mehr überein, lässt sich die virtuelle Maschine nicht ohne Weiteres starten. Snapshots sind deshalb kein Ersatz für eine unabhängige Datensicherung.

Verschlüsselung trifft Dateien und Speicherstrukturen

Das konkrete Schadensbild unterscheidet sich von Angriff zu Angriff. Manche Ransomware-Varianten verschlüsseln große Dateien nicht vollständig, sondern verändern gezielt einzelne Bereiche. Dieses Vorgehen beschleunigt den Angriff, kann aber dennoch ausreichen, um virtuelle Datenträger unbrauchbar zu machen.

Bei VMDK-Dateien können bereits beschädigte Header, Metadaten oder zentrale Bereiche verhindern, dass die virtuelle Festplatte korrekt erkannt wird. Andere Angriffe betreffen zusätzlich Konfigurationsdateien, Snapshot-Strukturen oder Verwaltungsdaten des Datastores.

Auch der zugrunde liegende Speicher muss in die Analyse einbezogen werden. Virtuelle Maschinen können auf lokalen RAID-Systemen, SAN- oder NAS-Speichern, VMFS-Datastores oder verteilten Speicherlösungen liegen. Neben der Verschlüsselung können daher weitere Schäden auftreten, etwa ausgefallene Festplatten, inkonsistente RAID-Strukturen oder beschädigte Dateisysteme.

Datenrettung beginnt mit einer unveränderten Arbeitskopie

Nach einem Angriff ist entscheidend, den aktuellen Zustand der betroffenen Systeme zu erhalten. Unkoordinierte Neustarts, Reparaturversuche oder Schreibzugriffe auf dem Originalspeicher können noch vorhandene Strukturen verändern. Auch eine vorschnelle Neuinstallation des Hosts kann für die spätere Rekonstruktion wichtige Informationen überschreiben.

Für die technische Analyse werden betroffene Datenträger deshalb zunächst möglichst unverändert gesichert. Auf Grundlage dieser Arbeitskopien lässt sich prüfen, welche Bereiche verschlüsselt, beschädigt oder weiterhin lesbar sind.

Je nach Schadensbild können noch intakte Bestandteile virtueller Datenträger extrahiert und vorhandene Speicherstrukturen rekonstruiert werden. Bei teilweise verschlüsselten VMDK-Dateien wird unter anderem untersucht, welche Datenbereiche betroffen sind und ob sich nicht veränderte Inhalte noch sinnvoll zuordnen lassen.

Sind Snapshot-Ketten beschädigt, müssen die vorhandenen Basis- und Delta-Dateien analysiert und ihre Abhängigkeiten nachvollzogen werden. Ziel kann dabei sowohl die Rekonstruktion einer vollständigen virtuellen Maschine als auch die gezielte Wiederherstellung besonders wichtiger Dateien, Datenbanken oder Verzeichnisse sein.

Nicht jede virtuelle Maschine lässt sich vollständig wiederherstellen

Ob eine Datenrettung möglich ist, hängt vom Umfang der Verschlüsselung und vom Zustand des zugrunde liegenden Speichers ab. Wurden sämtliche relevanten Datenbereiche vollständig und mit einer sicheren Verschlüsselung verändert, kann auch ein Datenrettungslabor die ursprünglichen Inhalte nicht ohne passenden Entschlüsselungsschlüssel rekonstruieren.

Anders kann die Situation bei unvollständiger Verschlüsselung, beschädigten Verwaltungsstrukturen oder zusätzlichen Hardwarefehlern aussehen. Dann besteht die Aufgabe darin, noch vorhandene Datenbereiche zu sichern, ihre logischen Zusammenhänge wiederherzustellen und verwertbare Inhalte aus den virtuellen Datenträgern zu extrahieren.

Eine pauschale Aussage zur Wiederherstellbarkeit ist deshalb nicht möglich. Entscheidend sind die verwendete Ransomware, ihr Verschlüsselungsverfahren, die betroffenen Dateibereiche, vorhandene Snapshots und der technische Zustand des Speichersystems.

Erst analysieren, dann über das weitere Vorgehen entscheiden

Nach einem Ransomware-Angriff sollten Unternehmen das betroffene System vom Netzwerk trennen und die nächsten Schritte mit den zuständigen IT-Sicherheits-, Forensik- und Datenrettungsexperten abstimmen. Dabei müssen die Eindämmung des Angriffs, die Beweissicherung und die mögliche Wiederherstellung gemeinsam betrachtet werden.

Vorhandene Datenträger und virtuelle Strukturen sollten nicht verändert werden, solange unklar ist, welche Informationen für Analyse und Rekonstruktion noch benötigt werden. Auch verschlüsselte VMDK-Dateien, beschädigte Snapshots oder nicht mehr eingebundene Datastores können technisch relevante Bestandteile enthalten.

Gerade bei virtualisierten Infrastrukturen entscheidet daher nicht allein die Frage, ob ein Backup vorhanden ist. Ebenso wichtig ist, ob die virtuellen Datenträger, ihre Abhängigkeiten und die zugrunde liegenden Speicherstrukturen noch vollständig und konsistent vorliegen.

Beim Datenverlust im Gaming denken viele zuerst an verlorene Spielstände. Bei aktuellen Konsolen liegt die Sache anders. Bei Nintendo Switch und der Switch 2 liegen Spielstände im internen Konsolenspeicher, nicht auf der microSD-Karte. Auf der Karte befinden sich heruntergeladene Spiele, Updates, Screenshots und aufgezeichnete Videos. Bei Xbox synchronisiert Xbox Cloud die Spielstände über das Microsoft-Konto, während Erweiterungskarten vor allem installierte Titel und lokale Spieldaten enthalten.

Kritisch wird es bei Daten ohne Cloud-Anbindung. Selbst erstellte Mods, eigene Maps und Konfigurationen existieren oft nur ein einziges Mal. Dasselbe gilt für Gameplay-Aufnahmen, für Replay- und Analysedateien von eSports-Teams und für lokale PC-Spielstände, deren Cloud-Sicherung nie eingerichtet wurde. Fällt der Datenträger physisch aus, sind solche Inhalte ohne professionelle Rettung verloren.

Die technische Entwicklung verschärft die Lage. Mit microSD Express hat die Switch 2 einen Kartenstandard eingeführt, der über eine NVMe-Anbindung theoretisch bis zu rund 985 MB/s erreicht und klassische UHS-I-Karten damit deutlich überholt. Schnellere Karten und größere Spiele bedeuten zugleich, dass auf einem einzelnen Datenträger immer mehr wertvolle Inhalte zusammenkommen. Hinzu kommt die seit Anfang 2026 spürbare Verteuerung von Flash-Speicher infolge der weltweiten NAND-Knappheit, die manche Nutzer dazu bewegt, ihre Daten auf weniger Speichermedien zu bündeln.

Was im Schadensfall möglich ist, hängt von der Art des Defekts ab. Bei logischen Fehlern, etwa einem unterbrochenen Schreibvorgang oder einer beschädigten Dateizuordnung, lassen sich die Speicherbereiche häufig gezielt auslesen. Physische Schäden sind aufwendiger. Bei modernen Speicherkarten sitzen Controller und NAND-Flash in einem vergossenen Baustein, sodass der Zugriff über den Controller und, wo das NAND auslesbar ist, über eine seitenbasierte Rekonstruktion der Speicherinhalte läuft. Die schnellen microSD-Express-Karten der Switch 2 mit ihrer NVMe-Architektur sind dabei anspruchsvoller auszulesen als ältere UHS-I-Karten. Bei SSDs kommen je nach Defekt Controller-, Firmware- oder Zellenprobleme in Betracht. Eine pauschale Erfolgsgarantie gibt es nicht, entscheidend sind Schadensbild und Zustand der Speicherzellen.

Im Gaming-Umfeld fällt DATA REVERSE® ein wiederkehrendes Muster auf: Viele unterschätzen, welche Daten überhaupt lokal liegen. Spielstände wandern häufig in die Cloud, die eigenen Aufnahmen, Mods und Konfigurationen bleiben dagegen nur auf der einen Karte oder SSD. Ob sich ein defekter Datenträger im Labor auslesen lässt, entscheidet am Ende das Schadensbild.

Für Betroffene gilt: Bei ungewöhnlichen Geräuschen, nicht mehr erkannten Datenträgern oder plötzlichem Datenverlust sollte der Datenträger sofort vom Strom getrennt und nicht weiter beschrieben werden. Eigene Rettungsversuche mit Reparatur-Software können intakte Speicherbereiche zusätzlich gefährden. Wer keine funktionierende Sicherung hat, wendet sich am besten direkt an ein Datenrettungslabor.