Der Restore-Test: einmal aufgebaut, danach wiederholbar
Ein erfolgreicher Sicherungslauf beweist, dass Daten geschrieben wurden. Dass sie zurückkommen, beweist erst der Restore, und wie lange er dauert, weiß nur, wer ihn gestoppt hat.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der grüne Haken im Sicherungsjob beweist wenig
Ein erfolgreicher Sicherungslauf sagt aus, dass Daten gelesen und weggeschrieben wurden. Er sagt nichts darüber, ob sich daraus eine startfähige Datenbank bauen lässt, ob das Archivprotokoll für den gewünschten Zeitpunkt vollständig ist, ob der Schlüssel für die verschlüsselte Sicherung noch existiert und ob der Zielserver überhaupt genug Platz hat. Diese vier Fragen entscheiden im Ernstfall, und keine davon wird vom Sicherungsjob beantwortet.
Der zweite blinde Fleck ist die Dauer. In Notfallplänen steht regelmäßig eine Wiederanlaufzeit, die niemand gemessen hat. Sie enthält meist nur den eigentlichen Rückspielvorgang und nicht das Beschaffen der Sicherung aus dem kalten Speicher, das Bereitstellen eines Servers, das Nachfahren der Protokolle, den Neuaufbau von Indizes und den Start der Anwendungen. Zwischen der geschätzten und der gemessenen Zahl liegen in der Praxis oft Stunden.
Der dritte Punkt betrifft das Wissen. Ein Restore, den nur eine einzige Person durchführen kann, ist im Urlaub dieser Person nicht verfügbar. Ein Test, den jemand anderes anhand der Dokumentation durchführt, prüft deshalb zwei Dinge auf einmal: die Sicherung und die Anleitung.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Ablauf, den du einmal aufbaust und danach wiederholst
Die Reihenfolge ist in allen vier Systemen dieselbe, nur die Befehle unterscheiden sich. Wer sie einmal durchläuft und dabei mitschreibt, hat beim zweiten Mal eine Anleitung statt einer Erinnerung.
- 1
Den Ernstfall benennen
Leg fest, welcher Fall geprobt wird: eine versehentlich gelöschte Tabelle, ein beschädigter Datenbereich, der Verlust der ganzen Instanz oder ein verschlüsselnder Angriff, bei dem auch die letzten Sicherungen betroffen sein können. Zu jedem Fall gehören zwei Zahlen, die vorher mit dem Fachbereich vereinbart sind: die zulässige Ausfallzeit und der zulässige Datenverlust.
Geschafft, wenn: Auf dem Blatt steht ein konkreter Fall mit zwei vereinbarten Zielwerten, nicht der allgemeine Wunsch nach Sicherheit.
- 2
Ein getrenntes Zielsystem bereitstellen
Der Test läuft nie auf der Produktionsinstanz. Er braucht eine eigene Instanz, eigenen Speicher und eine Umgebung, aus der heraus keine produktiven Schnittstellen erreichbar sind. Prüf dabei gleich mit, ob dort dieselbe Hauptversion und dieselben Zeichensätze und Sortierregeln vorliegen, denn eine Sicherung lässt sich nicht auf eine ältere Version zurückspielen.
Geschafft, wenn: Die Kopie läuft auf eigener Instanz, und ihre Anwendungsschnittstellen zeigen ins Leere statt auf produktive Empfänger.
- 3
Die Sicherung tatsächlich zurückspielen
Beim SQL Server ist das RESTORE DATABASE mit MOVE für die Dateipfade, gefolgt von den Protokollsicherungen mit NORECOVERY und einem abschließenden STOPAT. Wichtig: RESTORE VERIFYONLY prüft nur, ob die Sicherungsmenge lesbar und vollständig ist, es ist ausdrücklich kein Restore-Test. Oracle stellt mit RMAN eine Kopie über DUPLICATE DATABASE UNTIL TIME bereit, PostgreSQL kombiniert die Basissicherung mit dem Archiv der Schreibprotokolle und einem recovery_target_time, MySQL entweder den vorbereiteten physischen Abzug oder den logischen Auszug plus die Binärprotokolle ab der aufgezeichneten Position.
Geschafft, wenn: Die Instanz startet, lässt Anmeldungen zu, und im Protokoll steht kein Fehler aus der Wiederherstellungsphase.
- 4
Zeitpunkt und Vollständigkeit fachlich prüfen
Jetzt kommt der Teil, den kein Werkzeug übernimmt. Vergleich einen fachlichen Wert aus der Kopie mit dem, was zum Zielzeitpunkt gegolten hat: die höchste Belegnummer, die Zeilenzahl der größten Bewegungstabelle, den jüngsten Zeitstempel. Ergänz eine technische Konsistenzprüfung, im SQL Server DBCC CHECKDB, in Oracle die Prüfung des Sicherungssatzes mit VALIDATE CHECK LOGICAL, in PostgreSQL pg_amcheck für Tabellen und Indizes.
Geschafft, wenn: Ein fachlicher Wert aus der Kopie stimmt mit dem erwarteten Stand überein, und die Konsistenzprüfung meldet keine Beschädigung.
- 5
Die Dauer der ganzen Kette messen
Stopp nicht nur den Rückspielvorgang. Zur Ausfallzeit gehören das Beschaffen der Sicherung aus dem kalten oder ausgelagerten Speicher, das Bereitstellen des Servers, das Nachfahren der Protokolle, gegebenenfalls der Neuaufbau von Indizes und der Start der Anwendungen samt Prüfung. Notier die Teilzeiten einzeln, denn nur so siehst du beim nächsten Mal, welcher Abschnitt sich lohnt zu verkürzen.
Geschafft, wenn: Im Notfallplan steht eine gemessene Zeit mit Teilschritten statt einer Schätzung aus dem Handbuch.
- 6
Das Ergebnis protokollieren
Ins Protokoll gehören Datum, geprobter Fall, verwendete Sicherung, erreichter Zeitpunkt, Gesamtdauer mit Teilzeiten, die geprüften fachlichen Werte, die durchführende Person und vor allem die Abweichungen. Genau die Abweichungen sind der Ertrag des Tests: der fehlende Schlüssel für die verschlüsselte Sicherung, die nicht vorhandenen Anmeldungen auf dem Zielserver, der zu knappe Plattenplatz, die Anleitung, die an Schritt sieben aufhört.
Geschafft, wenn: Es gibt ein Dokument, aus dem eine andere Person den Ablauf beim nächsten Mal wiederholen kann.
- 7
Rhythmus festlegen und automatisieren
Ein Test gehört nach jeder größeren Änderung an Schema, Version, Speicher oder Sicherungsverfahren durchgeführt, dazu in einem festen Abstand unabhängig davon. Den technischen Teil kannst du automatisieren: Ein Job spielt die Sicherung der letzten Nacht in eine Testinstanz zurück, prüft die Konsistenz und meldet sich, wenn etwas schiefgeht. Der geübte Ernstfall mit Stoppuhr und Dokumentation bleibt daneben bestehen, aber seltener.
Geschafft, wenn: Der technische Test läuft, ohne dass jemand daran denken muss, und der geübte Ernstfall hat einen Termin im Kalender.
Sechs Angaben, die ein Restore-Protokoll tragen
- 01 Welcher Fall wurde geprobt, und welche Zielzeit war vereinbart?
- 02 Aus welcher Sicherung und bis zu welchem Zeitpunkt wurde zurückgespielt?
- 03 Wie lange dauerte die Kette von der Entscheidung bis zum nutzbaren System?
- 04 Welcher fachliche Wert wurde geprüft, und stimmte er mit dem Ziel überein?
- 05 Was hat gefehlt: Schlüssel, Platz, Rechte, Anleitung oder Zeit?
- 06 Wer hat den Test durchgeführt, und wann steht der nächste an?
Was du nach dieser Seite belastbar sagen kannst
Am Ende steht kein Gefühl, sondern ein Protokoll: welcher Fall geprobt wurde, aus welcher Sicherung, bis zu welchem Zeitpunkt, wie lange es gedauert hat und was dabei gefehlt hat. Diese Angaben lassen sich gegen die vereinbarten Zielwerte halten und beim nächsten Mal vergleichen.
Die zwei Zielwerte trennen
Die zulässige Ausfallzeit und der zulässige Datenverlust sind zwei verschiedene Vereinbarungen. Der Test misst die eine und weist die andere über den erreichten Zeitpunkt nach.
Auf ein getrenntes System zurückspielen
Die Kopie läuft auf eigener Instanz mit eigenem Speicher und ohne Verbindung zu produktiven Schnittstellen. Sonst schickt die wiederhergestellte Anwendung Rechnungen ein zweites Mal heraus.
Fachlich prüfen statt technisch
Dass die Instanz startet, ist die halbe Antwort. Die andere Hälfte ist ein fachlicher Wert: die letzte Belegnummer, die Zeilenzahl der größten Tabelle, der jüngste Zeitstempel.
Die ganze Kette stoppen
Gemessen wird von der Entscheidung bis zum nutzbaren System, einschließlich Bereitstellung, Rückspielen, Nachfahren der Protokolle und Anwendungsstart.
Den Einzelfall getrennt üben
Eine versehentlich gelöschte Tabelle verlangt eine andere Technik als der Totalverlust. Wer nur den großen Fall probt, steht beim kleinen ohne Verfahren da.
Den Test automatisieren
Ein Job, der die Sicherung der Nacht in eine Testinstanz zurückspielt und anschließend die Konsistenz prüft, findet Probleme, bevor sie jemand braucht.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Warum die Prüffunktionen der Hersteller keinen Test ersetzen
Alle vier Systeme bieten Prüfungen an, die schnell laufen und beruhigend aussehen. Microsoft schreibt zu RESTORE VERIFYONLY ausdrücklich, dass damit geprüft wird, ob die Sicherungsmenge vollständig und lesbar ist, wobei die Prüfsummen ausgewertet werden, sofern die Sicherung mit CHECKSUM erstellt wurde. Über die Struktur der enthaltenen Daten sagt die Prüfung nichts. RMAN RESTORE VALIDATE liest die Sicherungsstücke und prüft sie auf Beschädigungen, stellt aber nichts her. pg_verifybackup vergleicht die Basissicherung gegen ihr Manifest, also gegen die eigene Inhaltsliste.
Diese Prüfungen sind sinnvoll und gehören in den Betrieb, weil sie Beschädigungen früh finden. Sie beantworten nur eine andere Frage als der Restore-Test. Sie sagen: Die Sicherung ist lesbar. Der Test sagt: Aus dieser Sicherung entsteht in so und so vielen Stunden ein System, mit dem der Fachbereich arbeiten kann.
Ein Punkt, der in fast jedem ersten Test auffällt, ist die Verschlüsselung. Eine mit TDE geschützte Datenbank im SQL Server lässt sich auf einer fremden Instanz nur zurückspielen, wenn das Zertifikat und der zugehörige private Schlüssel dort vorhanden sind, und die liegen häufig nur auf dem Quellserver, also genau auf dem System, das im Ernstfall fehlt. Dasselbe gilt für Schlüssel aus dem Wallet bei Oracle. Die Sicherung des Schlüssels gehört deshalb getrennt von der Datensicherung verwahrt und ebenfalls in den Test.
Der gelöschte Datensatz ist ein anderer Fall als der Totalverlust
Beim Totalverlust ist der Weg klar: vollständige Sicherung, dann die Protokolle bis zum gewünschten Zeitpunkt. Beim versehentlich gelöschten Datenbestand fällt auf, dass die meisten Systeme keine Teilwiederherstellung einzelner Tabellen anbieten. Im SQL Server gibt es keinen Befehl, der eine einzelne Tabelle zurückholt, du stellst die Datenbank unter anderem Namen wieder her und kopierst die Zeilen zurück. In PostgreSQL gilt dasselbe, sofern nicht zufällig ein logischer Auszug der betroffenen Tabelle vorliegt.
Oracle ist an dieser Stelle besser ausgestattet. Der Papierkorb und Flashback Table holen eine gelöschte Tabelle zurück, solange der Platz nicht überschrieben wurde, und RMAN kann seit Version 12 einzelne Tabellen aus einer Sicherung zurückholen, indem es im Hintergrund eine Hilfsinstanz aufbaut. MySQL liegt dazwischen: Aus einem logischen Auszug lässt sich eine einzelne Tabelle herausziehen, aus einem physischen Abzug nur mit dem Umweg über transportierbare Tabellenbereiche.
Für den Test heißt das: Beide Fälle brauchen ein eigenes Verfahren und eine eigene Zeitmessung. Der kleine Fall tritt viel häufiger ein als der große, und er ist derjenige, bei dem eine halbe Stunde Verzögerung schon spürbar ist, weil der Fachbereich in dieser Zeit weiterarbeitet und neue Daten schreibt, die beim Zurückspielen nicht verloren gehen dürfen.
Wie oft, und wer den Test durchführen sollte
Ein fester Rhythmus ist weniger wichtig als die Kopplung an Änderungen. Nach einem Versionswechsel, einem Umzug des Speichers, einer Änderung am Sicherungsverfahren oder einer größeren Schemaänderung ist die alte Messung wertlos. Dazu kommt ein Abstand, der zum Risiko passt, und zwar unabhängig davon, ob sich etwas geändert hat. Das IT-Grundschutz-Kompendium des BSI führt für dieses Thema den eigenen Baustein CON.3 Datensicherungskonzept, und dort gehört die Erprobung der Wiederherstellung zu den Anforderungen an ein tragfähiges Konzept.
Wer den Test durchführt, ist eine Entscheidung mit Wirkung. Führt ihn die Person durch, die das Sicherungsverfahren gebaut hat, prüft er die Technik. Führt ihn jemand anderes anhand der Dokumentation durch, prüft er zusätzlich die Anleitung, und genau dort liegen die meisten Lücken. Ein guter Kompromiss ist der Wechsel: einmal die vertraute Person mit Stoppuhr, beim nächsten Mal eine Kollegin oder ein Kollege nur mit dem geschriebenen Ablauf.
Zwei Randbedingungen fallen erst im Test auf. Erstens muss die Sicherung erreichbar sein, wenn die Umgebung ausgefallen ist, was gegen einen Ablageort spricht, der seine Anmeldung aus demselben Verzeichnisdienst bezieht. Zweitens muss mindestens eine Fassung so abgelegt sein, dass sie sich nicht überschreiben oder löschen lässt, sonst nützt sie bei einem verschlüsselnden Angriff nichts. Beides gehört in den geprobten Fall und nicht in eine Fußnote.
Was das Protokoll enthalten muss, damit die Zahl trägt
Die Gesamtdauer allein ist wenig wert, weil sie sich beim nächsten Mal nicht erklären lässt. Nützlich wird sie durch die Teilzeiten: Beschaffung der Sicherung, Bereitstellung des Systems, Rückspielen, Nachfahren der Protokolle, Prüfung, Anwendungsstart. Steckt die Hälfte der Zeit in der Beschaffung aus dem ausgelagerten Speicher, hilft ein schnellerer Server gar nichts, dann ist die Aufbewahrung der letzten Tage auf schnellem Speicher die wirksame Maßnahme.
Ins Protokoll gehört außerdem, was gefehlt hat, auch wenn der Test am Ende erfolgreich war. Genau diese Liste ist der eigentliche Ertrag: die Anmeldungen, die auf dem Zielserver nicht existierten, die Verbindungszeichenfolge, die noch auf die alte Instanz zeigte, der Plattenplatz, der für die temporären Dateien nicht reichte, die Anleitung, die den Schritt mit dem Zertifikat nicht erwähnt.
Zum Schluss ein Vergleich mit der Vereinbarung. Wenn die zulässige Ausfallzeit vier Stunden beträgt und der Test sieben ergibt, ist das kein Grund, den Test schlechtzureden, sondern das erste belastbare Argument für ein anderes Verfahren, sei es eine bereitstehende Zweitinstanz, häufigere Protokollsicherungen oder ein anderer Ablageort. Ohne die gemessene Zahl bleibt diese Diskussion ein Austausch von Meinungen.
Dazu passende Kurse
Wer den Ablauf einmal unter Anleitung durchgespielt hat, braucht im Ernstfall keine Anleitung mehr, und dafür gibt es bei cmt Schulungen zu Sicherung und Wiederherstellung .
Für Umgebungen mit Recovery-Katalog und mehreren Instanzen lohnt der Blick auf die Oracle-Kurse rund um RMAN und den Wiederanlauf .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Super Schulung, in der der Trainer auch auf eigene Fragestellungen eingegangen ist.
Super Grundlagenschulung mit allen wichtigen Punkten und hilfreichen Tipps!
Schön, sich 5 Tage ungestört mit Postgres beschäftigen zu können.
Häufige Fragen
Reicht es, die Wiederherstellung einmal im Jahr zu prüfen?
Können wir statt eines Tests einfach die Replik verwenden?
Wie testen wir, ohne ein zweites Produktivsystem zu bezahlen?
Was ist mit den Berechtigungen nach dem Zurückspielen?
Passt thematisch dazu
Wenn beim Test auffällt, dass die Sicherung vom gesicherten System aus beschreibbar ist, liegt das Problem nicht im Ablauf, sondern im Aufbau, und wie der aussehen sollte, beschreiben die 3-2-1-Regel und unveränderliche Sicherungsziele .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Datenbanken-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Der Ernstfall ist der falsche Zeitpunkt für den ersten Versuch
Rückspielen, Zeitpunkt treffen, Dauer messen und dokumentieren lässt sich an einer Testinstanz üben, und bei cmt gehört genau das zum Programm.