Sauvegarde et récupération dans Base Database Service

La sauvegarde de votre base de données est essentielle pour assurer la sécurité de vos données. Oracle propose plusieurs méthodes de sauvegarde de base de données.

La fonctionnalité de sauvegarde automatique gérée par Oracle est la méthode à privilégier pour sauvegarder les bases de données Oracle Cloud car vous pouvez configurer facilement les paramètres de sauvegarde à l'aide de la console. La fonctionnalité de sauvegarde automatique prend en charge Recovery Service et Object Storage en tant que destination de sauvegarde pour vous fournir une solution de sauvegarde cloud entièrement automatisée au même coût. Vous n'avez pas besoin d'effectuer de sauvegardes manuelles ni de tâches d'administration de stockage de sauvegarde. Vous pouvez également stocker des sauvegardes dans un stockage local. Chaque destination de sauvegarde présente des avantages et des exigences que vous devez prendre en compte, comme indiqué ci-dessous.

Recovery Service (recommandé)

Service entièrement géré basé sur la technologie Zero Data Loss Recovery Appliance d'Oracle sur site qui offre une protection moderne de la cybersécurité pour les bases de données Oracle. Des fonctionnalités uniques et automatisées protègent les modifications d'Oracle Database en temps réel, valident les sauvegardes sans surcharge de base de données de production et permettent une récupération rapide et prévisible à tout moment.

Si vos sauvegardes sont actuellement configurées avec Object Storage, vous pouvez passer en toute transparence à Recovery Service afin d'atteindre des fonctionnalités avancées avec le même coût.

Pour plus d'informations sur Recovery Service, reportez-vous à A propos d'Oracle Database Autonomous Recovery Service.

Stockage d'objet

Une solution de stockage à la demande sécurisée et évolutive pour les bases de données.

Pour plus d'informations sur Object Storage, reportez-vous à Présentation d'Object Storage.

Stockage local

  • Les sauvegardes sont stockées localement dans la zone de récupération rapide du système de base de données.
  • Durabilité : faible
  • Disponibilité : moyenne
  • Taux de sauvegarde et de récupération : élevé
  • Avantages : sauvegarde optimisée et récupération rapide à un point dans le temps.
  • Inconvénients : si le système de base de données devient indisponible, la sauvegarde l'est également.

Actuellement, Oracle ne permet pas d'attacher des volumes de stockage de blocs à un système de base de données. Vous ne pouvez donc pas effectuer de sauvegarde dans les volumes attachés au réseau.

Pour les sauvegardes non gérées, vous pouvez utiliser RMAN ou dbcli, et vous devez créer et gérer vos propres buckets Object Storage pour les sauvegardes.

Remarques :

Si vous avez précédemment utilisé RMAN ou dbcli afin de configurer des sauvegardes, puis que vous basculez sur l'utilisation de la console ou de l'API pour les sauvegardes, une configuration de sauvegarde est créée et associée à la base de données. Par conséquent, vous ne pouvez plus utiliser vos sauvegardes non gérées configurées précédemment pour travailler.

Pour obtenir des instructions détaillées sur la création de sauvegardes, reportez-vous aux sections suivantes :

Pour plus d'informations sur la récupération à partir de sauvegardes, reportez-vous aux sections suivantes :

Stratégie IAM requise

Pour utiliser Oracle Cloud Infrastructure, un administrateur doit vous accorder un accès sécurisé dans une stratégie. Cet accès est requis, que vous utilisiez la console ou l'API REST avec un kit SDK, une interface de ligne de commande ou un autre outil. Si un message vous indique que vous ne disposez pas des droits d'accès ou des autorisations nécessaires, vérifiez auprès de l'administrateur le type d'accès qui vous a été accordé et le compartiment dans lequel vous devez travailler.

Si vous ne connaissez pas les stratégies, reportez-vous à Introduction aux stratégies et à Stratégies courantes.

Rubriques connexes

Prérequis

Examinez les prérequis suivants et assurez-vous qu'ils sont respectés pour l'opération de sauvegarde et de récupération :

