Backup und Recovery in Base Database Service

Die Sicherung Ihrer Datenbank ist wichtig für die Sicherheit Ihrer Daten. Oracle bietet verschiedene Methoden zum Sichern Ihrer Datenbank.

Das von Oracle verwaltete Feature für automatische Backups ist die bevorzugte Methode für die Sicherung von Oracle Cloud-Datenbanken, da Sie Backupeinstellungen einfach mit der Konsole konfigurieren können. Die Funktion für automatische Backups unterstützt Recovery Service und Object Storage als Backupziel, sodass Sie eine vollständig automatisierte Cloud-Backuplösung mit den gleichen Kosten erhalten. Sie müssen keine manuellen Backups oder Administrationsaufgaben für Backupspeicher ausführen. Sie können Backups auch im lokalen Speicher speichern. Jedes Backupziel hat seine Vorteile und Anforderungen, die Sie berücksichtigen sollten (siehe Beschreibung unten).

Recovery Service (empfohlen)

Ein vollständig verwalteter Service, der auf der Zero Data Loss Recovery Appliance-Technologie von Oracle On-Premises basiert und modernen Cybersicherheitsschutz für Oracle Databases bietet. Einzigartige, automatisierte Funktionen schützen Oracle Database-Änderungen in Echtzeit, validieren Backups ohne Overhead der Produktionsdatenbank und ermöglichen ein schnelles, vorhersehbares Recovery zu jedem Zeitpunkt.

Wenn Ihre Backups derzeit mit Object Storage konfiguriert sind, können Sie nahtlos zu Recovery Service wechseln, um erweiterte Funktionen mit den gleichen Kosten zu erreichen.

Weitere Informationen zu Recovery Service finden Sie unter Oracle Database Autonomous Recovery Service.

Objektspeicher

Eine sichere, skalierbare On-Demand-Speicherlösung für Datenbanken.

Weitere Informationen zu Object Storage finden Sie unter Überblick über Object Storage.

Lokaler Speicher

• Backups werden lokal im Fast Recovery-Bereich des DB-Systems gespeichert.
• Dauerhaftigkeit: Niedrig
• Verfügbarkeit: Mittel
• Backup- und Recovery-Rate: Hoch
• Vorteile: Optimiertes Backup und schnelles Point-in-Time Recovery.
• Nachteile: Wenn das DB-System nicht verfügbar ist, ist auch das Backup nicht verfügbar.

Derzeit können Sie mit Oracle keine Blockspeicher-Volumes an ein DB-System anhängen, sodass Sie kein Backup auf Volumes erstellen können, die an das Netzwerk angehängt sind.

Bei nicht verwalteten Backups können Sie RMAN oder dbcli verwenden. Außerdem müssen Sie Ihre eigenen Objektspeicher-Buckets für Backups erstellen und verwalten.

Hinweis: Wenn Sie Backups vorher mit RMAN oder dbcli konfiguriert haben und dann zur Konsole oder API für Backups wechseln, wird eine neue Backupkonfiguration erstellt und mit der Datenbank verknüpft. Das bedeutet, dass die zuvor konfigurierten nicht verwalteten Backups dann eventuell nicht mehr funktionieren.

Ausführliche Anweisungen zum Erstellen von Backups finden Sie unter:

• Datenbank mit der Konsole sichern
• Datenbank mit RMAN in Object Storage sichern

Ausführliche Anweisungen zum Recovery von Backups finden Sie unter:

• Datenbank mit der Konsole wiederherstellen
• Datenbank mit RMAN-Backups aus Object Storage wiederherstellen
• Datenbank aus dem OCI Classic-Objektspeicher wiederherstellen

Erforderliche IAM-Policy

Um Oracle Cloud Infrastructure verwenden zu können, muss einem Administrator der Sicherheitszugriff in einer Policy erteilt werden. Dieser Zugriff ist unabhängig davon erforderlich, ob Sie die Konsole oder die REST-API mit einem SDK, einer CLI oder einem anderen Tool verwenden. Wenn Sie eine Meldung erhalten, dass Sie keine Berechtigung haben oder nicht autorisiert sind, fragen Sie den Administrator, welcher Zugriffstyp Ihnen zugewiesen wurde und in welchem Compartment Sie arbeiten sollen.

Wenn Sie mit Policys nicht vertraut sind, finden Sie weitere Informationen unter Erste Schritte mit Policys und Allgemeine Policys.

Voraussetzungen

