Ein erfolgreicher RMAN-Backup-Job ist ein wichtiger Status – aber noch kein Beweis, dass sich die Datenbank im Notfall wiederherstellen lässt. Auch die verschiedenen RMAN-Validierungsbefehle testen nicht alle denselben Teil der Kette. Wer sie im Runbook richtig kombiniert, erkennt fehlende oder beschädigte Sicherungen früher und weiß, welche Lücken nur ein tatsächlicher Restore-Test schließen kann.
BACKUP VALIDATE liest die aktuellen Datenbankdateien, ohne ein Backup zu schreiben. RESTORE ... VALIDATE prüft, ob RMAN passende vorhandene Sicherungen lesen und für einen Restore verwenden kann – ohne Dateien zurückzuschreiben.1. BACKUP VALIDATE: Sind die Quelldateien lesbar?
Dieser Befehl liest die Dateien, die in einem Backup enthalten wären, und prüft unter anderem auf physische Blockkorruption sowie fehlende Dateien. Er erzeugt selbst jedoch keine Backup-Sets. Mit CHECK LOGICAL werden zusätzlich bestimmte logische Blockfehler gesucht:
BACKUP VALIDATE CHECK LOGICAL
DATABASE
ARCHIVELOG ALL;
Das ist hilfreich als regelmäßiger Datenbank-Health-Check und kann Korruption sichtbar machen, bevor ein Backup-Job oder ein späterer Restore davon betroffen ist. Die Prüfung liest umfangreiche Datenmengen und sollte daher hinsichtlich I/O, CPU und Laufzeit geplant werden.
2. RESTORE ... VALIDATE: Kann RMAN die Sicherung verwenden?
Bei RESTORE DATABASE VALIDATE wählt RMAN selbst die Backups aus, die es für einen Restore einsetzen würde, und liest die Backup-Blöcke. Es schreibt dabei keine Datafiles zurück und verändert die Produktionsdateien nicht. Mit RESTORE ARCHIVELOG ALL VALIDATE lässt sich ergänzend die Verfügbarkeit der Archivlogs prüfen, die für den geplanten Wiederherstellungszeitraum benötigt werden.
RESTORE DATABASE VALIDATE;
RESTORE ARCHIVELOG ALL VALIDATE;
Wenn Sie gezielt ein bestimmtes Backup-Set prüfen wollen, verwenden Sie VALIDATE BACKUPSET. Ein RESTORE ... PREVIEW ist dagegen nur eine Vorschau darauf, welche Sicherungen RMAN auswählen würde; es liest nicht die gesamten Backup-Inhalte und ersetzt keine Validierung.
3. Was nur ein echter Restore beweist
Validierung schreibt keine wiederhergestellten Dateien und testet daher nicht den kompletten Betriebsablauf. Ein isolierter Restore zeigt zusätzlich, ob Zielpfade, Storage, Wallets für verschlüsselte Backups, Oracle-Home, Control-File, Passwortzugriff und Recovery-Prozess zusammen funktionieren. Für eine sichere Probe müssen Testumgebung und Produktionsdaten sauber getrennt sein; insbesondere dürfen Recovery Area und Datenbankidentität nicht versehentlich mit Produktion kollidieren.
Für bestimmte Szenarien kann RECOVER ... TEST außerdem die Anwendung von Redo probeweise im Speicher ausführen. Auch das ersetzt keinen regelmäßigen Restore auf ein separates Ziel mit anschließender fachlicher Prüfung der Datenbank.
Ein praktikabler Prüfplan
- Backup-Jobs und RMAN-Logs überwachen; erfolgreiche Sicherungen samt Archivlogs und Control-File-Autobackups nachweisen.
- Regelmäßig
BACKUP VALIDATEausführen und bei Bedarf mitCHECK LOGICALlogische Blockprüfungen ergänzen. RESTORE ... VALIDATEauf den gewünschten Recovery-Zeitraum und die benötigten Backup-Medien ausrichten.- Fehler wie fehlende Pieces oder
RMAN-06026als Betriebsalarm behandeln, nicht nur im Log archivieren. - In festen Abständen einen vollständigen Restore in einer isolierten Umgebung durchführen und Start, Recovery, Anwendungszugriff sowie gemessene Wiederherstellungszeit dokumentieren.
Fazit
RMAN-Validierung ist ein wertvoller automatisierbarer Schutz, aber kein Ersatz für einen Restore-Drill. Kombinieren Sie Prüfungen der Quelldateien, der tatsächlich verfügbaren Backups und regelmäßige echte Wiederherstellungen. Erst der letzte Schritt zeigt, ob technische Sicherungen auch innerhalb der vereinbarten RTO- und RPO-Ziele wieder zu einem nutzbaren System werden.
Weiterführend: Oracles Anleitung zum Validieren von Datenbankdateien und Backups, zur RMAN-RESTORE-Referenz und zur vollständigen Datenbankwiederherstellung.