Recovery Service

Pour plus d'informations sur les prérequis de Recovery Service, reportez-vous à Configuration de Recovery Service.

Stockage d'objet

  • Le système de base de données requiert l'accès à Object Storage, ce qui inclut la connectivité à l'adresse Swift applicable. Oracle recommande d'utiliser une passerelle de service avec le réseau cloud virtuel pour activer cet accès. Reportez-vous à Réseau cloud virtuel et sous-réseaux.
  • Un bucket Object Storage existant à utiliser comme destination de sauvegarde. Vous pouvez utiliser la console ou l'API Object Storage pour créer le bucket. Reportez-vous à Gestion des buckets.
  • Un jeton d'authentification généré par OCI. Vous pouvez utiliser la console ou l'API IAM pour générer le mot de passe. Reportez-vous à Gestion des informations d'identification utilisateur.

  • Le nom utilisateur indiqué dans le fichier de configuration de sauvegarde doit disposer d'un accès à Object Storage au niveau de la location. Pour ce faire, vous pouvez simplement ajouter le nom utilisateur au groupe d'administrateurs. Toutefois, cette opération donne accès à l'ensemble des services cloud. Il est préférable qu'un administrateur crée une stratégie semblable à la suivante, qui limite l'accès aux seules ressources d'Object Storage requises afin de sauvegarder et de restaurer la base de données :

    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>

    Pour plus d'informations sur l'ajout d'un utilisateur à un groupe, reportez-vous à Gestion des groupes.

Pour plus d'informations sur Object Storage, reportez-vous à Présentation d'Object Storage.

Informations générales

La base de données et le système de base de données doivent avoir l'état Disponible pour qu'une opération de sauvegarde puisse être exécutée. Oracle recommande d'éviter d'effectuer des actions susceptibles d'interférer avec la disponibilité (comme l'application de patches et les opérations Data Guard) pendant une opération de sauvegarde. En cas d'échec d'une opération de sauvegarde automatique, le service Database retente l'opération au cours de la fenêtre de sauvegarde du jour suivant. En cas d'échec d'une sauvegarde complète à la demande, vous pouvez réessayer l'opération lorsque la disponibilité du système et de la base de données est restaurée.

En plus des prérequis répertoriés, assurez-vous que les conditions suivantes sont remplies pour éviter les échecs de sauvegarde :

  • Le mode d'archivage de la base de données est défini sur ARCHIVELOG (valeur par défaut).
  • Le répertoire /u01 du système de fichiers hôte de la base de données dispose de suffisamment d'espace libre pour l'exécution des processus de sauvegarde.
  • Le fichier .bash_profile de l'utilisateur oracle n'inclut aucune commande interactive (comme oraenv ou une commande susceptible de générer un message d'erreur ou d'avertissement).
  • (Pour les sauvegardes automatiques) Aucune modification n'a été apportée à l'entrée WALLET_LOCATION par défaut dans le fichier sqlnet.ora.
  • Aucune modification n'a été apportée aux paramètres de sauvegarde RMAN à l'aide des commandes RMAN standard.

Pour plus d'informations sur les problèmes que peut engendrer le non-respect de ces instructions, reportez-vous à Dépannage des échecs de sauvegarde.

Fonctionnalités de sauvegarde gérée

Les informations suivantes s'appliquent aux sauvegardes gérées configurées à l'aide de l'API ou de la console.

Remarques :

Les sauvegardes automatiques doivent être activées pour les bases de données d'un compartiment de zone de sécurité. Pour obtenir la liste complète des stratégies ayant une incidence sur les ressources Base Database Service, reportez-vous à Stratégies de zone de sécurité.

Actuellement, les deux types de sauvegarde automatique suivants sont pris en charge :

  • Recovery Service : solution de sauvegarde centralisée, entièrement gérée et autonome pour les bases de données.
  • Object Storage : solution de stockage à la demande sécurisée et évolutive pour les bases de données.

