MariaDB-Wiederherstellungstests für einen Heimserver - Backups prüfen, bevor sie gebraucht werden
Ein geplanter Job endet ohne Fehler, ein neues Archiv erscheint auf einem anderen Datenträger und seine Prüfsumme stimmt. Ist die Datenbank damit wiederherstellbar? Das sind nützliche Signale, doch sie beantworten nur eine engere Frage: Es gibt lesbares Backup-Material. Sie zeigen nicht, ob MariaDB die erwarteten Objekte rekonstruieren kann, ob die Anwendung den wiederhergestellten Zustand versteht oder ob fehlende Systembestandteile identifiziert wurden.
Ein Wiederherstellungstest schließt einen Teil dieser Lücke. Er ist eine geplante Recovery-Übung außerhalb der Produktion, mit einem festgelegten Wiederherstellungspunkt und ausdrücklichen Akzeptanzprüfungen. Das Ziel ist nicht, Gewissheit zu erzeugen. Eine ungeprüfte Annahme soll durch Belege ersetzt werden, während verbleibende Unsicherheiten dokumentiert werden.
Zuerst definieren, was „wiederhergestellt“ bedeutet
Ein erfolgreicher Importbefehl ist keine vollständige Definition von Recovery. Bei einer kleinen Publishing-Anwendung könnte „wiederhergestellt“ bedeuten, dass der Datenbankserver startet, das erwartete Schema vorhanden ist, repräsentative Datensätze und Beziehungen erhalten sind, Texte weiterhin korrekt kodiert sind und eine isolierte Anwendungskopie die Daten lesen kann. Ein anderer Dienst könnte zusätzlich geplante Events, gespeicherte Routinen, Verschlüsselungsschlüssel, hochgeladene Dateien oder ein bestimmtes Datenbankkonto benötigen.
Die Akzeptanzkriterien sollten vor der Übung feststehen. Andernfalls endet die Prüfung leicht beim ersten grünen Signal. Ein einfacher Testplan kann festhalten:
- welcher Backup-Snapshot oder Dump verwendet wird;
- welcher isolierte Rechner, welche virtuelle Maschine oder welcher Container ihn aufnimmt;
- welche Datenbankobjekte und repräsentativen Datensätze vorhanden sein müssen;
- welche schreibgeschützten Anwendungspfade geprüft werden;
- welche externen Komponenten bewusst außerhalb dieser Übung liegen; und
- wann die Zeitmessung beginnt und welches Ereignis als abgeschlossene Recovery gilt.
Das ist eine kleine Ausprägung eines umfassenderen Contingency-Planning-Gedankens. NIST SP 800-34 Rev. 1 behandelt Recovery-Anforderungen, Prioritäten und Übungen als Bestandteile der Planung statt als Entscheidungen, die erst nach einer Störung improvisiert werden. Ein privater Heimserver braucht keine Verwaltung wie eine US-Bundesbehörde, profitiert aber ebenfalls von der Trennung zwischen einer beabsichtigten Prozedur und einer tatsächlich erprobten Fähigkeit.
Drei Prüfungen beantworten drei unterschiedliche Fragen
1. Lässt sich der Backup-Speicher lesen?
Eine Integritätsprüfung des Repositorys sucht nach beschädigten oder fehlenden Backup-Daten. Bei restic prüft check standardmäßig die Repository-Struktur. Laut der restic-Dokumentation zu Repositorys erfordert die Prüfung der eigentlichen Pack-Daten --read-data oder eine --read-data-subset-Option. Das Lesen sämtlicher Daten kann Zeit beanspruchen und bei einem entfernten Repository Bandbreitenkosten verursachen.
Diese Prüfung ist wichtig, startet jedoch kein MariaDB. Ein strukturell intaktes Repository kann trotzdem den falschen Dump, eine unvollständige Auswahl von Datenbankobjekten oder einen Dump enthalten, den die aktuelle Recovery-Umgebung nicht verwenden kann.
2. Kann MariaDB das Backup verarbeiten?
Die nächste Ebene stellt das Datenbankmaterial in einem isolierten Ziel wieder her. Dadurch werden Syntaxfehler, inkompatible Funktionen, fehlende Berechtigungen, unzureichender Speicherplatz und manche unvollständige Backup-Auswahl sichtbar. Außerdem treten manuelle Schritte zutage, die zuvor nur im Gedächtnis einer Person existierten.
Auch hier ist ein Exit-Status von null lediglich eine Beobachtung. Er beweist nicht, dass jede Zeile, Beziehung, Routine oder jedes Zeichen mit der beabsichtigten Bedeutung erhalten blieb.
3. Kann die Anwendung das Ergebnis verwenden?
Die letzte Ebene verbindet eine temporäre Anwendungsinstanz mit der wiederhergestellten Datenbank und prüft ausgewählte Lesewege. Allein die Antwort der Startseite ist ein schwacher Beleg: Sie könnte aus einem Cache stammen oder nur wenige Tabellen berühren. Aussagekräftigere Prüfungen decken gezielt repräsentative Inhalte, Authentifizierungsmetadaten ohne echte Anmeldung, Kategoriebeziehungen, mehrsprachige Texte und Funktionen ab, die von Views oder geplanten Datenbankobjekten abhängen.
Diese Ebenen ergänzen einander. Repository-Integrität, Importierbarkeit der Datenbank und Nutzbarkeit durch die Anwendung sollten nicht zu einem vagen Status „Backup OK“ zusammengefasst werden.
Die Art des wiederherzustellenden Backups kennen
Ein logischer Dump und ein physisches Backup erfordern unterschiedliche Verfahren. MariaDB dokumentiert mariadb-dump als Werkzeug, das SQL-Anweisungen zur Rekonstruktion von Datenbankstrukturen und Daten schreibt. Das Ergebnis lässt sich untersuchen und über den MariaDB-Client importieren, was für eine kleine isolierte Übung praktisch ist.
Ein mit mariadb-backup erstelltes physisches Backup enthält Datenbankdateien statt einer portablen Folge von SQL-Anweisungen. MariaDBs Dokumentation zur vollständigen Sicherung und Wiederherstellung erklärt, dass diese Dateien vor dem Restore vorbereitet werden müssen. Das Copy-back-Verfahren verlangt einen gestoppten Server und ein leeres Datenverzeichnis; außerdem ist die Kompatibilität des Werkzeugs mit der betreffenden Serverversion relevant. Der Import einer SQL-Datei und das Kopieren vorbereiteter Datendateien sind daher keine austauschbaren Rezepte.
Für beide Arten sollte ein temporäres Ziel verwendet werden, das nicht versehentlich in die Produktion schreiben kann. Ein alternativer Datenbankname auf dem Produktionsserver ist weniger isoliert als eine separate MariaDB-Instanz: Ressourcenknappheit, Kontofehler oder eine falsch konfigurierte Anwendung könnten weiterhin den Live-Dienst beeinträchtigen. Eine separate VM, ein Container oder ein Ersatzhost schafft, sofern verfügbar, eine deutlichere Grenze.
Eine begrenzte Übung für einen logischen MariaDB-Dump
1. Quelle und Ziel dokumentieren
Der genaue Snapshot, der Dump-Zeitpunkt, sofern bekannt, seine Größe sowie die zum Erstellen und Wiederherstellen verwendeten MariaDB-Versionen sollten festgehalten werden. Ebenso wichtig sind der erwartete Datenbankname und die Anwendungsversion, die dieses Schema verstehen soll. „Latest“ sollte nicht stillschweigend gewählt werden: Der Wiederherstellungspunkt einer Übung muss sichtbar sein.
Liegt die SQL-Datei in einem restic-Snapshot, wird sie in ein separates Verzeichnis wiederhergestellt. Die restic-Dokumentation zur Wiederherstellung unterstützt ein getrenntes Ziel und warnt davor, dass ein unterbrochener In-place-Restore Dateien in einem teilweise wiederhergestellten Zustand hinterlassen kann. Die erfolgreiche Wiederherstellung der SQL-Datei belegt nur diese Ebene; der Datenbankimport bleibt ein eigener Schritt mit eigenen Nachweisen.
2. Prüfen, wie der Dump erstellt wurde
Der Befehl, der den Dump erzeugt hat, gehört zum Recovery-Design. MariaDB dokumentiert, dass Trigger standardmäßig enthalten sind, während gespeicherte Routinen und Events Optionen wie --routines und --events benötigen. Eine Website, die auf eine dieser Funktionen angewiesen ist, kann sämtliche Tabellen besitzen und dennoch unvollständig sein.
Auch Konsistenz braucht eine Einschränkung. Bei transaktionalen Tabellen wie InnoDB kann --single-transaction einen konsistenten Zustand erfassen, ohne diese Tabellen während des gesamten Dumps zu sperren. Dieselbe Garantie gilt nicht automatisch für nicht transaktionale Engines, und gleichzeitiges DDL wie ALTER TABLE kann die Annahme ungültig machen. Deshalb sollten Engines und der konkrete Befehl geprüft werden, statt die Option nur als Ritual hinzuzufügen.
Ein Datenbankpasswort sollte nicht direkt in den Prozessargumenten stehen. Die MariaDB-Dokumentation bezeichnet das als unsicher und empfiehlt stattdessen eine Optionsdatei. Eine Recovery-Übung sollte kein Verfügbarkeitsproblem durch ein neues Zugangsdatenleck lösen.
3. In ein leeres, isoliertes Ziel importieren
Das neue Ziel benötigt ausreichend freien Speicherplatz und eine bewusst gewählte MariaDB-Version. Der logische Dump wird mit der für die installierte Version dokumentierten Client-Syntax importiert:
mariadb restore_drill < site-backup.sqlDieses Beispiel setzt voraus, dass eine leere Datenbank restore_drill bereits existiert, der Dump für genau eine Datenbank vorgesehen ist und die Authentifizierung aus einer geschützten Client-Konfiguration stammt. Mit --databases oder --all-databases erzeugte Dumps enthalten weiterreichende Anweisungen zur Datenbankauswahl und benötigen ein entsprechend isoliertes Ziel. Vor dem Import sollten Dateikopf und Erstellungsbefehl gelesen werden.
Client- und Serverversion, Start- und Endzeit, Exit-Status und Fehlerausgabe gehören in das Protokoll. Der Dump sollte nicht stillschweigend bearbeitet werden, nur damit die Übung besteht. Eine notwendige manuelle Reparatur ist eine Erkenntnis über den Recovery-Prozess.
4. Struktur und Bedeutung validieren
Am Anfang steht das Inventar der erwarteten Tabellen, Views, Trigger, Routinen und Events. Danach sollte die Prüfung über das Inventar hinausgehen. Eine kleine Menge vorab ausgewählter und inhaltlich verstandener Fakten wird verglichen: Anzahlen in plausiblen Bereichen, bekannte Datensatz-IDs, Eltern-Kind-Beziehungen, Eindeutigkeitsbedingungen und repräsentative Zeitstempel. Eine Gesamtzahl kann stimmen, obwohl wichtige Spalten abgeschnitten oder Beziehungen beschädigt sind.
Auch schwierige Texte gehören in die Stichprobe. Namen mit Akzenten, indonesische und deutsche Inhalte, Emoji, sofern die Anwendung sie erlaubt, sowie lange HTML-Felder können Zeichensatz- oder Kürzungsprobleme aufdecken, die reine ASCII-Testzeilen verbergen. Das ersetzt keine umfassende Validierung, liefert aber eine aussagekräftigere Stichprobe.
Werkzeuge zur Tabellenprüfung können zusätzliche Belege liefern, sind jedoch kein universeller Beweis. Storage Engines unterstützen unterschiedliche Prüfungen, und logische Konsistenz gehört zur Anwendung. Eine gültige Tabelle kann weiterhin eine Kategorie referenzieren, die nicht existiert, oder einen Veröffentlichungsstatus enthalten, den die Anwendung falsch interpretiert.
5. Die Anwendung ohne Nebenwirkungen prüfen
Eine temporäre Anwendungskopie wird mit der wiederhergestellten Datenbank verbunden, während ausgehende E-Mails, Push-Benachrichtigungen, Webhooks, geplante Jobs und Zahlungsintegrationen deaktiviert bleiben. Zuerst sollten schreibgeschützte Prüfungen erfolgen. Mehrere bewusst gewählte Routen werden geöffnet, darunter eine mit Beziehungen und eine mit mehrsprachigen oder älteren Daten. Caches werden umgangen oder leer gestartet, damit die Antwort tatsächlich vom wiederhergestellten Zustand abhängt.
Produktive Session-Secrets oder echte Zugangsdaten von Drittanbietern sollten nicht wiederverwendet werden, nur um die Testumgebung produktionsähnlich erscheinen zu lassen. Benötigen verschlüsselte Anwendungsdaten einen Schlüssel, wird diese Abhängigkeit dokumentiert und der Schlüssel über einen kontrollierten, übungsspezifischen Prozess bereitgestellt. Die Erkenntnis, dass eine Datenbank ohne einen fehlenden Schlüssel unbrauchbar ist, ist ein wichtiges Ergebnis und kein Grund, die Lücke zu verbergen.
Das Ergebnis in ein Recovery-Protokoll überführen
Ein nützliches Protokoll sagt mehr als „bestanden“. Es enthält den gewählten Wiederherstellungspunkt, die Dauer jeder Phase, verwendete Befehle oder Runbook-Versionen, abgeschlossene Prüfungen, beobachtete Fehler, manuelle Eingriffe und nicht getestete Komponenten. Abweichende Hardware, Speichergeschwindigkeit, MariaDB-Versionen oder Netzwerkbedingungen des Ziels werden ebenfalls notiert. Solche Unterschiede begrenzen, was die gemessene Zeit über einen echten Vorfall aussagt.
Jeder Fehler sollte zu einer konkreten Korrektur führen: Dump-Optionen ändern, eine fehlende Konfigurationsdatei aufbewahren, eine Abhängigkeit von einem Verschlüsselungsschlüssel dokumentieren, mehr temporären Speicher bereitstellen oder die Anwendungs-Checkliste aktualisieren. Danach wird der fehlgeschlagene Teil wiederholt. Eine Übung, die eine Lücke offenlegt, ist nützlich; ein Bericht, der Erfolg stillschweigend neu definiert, ist es nicht.
Die Häufigkeit sollte sich nach Änderungen und Folgen richten, nicht nach einer universellen Kalenderregel. Nach wesentlichen Änderungen an Datenbankversion, Backup-Methode, Schema, Verschlüsselung, Speicherziel oder Recovery-Umgebung ist eine Wiederholung sinnvoll. Eine kleine Website kann einen anderen Rhythmus wählen als ein System mit strengen Verfügbarkeitsverpflichtungen. Die ehrliche Frage lautet, ob die letzte Übung dem System noch ähnelt, das heute wiederhergestellt werden müsste.
Was die Übung weiterhin nicht beweisen kann
Ein erfolgreicher Restore garantiert weder den nächsten Snapshot noch das nächste Speichermedium oder Fehlerszenario. Das isolierte Ziel kann schneller oder langsamer als Ersatzhardware sein. DNS, TLS-Zertifikate, hochgeladene Medien, Warteschlangen, Object Storage oder externe APIs können fehlen. Ein logischer Dump kann Anwendungsdaten wiederherstellen, während Serverkonten oder Betriebskonfigurationen verloren bleiben, die nie zu seinem Umfang gehörten.
Auch die Datenprüfung bleibt eine Stichprobe. Repräsentative Datensätze können bedeutsame Fehler aufdecken, aber nicht die Richtigkeit jedes Werts beweisen. Größeres Vertrauen kann durch die Kombination aus Backup-Integritätsprüfungen, Datenbank-Constraints, Anwendungstests, Monitoring und gelegentlichen umfassenderen Recovery-Übungen entstehen. Jede Methode deckt einen anderen blinden Fleck ab.
Fazit
Ein Datenbank-Backup wird glaubwürdiger, wenn es den gesamten vorgesehenen Weg durchlaufen hat: aus dem Speicher in eine isolierte MariaDB-Instanz, durch strukturelle und semantische Prüfungen und schließlich in eine temporäre Anwendung. Das Ergebnis ist keine Gewissheit. Es ist ein datierter Beleg, ein gemessenes Verfahren und eine Liste von Abhängigkeiten, die während eines Ausfalls nicht mehr erraten werden müssen.
Der kleinste sinnvolle nächste Schritt besteht nicht darin, jedes Backup-System neu zu entwerfen. Ein vorhandener Dump wird ausgewählt, drei oder vier aussagekräftige Akzeptanzprüfungen werden definiert, der Dump wird fern der Produktion wiederhergestellt und jede Stelle dokumentiert, an der das Verfahren stockt. Gerade dieses Stocken ist häufig die wertvollste Erkenntnis eines Wiederherstellungstests.