Komme ich im Ernstfall wieder an meine Daten?

Nachts meldete die Datensicherung zuverlässig Erfolg. Als ich am 25. Juli 2026 testweise meine Daten wiederherstellte, entdeckte ich trotzdem vier Fehler. Die letzte Probe lag lange zurück; ich hatte mich von der grünen Meldung beruhigen lassen. Heute prüfe ich auf drei Ebenen, ob ich an meine Daten komme und die Anwendung damit arbeiten kann.

Was mit in die Sicherung muss

Eine Datenbank verändert ihre Daten, während die Anwendung läuft. Kopiere ich dabei einfach ihre Dateien, können Teile aus unterschiedlichen Zeitpunkten zusammenkommen. Die passen beim Wiederherstellen womöglich nicht mehr zueinander. Deshalb lasse ich die Datenbank selbst eine Datei erzeugen, in der die Daten zusammenpassen und nehme diesen in die Sicherung auf. Beim Wiederherstellen muss ich ihn wieder in die Datenbank einlesen. Entpackte Dateien allein machen die Daten noch nicht für die Anwendung nutzbar.

Außerdem sichere ich die Anwendungsdateien, die Konfiguration und die Passwörter der Programme. Die Einstellungen legen fest, wo eine Anwendung ihre Daten sucht. Das Passwort hilft ihr aber nur, wenn die Datenbank auch das zugehörige Konto kennt. Diese vermeintlichen Beigaben brauche ich also genauso wie die Daten selbst.

Ich verschlüssele die gesamte Sicherung. Eine Kopie bleibt zu Hause, eine weitere liegt außerhalb des Hauses an einem anderen Ort. Dort werden Dateien nicht allein deshalb gelöscht, weil sie an der Quelle verschwunden sind. Wenn ich zu Hause versehentlich etwas lösche, soll der nächste Kopierlauf meinen Fehler nicht gleich weiterreichen. Das verhindert, dass eine Löschung übernommen wird; die auswärtige Kopie selbst wird dadurch nicht unlöschbar.

Wenn die nächste Kopie ausbleibt

Ein Sicherungsauftrag, der gar nicht erst startet, verschickt auch keinen Fehlerbericht. Deshalb prüfe ich das Alter der letzten erfolgreichen Kopie. Wird sie zu alt, löst die verstrichene Zeit einen Alarm aus. Ich bin damit nicht auf eine Meldung des ausgefallenen Auftrags angewiesen. Keine Meldung heißt dann nicht mehr automatisch: alles in Ordnung. Auch eine auffällige Dateigröße löst einen Alarm aus: Die Sicherung könnte weniger Daten enthalten als erwartet. So weiß ich, wann ich den Sicherungslauf oder die entstandene Datei genauer prüfen muss. Ob ich daraus meine Daten zurückbekomme, klärt erst die Wiederherstellungsprobe.

Was meine drei Prüfungen abdecken

Ich prüfe zunächst die Sicherungsdatei selbst. Bei der vollständigen Probe stelle ich die Daten wieder her und starte die Anwendung. Zwischen diesen Proben wird jede Woche automatisch ein Teil der aktuellen Kopie zurückgespielt. Die Prüfungen ergänzen sich, weil sie unterschiedliche Lücken finden.

Lässt sich das Archiv lesen?

Bei der Integritätsprüfung kontrolliere ich, ob sich die Sicherungsdatei fehlerfrei lesen lässt. So kann ich ein beschädigtes Archiv erkennen, bevor ich es nach einem Ausfall brauche. Dass eine Datei vorhanden ist, hilft mir wenig, wenn ich ihren Inhalt nicht herausbekomme.

Auch in einem technisch einwandfreien Archiv kann etwas Wichtiges fehlen. Habe ich eine Passwortdatei gar nicht erst gesichert, fällt das bei dieser Prüfung nicht auf. Sie prüft nur die Dateien, die im Archiv enthalten sind. Ob der Anwendung etwas zum Arbeiten fehlt, muss ich durch Wiederherstellen und Starten herausfinden.

