72 Prozent prüfen ihre Sicherung selten oder nie

In einer eigenen Befragung von DATA REVERSE® unter 285 kleinen und mittleren Unternehmen im ersten Quartal 2025 gaben 77 Prozent an, mindestens wöchentlich zu sichern. 72 Prozent der Befragten prüfen jedoch selten oder nie, ob sich ihre Sicherungen tatsächlich wiederherstellen lassen. Im Ernstfall kann sich dann erstmals zeigen, ob das Backup tatsächlich funktioniert.

Ein erfolgreicher Sicherungslauf allein beweist noch nicht, dass eine Wiederherstellung gelingt. Die Meldung „erfolgreich" bestätigt in der Regel, dass die Software ihre Daten vollständig auf das Ziel geschrieben hat. Ob diese Daten Monate später noch lesbar sind, ist eine andere Frage. Viele Backup-Produkte bieten dafür eigene Prüfungen an, etwa das Zurücklesen mit Prüfsummenvergleich oder einen Testlauf der Wiederherstellung. Diese Funktionen kosten Zeit und Speicherplatz und sind deshalb häufig abgeschaltet oder wurden nie eingerichtet.

Warum ein Sicherungsziel leise ausfällt

Ein Backup-NAS führt ein anderes Leben als ein Produktivsystem. Es wird nachts beschrieben und tagsüber kaum angefasst, Monate vergehen, ohne dass jemand einen größeren Bestand daraus liest. Dieser Rhythmus verdeckt Fehler. Festplatten können im Betrieb einzelne Bereiche entwickeln, die sich nicht mehr fehlerfrei lesen lassen; Hersteller geben dafür je nach Laufwerksklasse unterschiedliche Fehlerraten an. Solange diese Bereiche nur geschrieben und nie gelesen werden, fällt das nicht auf. Ein umfangreicher Restore ist dann oft der erste vollständige Lesevorgang seit langer Zeit, und er macht die Schwachstellen sichtbar.

Dazu kommt der Verbund. Fällt in einem RAID 5 eine Platte aus, läuft das System weiter, allerdings ohne die Reserve, für die der Verbund gebaut wurde. Warnmeldungen dazu können per E-Mail versendet werden. Bleibt die Meldung unbeachtet, arbeitet das Backup-Ziel monatelang ohne Redundanz. Ein Restore belastet die verbliebenen Laufwerke über Stunden stärker als das nächtliche Schreiben. Ein bereits geschwächtes Laufwerk kann unter dieser Last ausfallen, und mit dem zweiten Ausfall ist der Verbund nicht mehr lesbar. Ähnliches ist vom Rebuild bekannt: Wird nach einem Plattentausch der Verbund neu aufgebaut, müssen die übrigen Platten in großem Umfang gelesen werden, bislang unbemerkte Lesefehler können den Vorgang stören oder abbrechen.

Sicherungsketten haben eine eigene Verwundbarkeit. Inkrementelle Sicherungen speichern nur die Änderungen seit dem letzten Lauf und setzen auf einer Vollsicherung auf. Ist ein Glied dieser Kette beschädigt, lassen sich je nach Verfahren die Stände danach nicht mehr vollständig zusammensetzen. Und ein Snapshot auf demselben Speichersystem ersetzt keine Sicherung, er liegt auf denselben Platten, die gerade ausfallen.

Warum der zweite Versuch warten sollte

Bricht eine Wiederherstellung wegen Lesefehlern ab, liegt es nahe, sie sofort neu zu starten. Jeder weitere Durchlauf liest jedoch dieselben schwachen Bereiche erneut und belastet Laufwerke, die bereits Fehler zeigen. Bei einer Festplatte mit beginnenden Defekten kann sich der Zustand mit jedem Leseversuch verschlechtern, bei einem RAID ohne Redundanz kann ein weiterer Ausfall den Verbund unlesbar machen. Deshalb gehört nach dem ersten Abbruch die Frage, was am Sicherungsziel vorliegt, vor den nächsten Versuch.

Was im Labor mit einem defekten Backup-Ziel geschieht

Im Labor wird das Sicherungsziel als Satz einzelner Datenträger behandelt. Jede Platte wird zunächst hardwareseitig ausgelesen und als 1:1-Kopie gesichert, defekte Laufwerke werden bei Bedarf zunächst für das Auslesen vorbereitet. Alle weiteren Schritte laufen auf diesen Kopien: Der RAID-Verbund wird daraus rekonstruiert, anschließend das Dateisystem des NAS und darin die Sicherungsdateien. Am Ende steht die Prüfung, welche Sicherungsstände vollständig und in sich schlüssig sind. Ist eine Kette unterbrochen, wird sie bis zum letzten intakten Glied zurückverfolgt. Für die Analyse hilft es, wenn der Original-Controller beziehungsweise das NAS-Gehäuse mit ins Labor kommt, weil sich die Konfiguration des Verbunds daraus schneller ableiten lässt. Für Unternehmen, deren Betrieb steht, bietet DATA REVERSE® einen Express-Service an.

Was vor dem nächsten Restore-Versuch geschehen sollte