Prüfen Sie und stellen Sie sicher, dass die folgenden Voraussetzungen für den Backup- und Recovery-Vorgang erfüllt sind:

Recovery Service

Ausführliche Informationen zu den Voraussetzungen für Recovery Service finden Sie unter Recovery Service konfigurieren.

Objektspeicher

• Für das DB-System ist Zugriff auf Object Storage erforderlich, einschließlich Verbindung zum entsprechenden Swift-Endpunkt. Oracle empfiehlt, ein Servicegateway mit dem VCN zu verwenden, um diesen Zugriff zu ermöglichen. Siehe VCN und Subnetze.
• Einen vorhandener Objektspeicher-Bucket, der als Backupziel verwendet wird. Sie können den Bucket über die Konsole oder die Object Storage-API erstellen. Siehe Buckets verwalten.
• Ein von OCI generiertes Authentifizierungstoken. Sie können das Kennwort mit der Konsole oder der IAM-API generieren. See Benutzerzugangsdaten verwalten.

• Der in der Backupkonfiguration angegebene Benutzername muss Zugriff auf Object Storage auf Mandantenebene haben. Dazu können Sie den Benutzernamen der Administratorengruppe hinzufügen. Dadurch wird allerdings der Zugriff auf alle Cloud-Services erteilt. Stattdessen sollte ein Administrator eine Policy wie im folgenden Beispiel erstellen, die den Zugriff auf nur die erforderlichen Ressourcen in Object Storage für Backup und Wiederherstellung der Datenbank einschränkt:

  Allow group <group_name> to manage objects in compartment <compartment_name> where target.bucket.name = '<bucket_name>'
  Allow group <group_name> to read buckets in compartment <compartment_name>

  Weitere Informationen darüber, wie Sie einer Gruppe einen Benutzer hinzufügen, finden Sie unter Gruppen verwalten.

Weitere Informationen zu Object Storage finden Sie unter Überblick über Object Storage.

Allgemeine Informationen

Der Status von Datenbank und DB-System muss "Verfügbar" lauten, damit ein Backupvorgang erfolgreich ausgeführt werden konnte. Oracle empfiehlt, dass Sie keine Aktionen ausführen, die sich auf die Verfügbarkeit auswirken könnten (wie Patching und Data Guard-Vorgänge), während ein Backupvorgang ausgeführt wird. Wenn ein automatischer Backupvorgang nicht erfolgreich verläuft, wiederholt der Datenbankservice den Vorgang während des Backupfensters des nächsten Tages. Wenn ein vollständiges On-Demand-Backup nicht erfolgreich verläuft, können Sie den Vorgang erneut ausführen, wenn die Verfügbarkeit des DB-Systems und der Datenbank wiederhergestellt ist.

Stellen Sie sicher, dass zusätzlich zu den aufgeführten Voraussetzungen die folgenden Bedingungen erfüllt sind, um Backupfehler zu vermeiden:

• Der Archivierungsmodus der Datenbank ist auf ARCHIVELOG gesetzt (Standardwert).
• Das Verzeichnis /u01 im Dateisystem des Datenbankhosts verfügt über ausreichend freien Speicherplatz zur Ausführung von Backupprozessen.
• Die .bash_profile-Datei für den Benutzer "oracle" enthält keine interaktiven Befehle (wie oraenv oder einen Befehl, der eine Fehler- oder Warnmeldung generieren könnte).
• (Bei automatischen Backups) Es wurden keine Änderungen am Standardeintrag WALLET_LOCATION in der Datei sqlnet.ora vorgenommen.
• Es wurden keine Änderungen an den RMAN-Backupeinstellungen mit den standardmäßigen RMAN-Befehlen vorgenommen.

Weitere Informationen zu Problemen, die sich aus der Nichtbefolgung dieser Richtlinien ergeben können, finden Sie unter Backupfehler beheben.

Features für verwaltete Backups

Die folgenden Informationen gelten für verwaltete Backups, die mit der Konsole oder der API konfiguriert wurden.

Hinweis: Für Datenbanken in einem Sicherheitszonen-Compartment müssen automatische Backups aktiviert werden. Eine vollständige Liste der Policys, die sich auf Ressourcen von Base Database Service auswirken, finden Sie unter Sicherheitszonen-Policys.

Derzeit werden die folgenden beiden Arten von automatischen Backups unterstützt:

