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. Das Feature für automatische Backups unterstützt Recovery Service und Object Storage als Backupziel, sodass Sie eine vollständig automatisierte Cloud-Backuplösung mit denselben 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 On-Premises-Technologie Zero Data Loss Recovery Appliance von Oracle basiert und modernen Cybersicherheitsschutz für Oracle Databases bietet. Einzigartige, automatisierte Funktionen schützen Oracle Database-Änderungen in Echtzeit, validieren Backups ohne Produktionsdatenbank-Overhead 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 denselben 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 zuvor mit RMAN oder dbcli konfiguriert haben und dann die Konsole oder API für Backups verwenden, 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:

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

Erforderliche IAM-Policy

Um Oracle Cloud Infrastructure verwenden zu können, muss ein Administrator Ihnen Sicherheitszugriff in einer Policy erteilen. 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 erteilt 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.

Verwandte Themen

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 der Datenbank und des DB-Systems muss "Verfügbar" lauten, damit ein Backupvorgang erfolgreich ausgeführt werden kann. 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 sein. 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 der von Oracle empfohlenen Vorgehensweise zur Verwendung von SYSBACKUP-Administratorberechtigungen für Backup- und Recovery-Vorgänge zu entsprechen, erstellt die Cloud-Automatisierung einen allgemeinen Benutzer namens C##DBLCMUSER mit der Rolle SYSBACKUP auf der CDB$ROOT-Containerebene. Backup- und Recovery-Vorgä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, erstellt oder entsperrt die Cloud-Automatisierung diesen Benutzer während der Backup- oder Recovery-Vorgänge.

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 der Ebene 0 in der Liste der Backups mit dem Backuptyp "Inkrementell" angezeigt werden, ebenso wie tägliche Backups der 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 Long-Term Retention Backup (LTR) können Sie vollständige Backups für einen Zeitraum von bis zu zehn Jahren für Compliance-, regulatorische 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 Recovery Service kein neues vollständiges Produktionsbackup erstellen, sondern bereits vorhandene operative Backups im System innerhalb des definierten Recovery-Fensters in der Policy verwenden. 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 langfristigen Aufbewahrungsbackups 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 aus einem Backup erstellen.

Nach Beendigung des DB-Systems werden die LTR-Backups gemäß dem Wert "Löschoptionen nach Beendigung der Datenbank" gelöscht.
  • Backups in 72 Stunden löschen: Alle Backups, einschließlich LTR-Backups, werden gelöscht.
  • Auf Policy-Basis löschen: LTR-Backups werden gemäß der Aufbewahrungs-Policy jedes LTR-Backups beibehalten.

Hinweis:

Oracle empfiehlt, beim Beenden eines DB-Systems die Option "Auf Policy basierender 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 bleiben unabhängig von automatischen Backups bestehen, 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 des LTR verwaltet.
  • Sie können einen LTR stornieren, wenn er sich im Status "Erstellen" befindet.
  • Sie können ein LTR-Backup jederzeit löschen, nachdem es erstellt wurde.
  • Wenn das wiederherzustellende LTR-Backup während der Wiederherstellung eine unterstützte Hauptversion des DB-Homes ist, wird es auf die neueste RU dieser Version wiederhergestellt.
  • Wenn das wiederherzustellende LTR-Backup während der Wiederherstellung keine unterstützte Hauptversion des DB-Homes ist, wird es in einer der unterstützten Hauptversionen wiederhergestellt, bei denen die Datenbank auf eine der unterstützten Hauptversionen upgegradet werden muss.