Afin d'être en adéquation avec la pratique recommandée par Oracle qui consiste à utiliser les privilèges d'administration SYSBACKUP pour les opérations de sauvegarde et de récupération, l'automatisation du cloud crée un utilisateur d'administration commun nommé C##DBLCMUSER avec le rôle SYSBACKUP au niveau du conteneur CDB$ROOT. Les opérations de sauvegarde et de récupération sont donc exécutées avec l'utilisateur doté des moindres privilèges requis. Les informations d'identification de cet utilisateur sont générées de manière aléatoire et gérées en toute sécurité par l'automatisation du cloud. Si l'utilisateur est introuvable ou s'il est à l'état LOCKED et EXPIRED, l'automatisation du cloud recrée ou déverrouille cet utilisateur lors des opérations de sauvegarde ou de récupération.

Sauvegardes incrémentielles automatiques et sauvegardes de fichiers de journalisation archivés

Lorsque vous activez la fonctionnalité de sauvegarde Object Storage pour une base de données, le service crée les éléments suivants en continu :

  • Sauvegarde hebdomadaire de niveau 0, généralement créée un jour de week-end donné. Une sauvegarde de niveau 0 est l'équivalent d'une sauvegarde complète. Dans la console, les sauvegardes hebdomadaires de niveau 0 apparaissent dans la liste des sauvegardes "incrémentielles", tout comme les sauvegardes quotidiennes de niveau 1.
  • Sauvegardes quotidiennes de niveau 1, à savoir des sauvegardes incrémentielles créées quotidiennement pendant les six jours qui suivent la date de la sauvegarde de niveau 0.
  • Les sauvegardes de niveau 0 et de niveau 1 sont stockées dans la banque d'objets. Un OCID leur est affecté.
  • Sauvegardes des fichiers de journalisation archivés en cours (fréquence minimale : toutes les 60 minutes). Le champ Heure de la dernière sauvegarde de la page de détails de la base de données dans la console OCI affiche l'heure des derniers fichiers de journalisation archivés. Cette sauvegarde diffère des sauvegardes automatiques de niveau 0 et 1 car elle est basée sur des données de journal et aucun OCID ne lui est affecté. La dernière sauvegarde de fichiers de journalisation archivés peut être utilisée pour créer une base de données ou pour récupérer une base de données avec une perte de données minimale.

Conservation de sauvegarde

Si vous choisissez d'activer les sauvegardes automatiques, vous pouvez sélectionner l'une des périodes de conservation fournies ou une stratégie personnalisée. Le système supprime automatiquement les sauvegardes incrémentielles à la fin de la période de conservation choisie.