• Recovery Service: Eine zentralisierte, vollständig verwaltete und eigenständige Backuplösung für Datenbanken.
• Object Storage: Eine sichere, skalierbare On-Demand-Speicherlösung für Datenbanken.

Um die von Oracle empfohlene Vorgehensweise bei der Verwendung der administrativen SYSBACKUP-Berechtigungen für Backup- und Recovery-Vorgänge zu entsprechen, erstellt der Cloud-Automatisierung einen allgemeinen Benutzer C##DBLCMUSER mit den SYSBACKUP-Rollen auf der CDB$ROOT-Containerebene. Sicherungs- und Wiederherstellungsvorgänge werden daher mit einem Benutzer ausgeführt, der über die geringsten erforderlichen Berechtigungen verfügt. Zugangsdaten für diesen Benutzer werden zufällig generiert und sicher von der Cloud-Automatisierung verwaltet. Wenn der Benutzer nicht gefunden wird oder LOCKED und EXPIRED ist, wird dieser Benutzer während der Backup- oder Recovery-Vorgänge von der Cloud-Automatisierung neu erstellt oder entsperrt.

Automatische inkrementelle Backups und Backups des archivierten Redo-Logs

Wenn Sie das Object Storage-Backupfeature für eine Datenbank aktivieren, erstellt der Service fortlaufend Folgendes:

• Wöchentliches Backup der Ebene 0, wird in der Regel an einem angegebenen Wochenende erstellt. Ein Backup der Ebene 0 entspricht einem vollständigen Backup. Beachten Sie, dass in der Konsole wöchentliche Backups von Ebene 0 in der Liste der Backups mit dem Backupttyp "Inkrementell" angezeigt werden, ebenso wie tägliche Backups von Ebene 1.
• Tägliche Backups der Ebene 1. Das sind inkrementelle Backups, die an jedem der sechs Tage nach dem Backup der Ebene 0 erstellt werden.
• Backups der Ebenen 0 und 1 werden in Object Storage gespeichert und erhalten eine OCID.
• Fortlaufende Backups des archivierten Redo-Logs (mit einer minimalen Häufigkeit von "Alle 60 Minuten"). Im Feld Letzte Backupzeit auf der Seite mit den Datenbankdetails in der OCI-Konsole wird die Zeit der letzten archivierten Redo-Logs angezeigt. Dieses Backup unterscheidet sich dahingehend von den automatischen Backups der Ebenen 0 und 1, dass es auf Logdaten basiert und keine zugewiesene OCID aufweist. Mit dem Backup des letzten archivierten Redo-Logs kann eine neue Datenbank erstellt oder eine Datenbank mit minimalem Datenverlust wiederhergestellt werden.

Backupaufbewahrung

Wenn Sie automatische Backups aktivieren, können Sie einen der angegebenen Aufbewahrungszeiträume oder eine benutzerdefinierte Policy auswählen. Das System löscht die inkrementellen Backups automatisch am Ende des ausgewählten Aufbewahrungszeitraums.

Die folgenden Aufbewahrungszeiträume sind für Recovery Service verfügbar. Die Aufbewahrungszeiträume (in Tagen) sind in der Schutz-Policy von Recovery Service definiert.

• Bronze (14 Tage)
• Silber (35 Tage) (Standard)
• Gold (65 Tage)
• Platin (95 Tage)
• Benutzerdefiniert (Benutzerdefinierte Schutz-Policy)

Die folgenden Aufbewahrungszeiträume sind für Object Storage verfügbar.

• 7 Tage
• 15 Tage
• 30 Tage (Standard)
• 45 Tage
• 60 Tage

Backup der langfristigen Aufbewahrung mit Recovery Service

Mit LTR (Long-term Retention Backup) können Sie vollständige Backups für einen Zeitraum von bis zu zehn Jahren für Compliance-, behördliche oder andere Geschäftsanforderungen mit vollständigem LTR-Lebenszyklusmanagement und Unveränderlichkeit speichern.

Bei LTR mit Recovery Service muss der Aufbewahrungszeitraum in Tagen (90 - 3650) oder Jahren (1 - 10) ab dem Zeitpunkt der Erstellung des Backups liegen.

Um ein LTR-Backup mit dem erforderlichen Aufbewahrungszeitraum zu erstellen, muss für Recovery Service kein neues vollständiges Produktionsbackup erstellt werden. Dies geschieht jedoch, indem bereits vorhandene operative Backups im System innerhalb des definierten Recovery-Fensters in der Policy verwendet werden. Ausführliche Schritte finden Sie unter On-Demand-Backup einer Datenbank erstellen.