Restore-Optionen

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

  • Im letzten Status wiederherstellen : Stellt die Datenbank im letzten bekannten fehlerfreien Zustand mit dem geringstmöglichen Datenverlust wieder her.
  • Mit einem Zeitstempel wiederherstellen:: Stellt die Datenbank mit dem angegebenen Zeitstempel wieder her.

  • Mit SCN wiederherstellen:: Stellt die Datenbank mit der angegebenen Systemänderungsnummer (SCN) wieder her. Diese SCN muss gültig sein.

    Hinweis:

    Sie können die zu verwendende SCN bestimmen, indem Sie entweder den Datenbankhost abfragen oder Online- oder archivierte Logs aufrufen.

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 Recovery Service und Object Storage als 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 und allen ihren Ressourcen verknüpft sind, am Ende des angegebenen Aufbewahrungszeitraums entfernt.
  • Backups 72 Stunden lang aufbewahren, dann löschen: Wenn eine Datenbank beendet wird, werden die automatischen Datenbankbackups, die mit der beendeten Datenbank verknüpft sind, und alle ihre Ressourcen 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 Backupfenster: Automatische Backups, die erstmalig nach dem 20. November 2018 für eine Datenbank aktiviert wurden, werden zwischen Mitternacht und 06:00 Uhr morgens in der Zeitzone der DB-Systemregion ausgeführt. Wenn Sie vor diesem Datum automatische Backups für eine Datenbank aktiviert haben, liegt das Backupfenster für die Datenbank weiterhin zwischen Mitternacht und 6:00 Uhr morgens 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 wieder automatische Backups für die Datenbank konfigurieren, die in der Data Guard-Verknüpfung die primäre Rolle übernommen hat.
  • Änderungen des Aufbewahrungszeitraums: Wenn Sie den Aufbewahrungszeitraum für automatische Backups der Datenbank zu einem späteren Zeitpunkt verkürzen, werden vorhandene Backups, die außerhalb des aktualisierten Aufbewahrungszeitraums liegen, vom System gelöscht.
  • Object Storage-Kosten: Für automatische Backups fallen Object Storage-Nutzungskosten 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 aus einer Standbydatenbank in einer Data Guard-Assoziation

Sie können ein Backup und eine Wiederherstellung aus einer Standbydatenbank in einer Data Guard-Verbindung erstellen. Mit diesem Feature können Sie Backups in die Standbydatenbank auslagern und so Ressourcen in der Primärdatenbank freigeben.

Beachten Sie Folgendes, bevor Sie beginnen:

  • Mit Recovery Service oder Object Storage können Sie die Standbydatenbanken sichern.
  • 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 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 die Primär- und die Standbydatenbank jedoch dasselbe Backupziel aufweisen.
  • Bei Backups im Recovery Service kann die Primärdatenbank aus den Backups der Standbydatenbank oder der Primärdatenbank zurückgeschrieben oder wiederhergestellt werden. In ähnlicher Weise kann die Standby-Datenbank aus den Backups der Primär- oder der Standby-Datenbank zurückgeschrieben oder wiederhergestellt werden.
  • Bei Backups im Object Storage können die Primärdatenbank und die Standbydatenbank nur aus den jeweiligen Backups wiederhergestellt oder wiederhergestellt werden.
  • Das Backupziel der Primär- und der Standbydatenbank in einer Data Guard-Assoziation 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 Standbydatenbank Recovery Service ist, muss das Backupziel der Primärdatenbank ebenfalls 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 sowohl der Primär- als auch der Standby-Datenbank Object Storage ist und Sie das Backupziel der Primärdatenbank in Recovery Service ändern möchten, müssen Sie zuerst das Backup auf der Standby-Datenbank deaktivieren.
  • Wenn das automatische Backup auf der Primärdatenbank konfiguriert wurde, werden die Backups beim 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 wiederherstellen, um eine Datenbank (Out-of-Place-Wiederherstellung) über Availability-Domains innerhalb derselben Region oder in einer anderen Region hinweg mit einem Backup zu erstellen, das mit Object Storage oder Autonomous Recovery Service erstellt wurde.

Sie können auch ein Backup wiederherstellen, das in einer Datenbank erstellt wurde, die mit hostbasierten Wallets (lokalen Wallets) oder OCI Vault konfiguriert wurde. 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: Die VCNs in lokalen und Remote-Regionen 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 Sicherheitsregeln zu verwalten.

      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 Sicherheitsregeln zu verwalten.

      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 Sicherheitsregeln zu verwalten.

      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 Sicherheitsregeln zu verwalten.
    2. Fügen Sie Egress-Regeln zum 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 Sicherheitsregeln zu verwalten.

      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 Sicherheitsregeln zu verwalten.

    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 Erstellen eines Recovery Service-Subnetzes im Datenbank-VCN.
  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.