Oracle Database · · 3 Min.

RMAN-Backups in 26ai absichern

Was AES-XTS für Backup-Sicherheit bedeutet und warum Restore-Tests wichtiger sind als ein starkes Algorithmuslabel.

Verschlüsselte Backups schützen Daten auch dann, wenn Backup-Sets, Object Storage oder Medien außerhalb der Datenbankumgebung in falsche Hände geraten. Oracle AI Database 26ai erweitert RMAN für neue Installationen und passende Kompatibilitätseinstellungen um AES-XTS. RMAN verwendet dabei standardmäßig AES256 im XTS-Modus für neue verschlüsselte Backups.

Wichtig: Die Wahl des Algorithmus allein macht einen Backup-Prozess nicht sicher. Schlüsselverwaltung, Zugriff auf Wallets, Backup-Katalog, Aufbewahrung und ein getesteter Restore gehören genauso dazu.

1. Was sich in 26ai ändert

Wenn COMPATIBLE auf mindestens 23.0.0 steht, kann RMAN die AES-XTS-Varianten AES256 und AES128 für Backup-Verschlüsselung verwenden. AES256 XTS ist für neue RMAN-Backups als Standard vorgesehen. Bei niedrigerem COMPATIBLE-Wert bleibt das bisherige AES-CFB-Verhalten bestehen.

Das ist für Upgrades wichtig: Nicht jede 26ai-Datenbank verhält sich allein durch die Softwareversion gleich. Prüfen Sie die Einstellung in jeder CDB und PDB, dokumentieren Sie die tatsächliche RMAN-Konfiguration und klären Sie, welche Algorithmen die vorhandene Restore-Umgebung unterstützt.

2. Algorithmus, Schlüssel und Zugriff trennen

Ein Backup kann korrekt verschlüsselt sein und trotzdem nicht wiederherstellbar, wenn die Schlüssel oder Wallets fehlen. Begrenzen Sie den Zugriff auf Verschlüsselungs-Credentials und trennen Sie Rollen für Backup-Ausführung, Schlüsselverwaltung und Restore-Freigabe. Der Backup-Operator sollte nicht automatisch uneingeschränkten Zugriff auf alle Schlüsselmaterialien erhalten.

Dokumentieren Sie außerdem, wie Schlüssel rotieren, wie alte Backups lesbar bleiben und wie ein Restore in einer isolierten Umgebung auf die benötigten Credentials zugreift. Die Aufbewahrungsfrist des Schlüssels muss mindestens zur Aufbewahrungsfrist der verschlüsselten Backup-Sets passen.

3. Migration und gemischte Umgebungen

In vielen Unternehmen laufen 19c, 23ai und 26ai parallel. Ein Backup-Runbook muss daher zwischen alten und neuen Algorithmusprofilen unterscheiden. Testen Sie die Kombination aus Zielversion, RMAN-Client, Recovery Catalog, Wallet und Backup-Ziel – insbesondere, wenn Backups über einen zentralen Katalog oder auf mehreren Plattformen verwaltet werden.

Planen Sie die Umstellung nicht nur für Vollbackups. Auch inkrementelle Sicherungen, Archivlogs, Standby-Umgebungen und Klone müssen in den Test einbezogen werden. Ein erfolgreicher Backup-Job beweist nur, dass geschrieben wurde; erst ein validierter Restore beweist, dass die Kette nutzbar ist.

4. DBA-Checkliste

  1. COMPATIBLE, Datenbankversion und RU-Stand aller Zielsysteme erfassen.
  2. RMAN-Verschlüsselungsalgorithmus und Credential- beziehungsweise Wallet-Zugriff dokumentieren.
  3. Schlüsselrotation und Aufbewahrungsfristen aufeinander abstimmen.
  4. Vollbackup, Inkremente, Archivlogs und Recovery Catalog in einer Testumgebung wiederherstellen.
  5. Restore-Zeiten, Berechtigungen, Audit-Einträge und Notfallzugriff regelmäßig überprüfen.
Praxisregel: Ein Backup gilt erst dann als belastbar, wenn ein Restore mit den real verfügbaren Schlüsseln und Berechtigungen erfolgreich getestet wurde – nicht nur, wenn RMAN den Job mit „completed“ beendet.

Fazit

Oracle AI Database 26ai hebt die Verschlüsselungsoptionen für RMAN-Backups mit AES-XTS auf ein moderneres Niveau. Für DBAs entsteht der Nutzen aber erst durch eine vollständige Kette aus kompatibler Konfiguration, geschütztem Schlüsselzugriff, gemischter Umgebungsplanung und wiederholbaren Restore-Tests.

Weiterführend: die Oracle Backup and Recovery User’s Guide, die RMAN-CONFIGURE-Referenz und die RMAN-Übersicht.