Sie können den Aufbewahrungszeitraum für ein bestimmtes vorhandenes LTR-Backup innerhalb des Aufbewahrungszeitraums ändern. Ausführliche Schritte finden Sie unter Aufbewahrungszeitraum eines Backups mit langfristiger Aufbewahrung mit Recovery Service ändern.

Sie können ein LTR-Backup wiederherstellen, um innerhalb des Aufbewahrungszeitraums eine neue Datenbank zu erstellen. Ausführliche Schritte finden Sie unter DB-Systeme mit der Konsole mit einem Backup erstellen.

Beim Beenden des DB-Systems werden die LTR-Backups gemäß dem Wert "Löschoptionen nach Datenbankbeendigung" gelöscht.

• Backups in 72 Stunden löschen: Alle Backups, einschließlich LTR-Backups, werden gelöscht.
• Basierend auf Policy löschen: LTR-Backups werden gemäß der Aufbewahrungs-Policy jedes LTR-Backups beibehalten.

Hinweis: Oracle empfiehlt, beim Beenden eines DB-Systems die Option "Basierend auf Policy löschen" zu wählen, um sicherzustellen, dass die LTR-Backups beibehalten werden.

Beachten Sie die folgenden zusätzlichen Faktoren für LTR-Backups:

• LTR-Backups bestehen weiterhin unabhängig von automatischen Backups, die in der Datenbank konfiguriert sind.
• LTR-Backups werden nach Ablauf des angegebenen Aufbewahrungszeitraums automatisch gelöscht.
• In-Place-Wiederherstellung wird für LTR nicht unterstützt.
• Bei Datenbanken in einer Data Guard-Konfiguration wird das LTR-Backup nur für die Datenbank erstellt, in der es angefordert wird.
• Die Datenbank muss den Status AVAILABLE aufweisen, um eine LTR zu erstellen.
• LTR wird für Datenbanken mit dateibasierten TDE- oder KMS-basierten Keystores unterstützt.
• Alle Verschlüsselungsschlüssel werden für den gesamten Aufbewahrungszeitraum der LTR verwaltet.
• Sie können eine LTR abbrechen, wenn sie sich im Status "Wird erstellt" befindet.
• Sie können ein LTR-Backup jederzeit nach seiner Erstellung löschen.
• Wenn das wiederhergestellte LTR-Backup während der Wiederherstellung eine unterstützte DB Home-Hauptversion ist, wird es auf das neueste RU dieser Version wiederhergestellt.
• Wenn das wiederhergestellte LTR-Backup während der Wiederherstellung keine unterstützte DB Home-Hauptversion ist, wird es auf eine der unterstützten Hauptversionen wiederhergestellt, auf denen das Upgrade der Datenbank auf eine der unterstützten Hauptversionen erfolgen muss.

Restore-Optionen

Die folgenden Wiederherstellungsoptionen sind für die Datenbank verfügbar. Dies wird für LTR nicht unterstützt.

• Im letzten Zustand wiederherstellen: Stellt die Datenbank im letzten bekannten fehlerlosen Zustand mit dem geringstmöglichen Datenverlust zurück.
• Mit einem Zeitstempel wiederherstellen: Stellt die Datenbank mit dem angegebenen Zeitstempel wieder.
• Mit SCN wiederherstellen: Stellt die Datenbank mit der angegebenen Systemänderungsnummer (SCN) wieder. Diese SCN muss gültig sein.

Hinweis: Sie können die zu verwendende SCN-Nummer ermitteln, indem Sie entweder auf dem Datenbankhost zugreifen und diese abfragen oder auf ein beliebiges Onlinelog oder archiviertes Log zugreifen.

Schutz-Policys

Recovery Service verwendet Schutz-Policys, um die Aufbewahrung von Datenbankbackups in Oracle Cloud zu kontrollieren.

Schutz-Policys stellen ein automatisiertes Aufbewahrungsmanagement für geschützte Datenbanken bereit, das die Anforderungen für regulierte Umgebungen erfüllt. Jede geschützte Datenbank muss mit einer Schutz-Policy verknüpft sein.

Eine Schutz-Policy bestimmt den maximalen Zeitraum (in Tagen), über den Backups aufbewahrt werden können, die von Recovery Service erstellt wurden. Je nach Ihren Geschäftsanforderungen können Sie für jede geschützte Datenbank separate Policys zuweisen oder nur eine Policy für alle geschützten Datenbanken in einem VCN verwenden.