Erst fertig, wenn die Anwendung antwortet

Für die vollständige Probe nutze ich einen vorbereiteten Rechner. Ich lade die Sicherung herunter, stelle ihren Inhalt wieder her und prüfe die Antwort der Anwendung. Am 25. Juli 2026 zeigte sich, wo dieser Ablauf scheitern konnte:

• Die Datenbankkonten fehlten. Die Daten waren wieder da, doch die Anwendung konnte sich nicht anmelden. Der Sicherungsbericht bestätigte den Export der Daten, ohne zu prüfen, ob auch die nötigen Konten gesichert waren.
• Das Wiederherstellungsskript ließ die Datenbanken aus. Es entpackte Dateien, las die Datenbankexporte aber nicht ein. Beim Sichern war kein Fehler aufgetreten; der fehlende Schritt steckte im Werkzeug zum Wiederherstellen.
• Eine Ausschlussregel erfasste auch Passwortdateien. Sie passte auf mehr Dateien als beabsichtigt und ließ dadurch benötigte Zugangsdaten weg. Das Sicherungsprogramm hielt sich an seine Vorgaben und hatte aus seiner Sicht nichts zu melden.
• Die Daten kamen unter dem falschen Namen zurück. Die Anwendung hätte neben den wiederhergestellten Daten einen leeren Speicher angelegt – als wäre sie gerade auf einer leeren Festplatte eingezogen. Die Dateien waren da, nur suchte das Programm unter einem anderen Namen; diese Übereinstimmung prüfte der Sicherungsbericht nicht.

Ich behob die Fehler und wiederholte die Probe am 22. August 2026, nachdem ich das Sicherungsskript umgebaut hatte. Dabei wollte ich wissen, ob alle vier Korrekturen auch mit den neu erstellten Sicherungen funktionierten. Das taten sie. Außerdem erweiterte ich die Probe von 3 auf 7 Datenbanken und startete die Anwendung.

Ich beende die Probe erst mit einer korrekten Antwort der Anwendung. Beim Start müssen Daten, Konten, Passwörter und Einstellungen zusammenpassen. Würde ich nach dem Einlesen der Datenbank aufhören, könnte mir etwa der fehlende Zugang der Anwendung entgehen. Die folgende Messung reicht bis zu ihrer ersten korrekten Antwort; sämtliche Funktionen habe ich dabei nicht geprüft.

Schritt der Probe vom 22. August 2026	Dauer
Sicherung herunterladen — 1,26 GB	117 s
Entpacken und entschlüsseln	ca. 21 s
Datenbank starten, Konten und 4 Datenbanken wiederherstellen	ca. 27 s
Die übrigen 3 Anwendungen samt Datenbanken wiederherstellen	ca. 44 s
Anwendung starten, bis sie erstmals korrekt antwortet	ca. 12 s
Insgesamt	ca. 220 s, also ca. 3,7 min

Mehr als die Hälfte der Zeit entfiel auf das Herunterladen. Deshalb starte ich die Uhr schon dort. Wenn du erst beim Entpacken misst, sieht das Ergebnis besser aus, aber die längste Wartezeit fehlt. Nach einem Ausfall müsste ich die Kopie schließlich auch erst beschaffen. Die Messung gilt für einen vorbereiteten Rechner; eine Installation des Betriebssystems ist darin nicht enthalten.

Bei der Augustprobe fiel außerdem ein Fehler im Wiederherstellungswerkzeug selbst auf. Hätte ich das Skript versehentlich auf meinem täglich genutzten Rechner gestartet, hätte es die aktuelle Konfiguration mit der alten aus der Sicherung überschrieben. Mein Rettungswerkzeug hätte damit gleich den nächsten Rettungseinsatz verursacht. Ich habe es so geändert, dass es vor dem Überschreiben selbst prüft, wo es läuft. Damit hängt der Schutz nicht mehr allein daran, dass ich mich im richtigen Moment an den richtigen Rechner erinnere. Bei einem Ausfall habe ich schon genug im Kopf.