– Nach dem ersten Abbruch keinen zweiten Versuch starten. Das Sicherungsziel herunterfahren, bei einem NAS über die Verwaltungsoberfläche oder den Ausschalter, nicht durch Ziehen des Netzsteckers.
– Die Datenträger beim Ausbau nach Schacht beschriften oder fotografieren und in keiner anderen Reihenfolge wieder einsetzen. Ein NAS mit vertauschten Platten neu zu starten, gehört zu den häufigen Ursachen für logische Folgeschäden.
– Keinen Rebuild anstoßen und keine Platte tauschen, solange unklar ist, welches Laufwerk in welchem Zustand ist.
– Die Konfiguration der Sicherungssoftware, das Jobprotokoll und den Aufbewahrungsplan sichern. Sie zeigen, welche Stände vorhanden sein müssten und wie die Kette aufgebaut ist.
– Die Rotation anhalten, damit die Sicherungssoftware nicht turnusmäßig die letzte intakte Vollsicherung überschreibt.
– Wenn auch das Produktivsystem beschädigt ist, dort keine Reparatur- oder Neuinstallationsversuche starten. Solange das Backup nicht gesichert ist, bleibt es die zweite Quelle, aus der sich der Bestand rekonstruieren lässt.

Für den Regelbetrieb rät DATA REVERSE® zu Wiederherstellungstests, die mindestens quartalsweise unter realen Bedingungen laufen: ein vollständiger Restore auf getrennte Hardware, mit Zeitmessung und einem Funktionstest der wiederhergestellten Anwendungen. Das Sicherungsziel gehört in dieselbe Überwachung wie die Produktivsysteme, mit Alarmen für RAID-Status und Laufwerksfehler, die ein besetztes Postfach erreichen. Mindestens eine Kopie sollte außerhalb des Gebäudes oder vom Netz getrennt liegen, damit der Ausfall eines Speichersystems Original und Sicherung nicht zugleich trifft. DATA REVERSE® ist nach ISO 9001 und ISO/IEC 27001 zertifiziert und stellt Daten von Servern, RAID-Verbünden, NAS-Systemen und virtuellen Umgebungen wieder her. Fälle, in denen ein Unternehmen erst im Notfall feststellt, dass seine Sicherung defekt oder unvollständig ist, gehören zur täglichen Praxis des Leipziger Labors.

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.

Redundante Systeme verschärfen das Phänomen paradoxerweise, denn sie laufen nach dem ersten Ausfall weiter, als wäre alles in Ordnung. Ein RAID im degradierten Zustand arbeitet ohne oder nur mit stark reduzierter Sicherheitsreserve, und fällt in dieser Phase ein weiteres Laufwerk aus, kann der gesamte Verbund stehen. Ähnliches gilt für Sicherungsjobs, die in der Ferienzeit still fehlschlagen: Der Fehler fällt erst auf, wenn die Sicherung gebraucht wird. Beides sind organisatorische Lücken, die sich als Technikschaden tarnen. Wie verbreitet sie sind, zeigte eine Befragung von DATA REVERSE® unter 245 Unternehmen auf der it-sa 2025: Die große Mehrheit übersieht kritische Risiken bei der eigenen Datenwiederherstellung.

Für die Urlaubsmonate heißt das konkret: Alarmierungsketten gehören vor der Ferienzeit getestet, mit einer Vertretung, die Meldungen versteht und Entscheidungen treffen darf. Ein degradiertes RAID ist ein Notfall mit Frist und wartet nicht bis zur Rückkehr des Kollegen. Vor jedem Rebuild steht zudem die Prüfung, ob eine aktuelle, funktionierende Sicherung existiert, denn der Wiederaufbau eines Verbunds ist der Moment mit dem höchsten Risiko für die verbliebenen Daten.

DATA REVERSE® rettet Daten von Festplatten, SSDs, RAID- und NAS-Systemen sowie mobilen Geräten. Das Unternehmen arbeitet nach ISO 9001 und ISO 27001, bietet eine bundesweit kostenfreie Abholung defekter Datenträger und gibt eine 95-Prozent-Datengarantie.

Für die Rettung setzen die Techniker deshalb am Controller und an der Firmware an, um den Zugang zu den Speicherbereichen wiederherzustellen, bei Bedarf über eine seitenbasierte Rekonstruktion der NAND-Inhalte. Zwei Eigenheiten unterscheiden diese Arbeit von der klassischen Festplattenrettung, und beide sollten IT-Verantwortliche kennen. Gelöschte Daten sind auf einer SSD schneller endgültig verloren, weil die TRIM-Funktion freigegebene Bereiche im Hintergrund tatsächlich leert, bei versehentlichen Löschungen zählt also jede Stunde, in der das Laufwerk noch läuft. Und in Unternehmensumgebungen ist der Datenträger heute in aller Regel verschlüsselt, unter Windows 11 meist per BitLocker. Ohne den zugehörigen Recovery-Key bleibt auch ein technisch perfekt gerettetes Abbild unlesbar.

Aus der Laborpraxis von DATA REVERSE® ergeben sich klare Empfehlungen. Recovery-Keys gehören zentral hinterlegt, etwa im Verzeichnisdienst des Unternehmens, und diese Ablage sollte regelmäßig geprüft werden, denn im Schadensfall ist es dafür zu spät. Ein nicht mehr erkanntes Laufwerk sollte weder durch wiederholte Neustarts noch durch Firmware-Updates auf Verdacht wiederbelebt werden, beides kann den Fehlerzustand verfestigen. Und weil eine SSD keine zweite Chance ankündigt, bleibt die verlässlichste Vorsorge eine Sicherung, die nicht auf demselben Gerät liegt.

Erste Schritte nach einem Datenverlust: https://www.datareverse-datenrettung.de/…

DATA REVERSE® rettet Daten von Festplatten, SSDs, RAID- und NAS-Systemen sowie mobilen Geräten. Das Unternehmen arbeitet nach ISO 9001 und ISO 27001, bietet eine bundesweit kostenfreie Abholung defekter Datenträger und gibt eine 95-Prozent-Datengarantie.