Weitere Informationen finden Sie unter Schutz-Policys verwalten.

Geschützte Datenbanken

Eine geschützte Datenbank ist eine Oracle Cloud-Datenbank, die Recovery Service für Backupvorgänge verwendet.

Weitere Informationen finden Sie unter Geschützte Datenbanken verwalten.

Echtzeit-Datenschutz

Recovery Service bietet Echtzeit-Datenschutz, damit Sie eine Datenbank in Bruchteilen einer Sekunde nach einem Datenbankfehler wiederherstellen können.

Echtzeitschutz ist die kontinuierliche Übertragung von Redo-Änderungen von einer geschützten Datenbank an Recovery Service. Dies reduziert den Datenverlust und bietet ein Recovery Point Objective (RPO) nahe 0. Diese Option ist gegen einen Aufpreis erhältlich.

Weitere Informationen finden Sie unter Echtzeit-Datenschutz.

Backuplöschoptionen nach Datenbankbeendigung

Wenn Sie eine Datenbank beenden, werden alle zugehörigen Ressourcen sowie automatischen Backups gelöscht. Verwaltete Backups mit dem Recovery Service- und Object Storage-Ziel werden entsprechend den ausgewählten Aufbewahrungs-Policy-Optionen gelöscht.

Sie können die folgenden Optionen verwenden, um verwaltete Datenbankbackups beizubehalten, nachdem die Datenbank beendet wurde. Mit diesen Optionen kann die Datenbank auch bei versehentlicher oder böswilliger Beschädigung der Datenbank aus Backups wiederhergestellt werden.

• Backups gemäß dem Aufbewahrungszeitraum beibehalten: Wenn eine Datenbank beendet wird, werden die automatischen Datenbankbackups, die mit der beendeten Datenbank verknüpft sind, und alle zugehörigen Ressourcen am Ende des angegebenen Aufbewahrungszeitraums entfernt.
• Backups 72 Stunden lang beibehalten, dann löschen: Wenn eine Datenbank beendet wird, werden die automatischen Datenbankbackups, die mit der beendeten Datenbank verknüpft sind, 72 Stunden lang aufbewahrt und anschließend gelöscht. Die Backups werden 72 Stunden lang aufbewahrt, um eine versehentliche Löschung durch den Benutzer zu verhindern.

Backupplanung

Bei Backups in Recovery Service wird der automatische Backupprozess zu einer beliebigen Zeit oder innerhalb des zugewiesenen Zeitfensters gestartet.

Bei Backups in Object Storage kann der automatische Backupprozess zum Erstellen von Backups der Ebenen 0 und 1 jederzeit innerhalb des täglichen Backupfensters (zwischen Mitternacht und 06:00 Uhr) ausgeführt werden. Sie können optional ein 2-stündiges Planungsfenster für Ihre Datenbank angeben, in dem der automatische Backupprozess beginnt. Sie können aus 12 Planungsfenstern wählen, die jeweils zu einer geraden Stunde beginnen (Beispiel: ein Fenster wird von 04:00-06:00 und das nächste von 06:00-08:00 ausgeführt). Backupjobs werden nicht unbedingt innerhalb des Planungsfensters abgeschlossen.

Bei Backups in Object Storage wird der Datenbank das Standardbackupfenster von 00:00 bis 06:00 Uhr in der Zeitzone der DB-Systemregion zugewiesen, wenn Sie kein Backupfenster angeben. Beachten Sie, dass das Standardfenster für die Backupplanung sechs Stunden lang ist, während die von Ihnen angegebenen Fenster zwei Stunden lang sind.

Berücksichtigen Sie bei der Planung von Backups die folgenden Faktoren.