Jede Woche kommt die nächste Datenbank dran

Zwischen den vollständigen Proben lasse ich jede Woche die nächste von fünf Datenbanken aus der neuesten Sicherung wiederherstellen. Das geschieht getrennt von der täglich genutzten Datenbank. Jede ist alle fünf Wochen an der Reihe. Die Reihenfolge ist fest: Bei einer zufälligen Auswahl könnte eine Datenbank wochenlang ungeprüft bleiben, ohne dass ich ihren nächsten Prüftermin kenne. So weiß ich im Voraus, wann jede drankommt.

Dabei läuft das Skript aus der Sicherung selbst. Eine inzwischen korrigierte Fassung auf meinem Rechner könnte problemlos funktionieren, während die gesicherte Fassung noch einen Fehler enthält. Im Ernstfall hätte ich genau diese ältere Fassung zur Hand. Deshalb tausche ich sie für die Probe nicht gegen eine neuere aus. Die Sicherung muss ihre Daten mit dem mitgelieferten Werkzeug wieder hergeben. So prüfe ich auch dieses Werkzeug und nicht bloß, ob ich die Daten irgendwie von Hand herausbekomme.

Die nur für den Test gestartete Datenbank verwendet dasselbe Software-Image wie die täglich genutzte Datenbank, also dieselbe vorbereitete Software mit derselben Version und denselben Erweiterungen. Eine der Datenbanken ließe sich ohne ihre Erweiterung überhaupt nicht wiederherstellen. Ich will vermeiden, dass eine fehlende Erweiterung im Test wie ein Defekt der Sicherung aussieht.

Eine gestartete Datenbank allein überzeugt mich noch nicht: Eine leere startet genauso bereitwillig. Deshalb habe ich für jede eine Mindestanzahl an Tabellen und eine zusätzliche Prüfung des Inhalts festgelegt. Je nach Datenbank zählt der Test Dokumente, gespeicherte Automatisierungsabläufe oder Einträge zu Fotos und Videos. So prüft er, ob auch die Inhalte zurückgekommen sind, die das Programm braucht.

Am 19. September 2026 testete ich nach Einführung der festen Reihenfolge alle fünf Datenbanken mit dem automatischen Verfahren. Dafür verwendete ich die Sicherung aus derselben Nacht. Alle fünf ließen sich wiederherstellen; die Tests dauerten 14 bis 47 Sekunden pro Datenbank. Auch die Fehlererkennung habe ich geprüft: Mit einer absichtlich zu hohen Mindestanzahl fiel der Test durch. Die Anwendung wird bei diesen Tests weiterhin nicht gestartet. Ihre Dauer vergleiche ich deshalb nicht mit der vollständigen Probe.

Nach jedem Test werden die entschlüsselten Passwörter vernichtet, damit sie nicht auf der Festplatte zurückbleiben. Bei meinen manuellen Tests an diesem Tag schlug das Sicherheitsprogramm wegen einer Massenlöschung Alarm. Mein eigener Schutz hielt mich für einen Angreifer. Die automatischen Durchläufe lässt er unbehelligt.

Damit erfahre ich regelmäßig, ob sich die Daten aus einer aktuellen Sicherung noch zurückholen lassen. Die vollständige Probe wiederhole ich nach jeder Änderung am Sicherungsskript, nach jeder neu hinzugefügten Datenbank und spätestens nach einem halben Jahr. Eine frühere Probe konnte spätere Änderungen schließlich nicht prüfen. Der wöchentliche Test hält die Daten im Blick; die vollständige Probe prüft zusätzlich, ob die Anwendung damit arbeiten kann.

Eine Wiederherstellung auf neuer Hardware einschließlich der Betriebssysteminstallation habe ich zusammen mit der Erweiterung um weitere Rechner geplant. Nach dieser Probe ergänze ich hier das Ergebnis.