Les périodes de conservation suivantes sont disponibles pour Recovery Service. Les périodes de conservation (en jours) sont définies dans la stratégie de protection Recovery Service.
  • Bronze (14 jours)
  • Argent (35 jours) (valeur par défaut)
  • Or (65 jours)
  • Platine (95 jours)
  • Personnalisée (stratégie de protection définie par l'utilisateur)
Les périodes de conservation suivantes sont disponibles pour Object Storage.
  • 7 jours
  • 15 jours
  • 30 jours (valeur par défaut)
  • 45 jours
  • 60 jours

Sauvegarde de conservation à long terme avec Recovery Service

La sauvegarde de rétention à long terme (LTR) vous permet de stocker des sauvegardes complètes pendant des périodes allant jusqu'à dix ans pour répondre à des besoins de conformité, réglementaires ou autres, avec une gestion complète du cycle de vie LTR et une immuabilité.

Pour LTR avec Recovery Service, la période de conservation doit être exprimée en jours (90 - 3650) ou en années (1 - 10) à compter de la création de la sauvegarde.

Pour créer une sauvegarde LTR avec la période de conservation requise, Recovery Service ne nécessite pas de créer une sauvegarde de production complète, mais utilise des sauvegardes opérationnelles existantes dans le système dans la fenêtre de récupération définie de la stratégie. Pour obtenir les étapes détaillées, reportez-vous à Création d'une sauvegarde à la demande d'une base de données.

Vous pouvez modifier la période de conservation d'une sauvegarde LTR existante spécifique au cours de la période de conservation. Pour obtenir des étapes détaillées, reportez-vous à Modification de la période de conservation d'une sauvegarde de conservation à long terme avec Recovery Service.

Vous pouvez restaurer une sauvegarde LTR pour créer une base de données au cours de la période de conservation. Pour obtenir les étapes détaillées, reportez-vous à Création d'un système de base de données à partir d'une sauvegarde à l'aide de la console.

Lors de la terminaison du système de base de données, les sauvegardes LTR sont supprimées conformément à la valeur "Options de suppression après la terminaison de la base de données".
  • Supprimer les sauvegardes dans les 72 heures : toutes les sauvegardes, y compris les sauvegardes LTR, seront supprimées.
  • Supprimer en fonction de la stratégie : les sauvegardes LTR sont conservées en fonction de la stratégie de conservation de chaque sauvegarde LTR.

Remarques :

Oracle recommande de choisir l'option Supprimer en fonction de la stratégie lors de la terminaison d'un système de base de données pour s'assurer que les sauvegardes de durée de conservation sont conservées.

Tenez compte des facteurs supplémentaires suivants pour les sauvegardes LTR :

  • Les sauvegardes LTR continueront d'exister indépendamment des sauvegardes automatiques configurées sur la base de données.
  • Les sauvegardes LTR seront automatiquement supprimées une fois la période de conservation indiquée terminée.
  • La restauration sur place n'est pas prise en charge pour la fonction LTR.
  • Pour les bases de données d'une configuration Data Guard, la sauvegarde LTR est créée uniquement pour la base de données dans laquelle elle est demandée.
  • La base de données doit avoir l'état DISPONIBLE pour créer une relation LTR.
  • La fonction LTR est prise en charge pour les bases de données avec des fichiers de clés TDE ou KMS basés sur des fichiers.
  • Toutes les clés de cryptage sont conservées pendant toute la période de conservation de la durée de conservation de la durée de conservation.
  • Vous pouvez annuler un LTR s'il est à l'état "créateur".
  • Vous pouvez supprimer une sauvegarde LTR à tout moment après sa création.
  • Pendant la restauration, si la sauvegarde LTR en cours de restauration est une version majeure du répertoire de base de base de données prise en charge, elle sera restaurée vers la dernière RU de cette version.
  • Lors de la restauration, si la sauvegarde LTR en cours de restauration n'est pas une version majeure du répertoire de base de base de données prise en charge, elle sera restaurée vers l'une des versions majeures prises en charge, sur lesquelles la base de données doit être mise à niveau vers l'une des versions majeures prises en charge.

Options de restauration

Les options de restauration suivantes sont disponibles pour la base de données. Cela n'est pas pris en charge pour la durée de vie.

  • Restaurer la dernière version : restaure la base de données telle qu'au dernier état correct connu, avec la perte de données la plus limitée possible.
  • Restaurer vers un horodatage : restaure la base de données telle qu'à l'horodatage spécifié.

  • Restaurer vers le SCN : restaure la base de données à l'aide du numéro SCN spécifié. Ce numéro SCN doit être valide.

    Remarques :

    Pour déterminer le numéro SCN à utiliser, vous pouvez accéder à l'hôte de base de données et l'interroger, ou accéder à des journaux en ligne ou archivés.

Stratégies de protection

Recovery Service recourt aux stratégies de protection pour contrôler la conservation des sauvegardes de base de données dans Oracle Cloud.

Les stratégies de protection assurent une gestion automatisée de la conservation des bases de données protégées, répondant aux exigences des environnements réglementés. Chaque base de données protégée doit être associée à une stratégie de protection.

La stratégie de protection détermine la période maximale (en jours) autorisée de conservation des sauvegardes créées par Recovery Service. En fonction de vos exigences métier, vous pouvez affecter des stratégies distinctes pour chaque base de données protégée ou utiliser une stratégie unique pour toutes les bases de données protégées dans un réseau cloud virtuel.

Pour plus d'informations, reportez-vous à Gestion des stratégies de protection.

Bases de données protégées

Une base de données protégée fait référence à une base de données Oracle Cloud qui utilise Recovery Service pour les opérations de sauvegarde.

Pour plus d'informations, reportez-vous à Gestion des bases de données protégées.

Protection de données en temps réel

Recovery Service offre une protection des données en temps réel afin que vous puissiez récupérer une base de données en moins d'une seconde après un échec de base de données.

La protection en temps réel est le transfert continu des modifications de journalisation d'une base de données protégée vers Recovery Service. Cela réduit la perte de données et fournit un objectif de point de récupération proche de 0. Cette option entraîne un coût supplémentaire.

Pour plus d'informations, reportez-vous à Protection de données en temps réel.

Options de suppression de sauvegarde après la terminaison d'une base de données

Lorsque vous mettez fin à une base de données, toutes ses ressources et toutes les sauvegardes automatiques sont supprimées. Les sauvegardes gérées à l'aide des destinations Recovery Service et Object Storage sont supprimées en fonction des options de stratégie de conservation sélectionnées.

Vous pouvez utiliser les options suivantes pour conserver les sauvegardes de base de données gérées après la terminaison d'une base de données. Ces options peuvent également contribuer à restaurer la base de données à partir de sauvegardes en cas de dommage accidentel ou malveillant de la base de données.

  • Conserver les sauvegardes en fonction de la période de conservation : en cas de terminaison d'une base de données, les sauvegardes automatiques associées à cette base de données et à toutes ses ressources sont enlevées à la fin de la période de conservation indiquée.
  • Conserver les sauvegardes pendant 72 heures, puis supprimer : en cas de terminaison d'une base de données, les sauvegardes automatiques associées à cette base de données et à toutes ses ressources sont conservées pendant 72 heures, puis supprimées. Les sauvegardes sont conservées pendant 72 heures afin d'éviter toute suppression accidentelle par l'utilisateur.

Programmation de sauvegarde

Pour les sauvegardes Recovery Service, le processus de sauvegarde automatique démarre à tout moment ou dans la fenêtre affectée.

Pour les sauvegardes Object Storage, le processus de sauvegarde automatique utilisé afin de créer des sauvegardes de niveau 0 et 1 peut être exécuté à tout moment dans la fenêtre de sauvegarde quotidienne (entre minuit et 6 h 00). Vous pouvez éventuellement indiquer une fenêtre de programmation de 2 heures pour la base de données, au cours de laquelle le processus de sauvegarde automatique démarrera. Vous pouvez choisir parmi 12 fenêtres de programmation, chacune commençant par une heure paire (par exemple, une fenêtre va de 04 h 00 à 06 h 00 et la suivante va de 06 h 00 à 08 h 00). Les travaux de sauvegarde ne se terminent pas forcément pendant la fenêtre de programmation.

Pour les sauvegardes Object Storage, si vous ne spécifiez pas de fenêtre, la fenêtre de sauvegarde par défaut allant de 00 h 00 à 06 h 00 dans le fuseau horaire de la région du système de base de données est affectée à la base de données. La fenêtre de programmation de sauvegarde par défaut est de six heures. Les fenêtres que vous indiquez sont quant à elles de deux heures.

Tenez compte des facteurs suivants lors de la programmation des sauvegardes.

  • Fuseau horaire de la fenêtre de sauvegarde : les sauvegardes automatiques activées pour une base de données pour la première fois après le 20 novembre 2018 sont exécutées entre minuit et 06 h 00 dans le fuseau horaire de la région du système de base de données. Si vous avez activé des sauvegardes automatiques pour une base de données avant cette date, la fenêtre de sauvegarde de la base de données continue d'être entre 00 h 00 et 06 h 00 UTC. Pour que vos sauvegardes automatiques soient exécutées dans une fenêtre de sauvegarde de votre choix, vous pouvez créer une demande de service My Oracle Support en ce sens.
  • Data Guard : dans une association Data Guard, vous pouvez configurer des sauvegardes automatiques et créer des sauvegardes de la base de données principale. Toutefois, vous ne pouvez pas configurer de sauvegardes automatiques ni créer de sauvegardes de la base de données de secours. En outre, après une opération de permutation, vous devez à nouveau configurer des sauvegardes automatiques pour la base de données qui a pris le rôle principal dans l'association Data Guard.
  • Modifications de la période de conservation : si vous raccourcissez la période de conservation des sauvegardes automatiques de votre base de données ultérieurement, les sauvegardes existantes effectuées en dehors de la période de conservation mise à jour sont supprimées par le système.
  • Coûts associés à Object Storage : les sauvegardes automatiques impliquent des coûts d'utilisation d'Object Storage.

Sauvegardes complètes à la demande

Vous pouvez créer une sauvegarde complète de la base de données à tout moment, sauf si cette dernière assume le rôle de base de données de secours dans une association Data Guard.

Sauvegardes autonomes

Lorsque vous mettez fin à un système de base de données ou à une base de données, toutes ses ressources sont supprimées, ainsi que toutes les sauvegardes automatiques. Les sauvegardes gérées à l'aide des destinations Recovery Service et Object Storage sont supprimées en fonction des options de stratégie de conservation sélectionnées. Les sauvegardes complètes sont conservées dans Object Storage en tant que sauvegardes autonomes. Vous pouvez utiliser une sauvegarde autonome pour créer une base de données.

Remarques :

  • La liste de sauvegardes que vous voyez dans la console ne contient aucune sauvegarde non gérée (sauvegardes créées directement à l'aide de RMAN ou dbcli).
  • Toutes les sauvegardes sont cryptées à l'aide de la même clé maître que celle utilisée pour le cryptage du portefeuille de cryptage transparent des données.

Annulation d'une sauvegarde complète ou incrémentielle en cours d'exécution

Vous pouvez annuler une sauvegarde en cours, ce qui vous permet de libérer des ressources système. Dans le cadre du workflow de création de base de données ou indépendamment (une fois la base de données créée), vous pouvez activer la sauvegarde automatique et sélectionner la destination de sauvegarde souhaitée. Selon la destination de sauvegarde choisie, vous pouvez avoir des sauvegardes complètes et plusieurs sauvegardes incrémentielles. Une fois que l'une de ces sauvegardes a démarré, vous avez la possibilité de l'annuler à mi-parcours. Vous pouvez annuler une sauvegarde en cours d'exécution (automatique ou autonome) à partir de la console ou de l'API. Vous pouvez annuler une sauvegarde manuelle déclenchée lorsque vous cliquez sur le bouton Créer une sauvegarde. Vous pouvez également supprimer une sauvegarde manuelle annulée.

Sauvegarde et restauration à partir d'une base de données de secours dans une association Data Guard

Vous pouvez sauvegarder et restaurer à partir d'une base de données de secours dans une association Data Guard. Grâce à cette fonctionnalité, vous pouvez décharger des sauvegardes vers la base de données de secours, libérant ainsi des ressources dans la base de données principale.

Avant de commencer, prenez en considération les éléments suivants :

  • Vous pouvez utiliser Recovery Service ou Object Storage pour sauvegarder les bases de données de secours.
  • Vous pouvez planifier des sauvegardes automatiques et configurer des périodes de conservation et des planifications de sauvegarde sur la base de données de secours.
  • Vous pouvez créer une base de données dans un autre domaine de disponibilité de la même région ou d'une autre région à partir d'une sauvegarde de la base de données de secours.
  • Les sauvegardes peuvent être configurées uniquement sur la base de données principale, sur la base de données de secours uniquement ou sur les bases de données principale et de secours. Toutefois, lorsqu'elles sont configurées, les bases de données principale et de secours doivent avoir la même destination de sauvegarde.
  • Pour les sauvegardes dans Recovery Service, la base de données principale peut être restaurée ou récupérée à partir des sauvegardes de la base de données de secours ou de la base de données principale. De même, la base de données de secours peut être restaurée ou récupérée à partir des sauvegardes de la base de données principale ou de la base de données de secours.
  • Pour les sauvegardes dans Object Storage, la base de données principale et la base de données de secours peuvent uniquement être restaurées ou récupérées à partir de leurs sauvegardes respectives.
  • La destination de sauvegarde de la base de données principale et de la base de données de secours dans une association Data Guard doit être la même. Par exemple, si la destination de sauvegarde de la base de données principale est Recovery Service, la destination de sauvegarde de la base de données de secours doit également être Recovery Service. De même, si la destination de sauvegarde de la base de données de secours est Recovery Service, la destination de sauvegarde de la base de données principale doit également être Recovery Service.
  • La destination de sauvegarde ne peut être modifiée qu'après la désactivation de la sauvegarde sur la base de données principale ou de secours dans une association Data Guard. Par exemple, si la destination de sauvegarde des bases de données principale et de secours est Object Storage et que vous voulez modifier la destination de sauvegarde de la base de données principale vers Recovery Service, vous devez d'abord désactiver la sauvegarde sur la base de données de secours.
  • Si la sauvegarde automatique était configurée sur la base principale, lors de la permutation, les sauvegardes se poursuivraient sur la nouvelle base de données de secours.
  • Si la sauvegarde automatique a été configurée sur la base de données de secours, lors du basculement, les sauvegardes se poursuivent sur la nouvelle base de données principale et les sauvegardes sont désactivées sur la nouvelle base de données de secours.

Pour plus d'informations sur les étapes de configuration des sauvegardes automatiques à l'aide de la console, reportez-vous à Configuration de sauvegardes automatiques pour une base de données de secours.

Restauration inter-régions

Vous pouvez utiliser une sauvegarde existante et la restaurer pour créer une base de données (restauration sans réutilisation de la mémoire) dans les domaines de disponibilité de la même région ou d'une autre région à l'aide d'une sauvegarde créée avec Object Storage ou Autonomous Recovery Service.

Vous pouvez également restaurer une sauvegarde effectuée sur une base de données configurée à l'aide de portefeuilles basés sur l'hôte (wallets locaux) ou d'OCI Vault. Pour plus d'informations sur les clés de cryptage de base de données, reportez-vous à Gestion des clés de cryptage.

Les prérequis suivants sont requis pour la restauration inter-région (dans la même location) pour Oracle Database Autonomous Recovery Service.

  1. Appairage VCN : les réseaux cloud virtuels des régions locales et distantes doivent tous deux être appairés d'une région à l'autre.

  2. Ajoutez des règles de sécurité sur les réseaux cloud virtuels source et cible.

    1. Ajoutez des règles entrantes sur la source.

      1. Cliquez sur Ajouter une règle entrante et ajoutez les détails suivants pour configurer une règle autorisant le trafic HTTPS de n'importe où :

        • Type de source : CIDR
        • CIDR source : indiquez le CIDR du VCN dans lequel réside la base de données.
        • Protocole IP : TCP
        • Plage de ports source : Tout
        • Plage de ports de destination :8005
        • Description : indiquez une description facultative de la règle entrante pour faciliter la gestion des règles de sécurité.

      2. Cliquez sur Ajouter une règle entrante et ajoutez les détails suivants pour configurer une règle autorisant le trafic SQLNet de n'importe où :

        • Type de source : CIDR
        • CIDR source : indiquez le CIDR du VCN dans lequel réside la base de données.
        • Protocole IP : TCP
        • Plage de ports source : Tout
        • Plage de ports de destination :2484
        • Description : indiquez une description facultative de la règle entrante pour faciliter la gestion des règles de sécurité.

      3. Cliquez sur Ajouter une règle entrante et ajoutez les détails suivants pour configurer une règle autorisant le trafic HTTPS de n'importe où :

        • Type de source : CIDR
        • CIDR source : indiquez le CIDR du VCN cible.
        • Protocole IP : TCP
        • Plage de ports source : Tout
        • Plage de ports de destination :8005
        • Description : indiquez une description facultative de la règle entrante pour faciliter la gestion des règles de sécurité.

      4. Cliquez sur Ajouter une règle entrante et ajoutez les détails suivants pour configurer une règle autorisant le trafic SQLNet de n'importe où :

        • Type de source : CIDR
        • CIDR source : indiquez le CIDR du VCN cible.
        • Protocole IP : TCP
        • Plage de ports source : Tout
        • Plage de ports de destination :2484
        • Description : indiquez une description facultative de la règle entrante pour faciliter la gestion des règles de sécurité.
    2. Ajoutez des règles sortantes sur la cible. Ces options sont facultatives si le trafic sortant est ouvert pour toutes les adresses IP et tous les ports.

      1. Cliquez sur Ajouter une règle sortante et ajoutez les détails suivants pour configurer une règle autorisant le trafic HTTPS de n'importe où :

        • Type de source : CIDR
        • CIDR source : indiquez le CIDR du VCN source.
        • Protocole IP : TCP
        • Plage de ports source : Tout
        • Plage de ports de destination :8005
        • Description : indiquez une description facultative de la règle entrante pour faciliter la gestion des règles de sécurité.

      2. Cliquez sur Ajouter une règle sortante et ajoutez les détails suivants pour configurer une règle autorisant le trafic SQLNet de n'importe où :

        • Type de source : CIDR
        • CIDR source : indiquez le CIDR du VCN source.
        • Protocole IP : TCP
        • Plage de ports source : Tout
        • Plage de ports de destination :2484
        • Description : indiquez une description facultative de la règle entrante pour faciliter la gestion des règles de sécurité.

    Remarques :

    Assurez-vous que le sous-réseau Recovery Service est présent dans la région source et est attaché au VCN source. Pour plus d'informations, reportez-vous à Création d'un sous-réseau de service de récupération dans le VCN de base de données.
  3. Appairage DNS entre des réseaux cloud virtuels locaux et distants.

Conservation des fichiers d'audit et des fichiers trace pour les bases de données utilisant les sauvegardes automatiques

Oracle Database écrit les fichiers d'audit et les fichiers trace dans le stockage local de votre base de données dans le répertoire /u01. Ces fichiers sont conservés pendant 30 jours par défaut, mais vous pouvez modifier cet intervalle. Une fois par jour, les fichiers d'audit et les fichiers trace de plus de 30 jours (ou excédant l'intervalle spécifié par l'utilisateur, le cas échéant) sont rejetés par un travail Oracle Scheduler. Vous pouvez également désactiver le travail Scheduler pour conserver indéfiniment ces fichiers. Utilisez les commandes dbcli suivantes pour apporter des modifications à ce travail Scheduler.

  • Pour définir la période de conservation sur une autre valeur que celle par défaut de 30 jours :

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

    Exemple : 

    dbcli update-database -in inventorydb -lr 15

  • Afin de désactiver le travail Scheduler de rejets quotidiens pour les anciens fichiers d'audit et fichiers trace :

    dbcli update-schedule -i <schedulerID> -d

    Exemple : 

    dbcli update-schedule -i 5678 -d

Utilisation de l'API

Pour plus d'informations sur l'utilisation de l'API et la signature des demandes, reportez-vous à API REST et à Informations d'identification de sécurité. Pour plus d'informations sur les kits SDK, reportez-vous à Kits SDK et interface de ligne de commande.

Utilisez ces opérations d'API pour gérer des sauvegardes de base de données :

  • ListBackups
  • GetBackup
  • CreateBackup
  • DeleteBackup
  • RestoreDatabase
  • UpdateDatabase : permet d'activer et de désactiver les sauvegardes automatiques
  • CreateDbHome : permet de créer une base de données de système de base de données à partir d'une sauvegarde autonome.

Pour obtenir la liste complète des API du service Database, reportez-vous à API du service Database.