• Zeitzone für Backup-Fenster: Automatische Backups, die erstmalig nach dem 20. November 2018 für eine Datenbank aktiviert werden, werden zwischen Mitternacht und 6:00 Uhr in der Zeitzone der Region des DB-Systems ausgeführt. Wenn Sie vor diesem Datum automatische Backups in einer Datenbank aktiviert haben, liegt das Backupfenster für die Datenbank weiterhin zwischen Mitternacht und 6:00 Uhr UTC. Sie können eine Serviceanfrage für My Oracle Support erstellen, damit die automatischen Backups in einem Backupfenster Ihrer Wahl ausgeführt werden.
• Data Guard: In einer Data Guard-Verknüpfung können Sie automatische Backups konfigurieren und Backups der Primärdatenbank erstellen. Sie können jedoch keine automatischen Backups konfigurieren oder Backups der Standbydatenbank erstellen. Außerdem müssen Sie nach einem Switchover-Vorgang erneut automatische Backups für die Datenbank konfigurieren, die in der Data Guard-Verknüpfung die primäre Rolle übernommen hat.
• Änderungen am Aufbewahrungszeitraum: Wenn Sie den Aufbewahrungszeitraum für automatische Backups der Datenbank in Zukunft verkürzen, werden vorhandene Backups, die außerhalb des aktualisierten Aufbewahrungszeitraums liegen, vom System gelöscht.
• Object Storage-Kosten: Für automatische Backups fallen Kosten für die Object Storage-Nutzungsgebühren an.

Vollständige On-Demand-Backups

Sie können jederzeit ein vollständiges Backup Ihrer Datenbank erstellen, es sei denn, die Datenbank übernimmt die Standbyrolle in einer Data Guard-Verknüpfung.

Standalone-Backups

Beim Beenden eines DB-Systems oder einer Datenbank werden alle zugehörigen Ressourcen sowie automatische Backups gelöscht. Verwaltete Backups mit Recovery Service und Object Storage als Ziel werden entsprechend den ausgewählten Aufbewahrungs-Policy-Optionen gelöscht. Vollständige Backups werden in Object Storage als Standalone-Backups aufbewahrt. Mit einem Standalone-Backup können Sie eine neue Datenbank erstellen.

Hinweis:

• Die in der Konsole angezeigte Backupliste enthält keine nicht verwalteten Backups (Backups, die direkt mit RMAN oder dbcli erstellt wurden).
• Alle Backups werden mit demselben Masterschlüssel verschlüsselt, der für die TDE-Wallet-Verschlüsselung verwendet wird.

Ausführung eines vollständigen oder inkrementellen Backups abbrechen

Sie können ein laufendes Backup abbrechen, um Systemressourcen freizugeben. Im Rahmen des Workflows "Datenbank erstellen" und unabhängig davon (nach dem Erstellen der Datenbank) können Sie das automatische Backup aktivieren und das gewünschte Backupziel auswählen. Je nach ausgewähltem Backupziel können Sie ein oder mehrere vollständige Backups und mehrere inkrementelle Backups erstellen. Wenn eines dieser Backups gestartet wurde, können Sie es vor Abschluss abbrechen. Sie können laufende Backups (automatisch oder Standalone) über die Konsole oder die API abbrechen. Sie können ein manuelles Backup abbrechen, das ausgelöst wird, wenn Sie auf die Schaltfläche "Backup erstellen" klicken. Sie können auch ein abgebrochenes manuelles Backup löschen.

Backup und Wiederherstellung in einer Data Guard-Verknüpfung aus einer Standbydatenbank

Sie können Backups und Wiederherstellungen aus einer Standbydatenbank in einer Data Guard-Verknüpfung erstellen. Mit diesem Feature können Sie Backups in die Standbydatenbank auslagern und dadurch Ressourcen in der primären Datenbank freigeben.

Beachten Sie Folgendes, bevor Sie beginnen:

