Wie man nachweist, dass ein Backup wiederherstellbar ist
Von Lucas Flores, IT Systeme Flores UG. Zuletzt aktualisiert am
Sie belegen, dass ein Backup wiederherstellbar ist, indem Sie daraus wiederherstellen: regelmäßig, nach einem Plan, den Sie einhalten, und indem Sie das Ergebnis mit dem vergleichen, was beim Backup aufgezeichnet wurde. In der Praxis sind das ein Restore-Test, das Zurücklesen einer Stichprobe der Daten, ein Hash-Vergleich mit den aufgezeichneten Prüfsummen, ein fester Rhythmus wie wöchentlich und dokumentierte Ergebnisse. Ein abgeschlossener Backup-Job sagt nur, dass Daten geschrieben wurden. Restow führt diese Prüfung jede Woche aus und zeigt das Ergebnis als Wiederherstellbarkeit.
Warum beweist ein erfolgreicher Backup-Job nichts?
Weil „abgeschlossen“ heißt, dass das Schreiben geklappt hat, nicht, dass sich die Daten wieder lesen lassen. Ein Schlüssel kann aus dem Takt mit dem geraten, was einen Chunk geschrieben hat, Speicher kann einen Block beschädigen, der monatelang nicht gelesen wird, und eine Formatänderung kann die Kompatibilität mit älteren Backups still brechen. Nichts davon zeigt sich im Status des Jobs. Es zeigt sich, wenn jemand einen Restore versucht, und das ist der schlechteste Zeitpunkt für diese Entdeckung.
Was gilt als Nachweis?
Fünf Bausteine, und der Nachweis ist nur so gut wie der schwächste:
| Baustein | Was Sie tun | Was es zeigt |
|---|---|---|
| Restore-Test | Echte Daten in ein getrenntes Ziel wiederherstellen, nie über die Produktion. | Der Restore-Pfad funktioniert durchgehend, einschließlich Schlüsseln und Berechtigungen. |
| Stichprobe zurücklesen | Elemente zufällig aus dem neuesten Backup ziehen und über denselben Weg zurücklesen, den ein echter Restore nimmt. | Das Backup ist lesbar und entschlüsselt sich, bei Daten, die Sie nicht vorher ausgesucht haben. |
| Hash-Vergleich | Eine Prüfsumme wie SHA-256 des Zurückgelesenen mit der vergleichen, die beim Backup aufgezeichnet wurde. | Was zurückkam, ist Byte für Byte das, was hineinging, nicht nur etwas, das sich öffnen lässt. |
| Ein regelmäßiger Rhythmus | Es nach festem Plan wiederholen, etwa jede Woche, und nach Änderungen am Aufbau. | Es funktioniert auch heute noch. Ein einzelner Test belegt nur den Tag, an dem er lief. |
| Dokumentierte Ergebnisse | Datum, Backup, Stichprobe, Methode und Ergebnis aufschreiben und aufbewahren. | Sie können es einem Kollegen, einem Kunden oder einem Prüfer zeigen und einen Verlauf sehen. |
Wie gelingt das ohne Spezialwerkzeug?
Jedes Backup-Produkt lässt sich mit einer kurzen Routine von Hand prüfen. Auf einem Linux-Server zum Beispiel: Prüfsummen einer zufälligen Stichprobe von Dateien vor dem Backup mit sha256sum festhalten (relative Pfade), diese Dateien in einen leeren Ordner wiederherstellen und dort sha256sum -c auf die Liste laufen lassen. Jede Zeile muss OK melden. Bei Mail eine Stichprobe von Nachrichten in ein Testpostfach wiederherstellen und mit den Originalen vergleichen, dazu ab und zu einen Restore des ganzen Postfachs in ein Testpostfach. Das Ergebnis aufschreiben. Nach Plan, nicht dann, wenn Sie daran denken.
Wie oft sollte man testen?
Das Zurücklesen einer Stichprobe mindestens wöchentlich, denn so schnell sollte ein stilles Problem auffallen, und eine vollständige Restore-Übung in ein Testziel jedes Quartal sowie nach jeder Änderung an Speicher, Schlüsseln oder Backup-Tool. Das ist unser Vorschlag, keine Regel aus einer Norm; Ihr eigenes Risiko und die Verträge Ihrer Kunden können mehr verlangen.
Wie macht Restow das?
Wenn Restow ein Backup anlegt, zeichnet es von jedem Element eine SHA-256-Prüfsumme auf. Jede Woche zieht für jedes Postfach, jedes OneDrive und jedes IMAP-Konto eine Restore-Prüfung zufällig 20 Mails, 20 Dateien und einige Kalendereinträge und Kontakte aus dem neuesten Backup, liest sie über den Restore-Pfad samt Entschlüsselung zurück und vergleicht das Zurückgelesene mit den aufgezeichneten Prüfsummen. Bei Servern und Clients stellt der Agent außerdem einige Dateien in einen temporären Ordner auf dem Rechner wieder her, vergleicht sie dort und löscht die Kopie. Das Ergebnis erscheint als Wiederherstellbarkeit: Bereit (grün) erst, nachdem eine Prüfung des neuesten Backups bestanden wurde, und „Nicht nachgewiesen“ für ein Backup, das existiert, aber noch nicht geprüft wurde, nie standardmäßig grün. Ein Bericht je Prüfung listet auf, was zurückgelesen wurde, und Alarme können eine Mail, einen Eintrag in der Glocke oder einen signierten Webhook senden, wenn eine Prüfung fehlschlägt.
Seit 0.4.0 gibt es zwei weitere Prüfungen. Eine Dateifreigabe wird nach jedem neuen Sicherungsstand geprüft: Bis zu 20 stichprobenartig gewählte Dateien werden zurückgelesen und verglichen, und das Repository bekommt wöchentlich einen restic check von 5 Prozent seiner Daten. SharePoint-Websites werden wie OneDrives geprüft, indem Dateien der Bibliotheken als Stichprobe gezogen werden. Für Proxmox VE (eine Preview) kann ein Job außerdem Startprüfungen ausführen, standardmäßig aus: Ein Sicherungsstand wird als neuer, vom Netzwerk getrennter Gast wiederhergestellt, gestartet, auf eine Antwort des QEMU-Gast-Agents geprüft und wieder gelöscht. Eine grüne Startprüfung heißt, dass der Gast geantwortet hat, nicht, dass jede Anwendung darin läuft; Windows-Gäste ohne Gast-Agent erreichen höchstens Gelb. Seit 0.4.2 wird außerdem jeder neue Sicherungsstand eines Proxmox-VE-Gasts binnen Minuten nach seiner Sicherung zurückgelesen: Eine Stichprobe seiner Blöcke wird mit der aufgezeichneten Prüfsumme verglichen.
Daneben liest eine Speicherprüfung Pakete erneut und vergleicht sie mit der aufgezeichneten Größe und Prüfsumme: jede Woche eine Stichprobe und jeden Monat jedes Paket. Seit 0.4.2 unterscheidet sie ein Paket, das sie im Moment nicht lesen konnte (ein Verbindungs- oder Berechtigungsfehler), von einem beschädigten: Ein solches Paket wird erneut gelesen und mit „Achtung“ bewertet statt mit „Nicht wiederherstellbar“, es sei denn, es bleibt in drei Prüfungen in Folge über mindestens 24 Stunden unlesbar. Und das Audit-Log zeichnet jedes Lesen und Wiederherstellen auf, die Chronik, wer was wiederhergestellt hat, ist also selbst ein Nachweis. Die Einzelheiten stehen unter wie Restow belegt, dass Ihre Sicherungen wiederherstellbar sind, in der Funktionsseite zur Verifizierung und in der Dokumentation.
Wo liegen die Grenzen einer Stichprobe?
Eine Stichprobe ist eine Stichprobe: 20 Mails von 50.000 belegen, dass der Restore-Pfad und diese Mails funktionieren, nicht jede einzelne Mail. Die monatliche Speicherprüfung, die jedes gespeicherte Paket liest, schließt viel von dieser Lücke. Die wöchentliche Prüfung stellt nicht in ein Live-Postfach in Microsoft 365 wieder her; ein vollständiger Test-Restore in ein separates Ziel ist geplant und nicht gebaut, stellen Sie also hin und wieder selbst ein Testpostfach wieder her. Und Microsoft-365-Backup und -Restore sind in den Release-Prüfungen von Restow noch nicht gegen einen echten Mandanten gelaufen; sie sind durch Tests gegen eine simulierte Graph-API abgedeckt. Deshalb sollte Restow, noch eine Beta, neben einem bestehenden Backup laufen, bis Sie Restores gegen Ihre eigenen Daten geprüft haben.
Häufig gefragt
Ist ein Restore-Test dasselbe wie die Prüfung der gespeicherten Daten?
Nein, sie beantworten verschiedene Fragen. Die Prüfung der gespeicherten Daten (Pakete lesen und Prüfsummen vergleichen) zeigt, dass der Speicher noch enthält, was geschrieben wurde. Ein Restore-Test geht denselben Weg wie ein echter Restore, mit Entschlüsselung und Zusammensetzen, und vergleicht das Ergebnis mit dem Original. Sie wollen beides: Das eine findet stille Schäden früh, das andere zeigt, dass die ganze Kette funktioniert.
Wie viele Elemente sollte ich als Stichprobe nehmen?
Eine magische Zahl gibt es nicht. Decken Sie jede Art von Daten ab, die Sie schützen (Mail, Kalender, Dateien, einen Datenbank-Dump), ziehen Sie die Elemente zufällig, damit Sie nicht immer dieselben einfachen testen, und wählen Sie die Stichprobe so groß, dass ein Fehler auffallen würde. Restow zieht je Postfach 20 Mails, 20 Dateien und einige Kalendereinträge und Kontakte, je Rechner bis zu 20 Dateien; eine manuelle Routine darf deutlich kleiner sein, wenn Sie sie wiederholen.
Muss ich zum Testen in die Produktion wiederherstellen?
Nein, und Sie sollten es nicht tun. Stellen Sie in ein getrenntes Ziel wieder her: einen leeren Ordner, ein Testpostfach, eine Test-VM. Ein Restore, der Produktivdaten überschreibt, ist ein Risiko, kein Test. Der Restore von Restow ist standardmäßig nicht destruktiv, und die wöchentliche Prüfung liest das Backup auf dem Server, ohne in ein Postfach oder über Dateien eines Rechners zu schreiben.
Was gehört in das dokumentierte Ergebnis?
Das Datum, welches Backup getestet wurde (Job und Wiederherstellungspunkt), was in der Stichprobe war und wie viele Elemente, die Methode, das Ergebnis je Element oder insgesamt, wer oder was es ausgeführt hat und was bei einem Fehler unternommen wurde. Eine Zeile je Lauf genügt, wenn es immer dieselbe Zeile ist und sie dort liegt, wo eine Prüferin oder ein Kollege sie findet.
Belegt Restow alles an einem Backup?
Nein. Die wöchentliche Prüfung belegt, dass eine zufällige Stichprobe über den Restore-Pfad unversehrt zurückgelesen wird; sie stellt nicht in ein Live-Postfach in Microsoft 365 wieder her, und ein vollständiger Test-Restore in ein separates Ziel ist geplant, nicht gebaut. Restow nennt auch, was seine Release-Prüfungen noch nicht abdecken, etwa Microsoft-365-Backup und -Restore gegen einen echten Mandanten.
Warum Restore-Tests wichtiger sind als Backups · EWS-Abschaltung: Was Backup-Tools jetzt brauchen
Mehr in Wissen: die 3-2-1-Backup-Regel und die „0“ in 3-2-1-1-0 →