• Mit Recovery Service oder Object Storage können Sie ein Backup der Standbydatenbanken erstellen.
• Sie können automatische Backups planen und Aufbewahrungszeiträume und Backupzeitpläne in der Standbydatenbank konfigurieren.
• Sie können eine Datenbank in einer anderen Availability-Domain (AD) innerhalb derselben Region oder in einer anderen Region als ein Backup der Standbydatenbank erstellen.
• Backups können nur in der Primärdatenbank, nur in der Standbydatenbank oder sowohl in der Primär- als auch in der Standbydatenbank konfiguriert werden. Bei der Konfiguration müssen sowohl die Primär- als auch die Standbydatenbank jedoch dasselbe Backupziel haben.
• Bei Backups im Recovery Service kann die Primärdatenbank zurückgeschrieben oder aus den Backups der Standbydatenbank oder der Primärdatenbank wiederhergestellt werden. Ebenso kann die Standbydatenbank aus den Backups der primären Datenbank oder der Standbydatenbank zurückgeschrieben oder wiederhergestellt werden.
• Bei Backups in Object Storage können die Primär- und die Standbydatenbank nur aus ihren jeweiligen Backups wiederhergestellt oder wiederhergestellt werden.
• Das Backupziel der Primärdatenbank und der Standbydatenbank in einer Data Guard-Verknüpfung muss identisch sein. Beispiel: Wenn das Backupziel der Primärdatenbank Recovery Service ist, muss das Backupziel der Standbydatenbank auch Recovery Service sein. Wenn das Backupziel der Standby-Datenbank Recovery Service ist, muss das Backupziel der primären Datenbank auch Recovery Service sein.
• Das Backupziel kann erst geändert werden, nachdem das Backup in der Primär- oder Standbydatenbank in einer Data Guard-Verknüpfung deaktiviert wurde. Beispiel: Wenn das Backupziel der Primär- und Standbydatenbank Object Storage ist und Sie das Backupziel der Primärdatenbank in Recovery Service ändern möchten, müssen Sie das Backup zunächst in der Standbydatenbank deaktivieren.
• Wenn das automatische Backup auf der Primärdatenbank konfiguriert wurde, werden die Backups bei einem Switchover auf der neuen Standbydatenbank fortgesetzt.
• Wenn das automatische Backup in der Standbydatenbank konfiguriert wurde, werden die Backups bei einem Failover in der neuen Primärdatenbank fortgesetzt, und die Backups werden in der neuen Standbydatenbank deaktiviert.

Ausführliche Schritte zum Konfigurieren automatischer Backups mit der Konsole finden Sie unter Automatische Backups für eine Standbydatenbank konfigurieren.

Regionsübergreifende Wiederherstellung

Sie können ein vorhandenes Backup verwenden und es wiederherstellen, um eine Datenbank (Out-of-Place-Wiederherstellung) über Availability-Domains in derselben Region oder in einer anderen Region zu erstellen. Verwenden Sie dazu ein Backup, das mit Object Storage oder Autonomous Recovery Service erstellt wurde.

Sie können auch ein Backup wiederherstellen, das auf einer Datenbank erstellt wurde, die mit hostbasierten Wallets (lokalen Wallets) konfiguriert wurde, oder OCI Vault. Weitere Informationen zu Datenbankverschlüsselungsschlüsseln finden Sie unter Verschlüsselungsschlüssel verwalten.

Die folgenden Voraussetzungen sind für die regionsübergreifende Wiederherstellung (innerhalb desselben Mandanten) für Oracle Database Autonomous Recovery Service erforderlich.

1. VCN-Peering: Sowohl die VCNs in lokalen als auch in Remoteregionen müssen regionsübergreifend per Peering verbunden sein.

2. Fügen Sie Sicherheitsregeln für die Quell- und Ziel-VCNs hinzu.

   1. Fügen Sie Ingress-Regeln für die Quelle hinzu.

      1. Klicken Sie auf Ingress-Regel hinzufügen, und fügen Sie die folgenden Details hinzu, um eine Regel einzurichten, die HTTPS-Traffic von überall aus zulässt:

         • Quelltyp: CIDR
         • Quell-CIDR: Geben Sie das CIDR des VCN an, in dem sich die Datenbank befindet.
         • IP-Protokoll: TCP
         • Quellportbereich: Alle
         • Zielportbereich: 8005
         • Beschreibung: Geben Sie eine optionale Beschreibung der Ingress-Regel an, um die Verwaltung der Sicherheitsregeln zu unterstützen.

      2. Klicken Sie auf "Ingress-Regel hinzufügen", und fügen Sie die folgenden Details hinzu, um eine Regel einzurichten, die SQLNet-Traffic von überall aus zulässt:

         • Quelltyp: CIDR
         • Quell-CIDR: Geben Sie das CIDR des VCN an, in dem sich die Datenbank befindet.
         • IP-Protokoll: TCP
         • Quellportbereich: Alle
         • Zielportbereich: 2484
         • Beschreibung: Geben Sie eine optionale Beschreibung der Ingress-Regel an, um die Verwaltung der Sicherheitsregeln zu unterstützen.

      3. Klicken Sie auf "Ingress-Regel hinzufügen", und fügen Sie die folgenden Details hinzu, um eine Regel einzurichten, die HTTPS-Traffic von überall aus zulässt:

         • Quelltyp: CIDR
         • Quell-CIDR: Geben Sie das CIDR des Ziel-VCN an.
         • IP-Protokoll: TCP
         • Quellportbereich: Alle
         • Zielportbereich: 8005
         • Beschreibung: Geben Sie eine optionale Beschreibung der Ingress-Regel an, um die Verwaltung der Sicherheitsregeln zu unterstützen.

      4. Klicken Sie auf "Ingress-Regel hinzufügen", und fügen Sie die folgenden Details hinzu, um eine Regel einzurichten, die SQLNet-Traffic von überall aus zulässt:

         • Quelltyp: CIDR
         • Quell-CIDR: Geben Sie das CIDR des Ziel-VCN an.
         • IP-Protokoll: TCP
         • Quellportbereich: Alle
         • Zielportbereich: 2484
         • Beschreibung: Geben Sie eine optionale Beschreibung der Ingress-Regel an, um die Verwaltung der Sicherheitsregeln zu unterstützen.

   2. Fügen Sie Egress-Regeln für das Ziel hinzu. Diese sind optional, wenn der Egress-Traffic für alle IPs und Ports geöffnet wird.

      1. Klicken Sie auf "Egress-Regel hinzufügen", und fügen Sie die folgenden Details hinzu, um eine Regel einzurichten, die HTTPS-Traffic von überall aus zulässt:

         • Quelltyp: CIDR
         • Quell-CIDR: Geben Sie das CIDR des Quell-VCN an.
         • IP-Protokoll: TCP
         • Quellportbereich: Alle
         • Zielportbereich: 8005
         • Beschreibung: Geben Sie eine optionale Beschreibung der Ingress-Regel an, um die Verwaltung der Sicherheitsregeln zu unterstützen.

      2. Klicken Sie auf "Egress-Regel hinzufügen", und fügen Sie die folgenden Details hinzu, um eine Regel einzurichten, die SQLNet-Traffic von überall aus zulässt:

         • Quelltyp: CIDR
         • Quell-CIDR: Geben Sie das CIDR des Quell-VCN an.
         • IP-Protokoll: TCP
         • Quellportbereich: Alle
         • Zielportbereich: 2484
         • Beschreibung: Geben Sie eine optionale Beschreibung der Ingress-Regel an, um die Verwaltung der Sicherheitsregeln zu unterstützen.

      Hinweis: Stellen Sie sicher, dass das Recovery-Servicesubnetz in der Quellregion vorhanden und an das Quell-VCN angehängt ist. Weitere Informationen finden Sie unter Recovery-Servicesubnetz im Datenbank-VCN erstellen.

3. Führen Sie DNS-Peering zwischen lokalen und Remote-VCNs aus.

Aufbewahrung von Audit- und Tracedateien für Datenbanken mit automatischen Backups

Oracle Database schreibt Audit- und Tracedateien in den lokalen Speicher der Datenbank im Verzeichnis /u01. Diese Dateien werden standardmäßig 30 Tage lang aufbewahrt. Sie können dieses Intervall jedoch ändern. Einmal täglich werden Audit- und Tracedateien, die älter als 30 Tage (oder gegebenenfalls älter das vom Benutzer angegebene Intervall) sind, von einem Oracle Scheduler-Job gelöscht. Sie können den Scheduler-Job auch deaktivieren, wenn Sie diese Dateien dauerhaft beibehalten möchten. Verwenden Sie die folgenden dbcli-Befehle, um Änderungen an diesem Scheduler-Job vorzunehmen.

• So ändern Sie die Standardeinstellung von 30 Tagen für den Aufbewahrungszeitraum:

  dbcli update-database -in <dbName> -lr <number_of_days_to_retain_files>

  Beispiel:

  dbcli update-database -in inventorydb -lr 15

• So deaktivieren Sie den täglichen Scheduler-Job zum Verwerfen älterer Audit- und Tracedateien:

  dbcli update-schedule -i <schedulerID> -d

  Beispiel:

  dbcli update-schedule -i 5678 -d

API verwenden

Informationen zur Verwendung der API und zu Signieranforderungen finden Sie unter REST-APIs und Sicherheitszugangsdaten. Informationen zu SDKs finden Sie unter Software Development Kits und Befehlszeilenschnittstelle (CLI).

Mit den folgenden API-Vorgängen können Sie Datenbankbackups verwalten:

• ListBackups
• GetBackup
• CreateBackup
• DeleteBackup
• RestoreDatabase
• UpdateDatabase- Automatische Backups aktivieren und deaktivieren.
• CreateDbHome: Zum Erstellen einer DB-Systemdatenbank aus einem Standalone-Backup.

Die vollständige Liste der APIs für den Database-Service finden Sie unter Database-Service-API.