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 fonction de sauvegarde automatique prend en charge Recovery Service et Object Storage comme destination de sauvegarde pour vous fournir une solution de sauvegarde cloud entièrement automatisée avec le 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é)

Un 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 la 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 facilement à Recovery Service pour bénéficier de 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.

Object Storage

Solution de stockage à la demandes, sécurisée et évolutive pour les bases.

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.

Remarque : si vous avez précédemment utilisé RMAN ou dbcli afin de configurer des sauvegardes, puis vous basculez avec la console ou l'API pour les sauvegardes, une configuration de sauvegarde est créée et associée à votre 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 :

• Sauvegarde d'une base de données à l'aide de la console
• Sauvegarde d'une base de données vers Object Storage à l'aide de RMAN

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

• Récupération d'une base de données à l'aide de la console
• Récupération d'une base de données à partir d'Object Storage à l'aide d'une sauvegarde RMAN
• Récupération d'une base de données à partir de la banque d'objets OCI Classic

Stratégie IAM requise

Pour utiliser Oracle Cloud Infrastructure, un administrateur doit vous accorder un accès de sécurité 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 vous obtenez un message vous indiquant que vous ne possédez pas de droits d'accès ou des autorisations nécessaires, vérifiez auprès du l'administrateur le type d'accès qui vous avez été octroyé et le compartiment dans lequel vous avez travaillé.

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

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.

Object Storage

• 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. Voir VCN 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

Vous devez avoir l'état Disponible pour qu'une opération de sauvegarde puisse s'exécuter. 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 qui peuvent engendrer un non-respect des instructions, reportez-vous à la section 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.

Remarque : les sauvegardes automatiques doivent être activées pour les bases de données d'un compartiment des zones 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 des données.
• Object Storage : solution de stockage à la demandes, sécurisée et évolutive pour les bases de données.

Afin d'être En adéquation avec la pratique préconisée par Oracle consistant à utiliser les privilèges d'administration SYSBACKUP pour la sauvegarde et la récupération, l'automatisation du cloud crée un utilisateur d'administration commun C##DBLCMUSER avec le rôle SYSBACKUP au niveau de conteneur CDB$ROOT. Ces opérations 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 de niveau 0 hebdomadaires 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 l'ultime sauvegarde sur la page de détails de l'ensemble de bases de données dans la console OCI affiche l'heure du dernier fichier de journalisation archivé. 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 à long terme avec Recovery Service

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

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

Pour créer une sauvegarde LTR avec la période de conservation requise, Recovery Service n'a pas besoin de créer une nouvelle sauvegarde complète de production, mais l'utilise en utilisant 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 des é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 des étapes détaillées, reportez-vous à Création d'un système de base de données à l'aide de la console à partir d'une sauvegarde.

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 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.

Remarque : 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 garantir la conservation des sauvegardes LTR.

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 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 sur laquelle elle est demandée.
• La base de données doit être à l'état AVAILABLE (DISPONIBLE) pour créer un LTR.
• LTR est pris en charge pour les bases de données avec des fichiers de clés d'accès TDE ou KMS basés sur des fichiers.
• Toutes les clés de cryptage seront conservées pendant toute la période de conservation du LTR.
• Vous pouvez annuler un LTR s'il est à l'état "création".
• Vous pouvez supprimer une sauvegarde LTR à tout moment après sa création.
• Lors de 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 version de la RU de cette version.
• Pendant 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 laquelle 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. Cette opération n'est pas prise en charge pour LTR.

• Restaurer la dernière version : restaure la base de données tel qu'au dernier état correctement connu, avec la perte des données la moins limitée possible.
• Restaurer vers un horodatage : restaure la base de données telle qu'à l'horodatage spécifié.
• Restaurer vers un SCN : restaure la base de données à l'aide du numéro SC N spécifié. Ce numéro SCN doit être valide.

Remarque : vous pouvez déterminer le numéro SCN à utiliser en accédant à l'hôte d'une base de données et en l'interrogant ou en accédant à un journal en ligne ou archivé.

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.

Cette protection 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 de la destination 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 la sauvegarde de base de données gérée 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 des sauvegardes en fonction de la période d'attente : en cas d'interruption d'une base de données, les sauvegardes automatiques de base de données associées aux bases de données terminées et à toutes leurs ressources sont enlevées à la fin de la période d'attente 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 fenêtre de sauvegarde : les sauvegardes automatiques activées pour la première fois après le 20 novembre 2018 sur une base de donnée sont exécutées entre minuit et 6 h 00 dans le fuseau horaire de l'environnement du système de base de donnée. 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 minuit et 6 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 durée de conservation : si vous raccourcissez à l'avenir la durée de conservation automatique des sauvegardes de votre base de donnée, les sauvegardes existantes exécutées en dehors de la période d'utilisation mise à jour sont supprimées par le système.
• Coûts liés à Object Storage : les sauvegardes automatiques impliquent un coût 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.

Remarque :

• 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 réserve dans une Association Data Guard

Vous pouvez sauvegarder et restaurer 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 programmer des sauvegardes automatiques et configurer des périodes de conservation et des programmations 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 dans 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 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 identique. Par exemple, si la destination de sauvegarde de la base 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 principales et de secours est Object Storage et que vous souhaitez remplacer la destination de sauvegarde de la base principale par Recovery Service, vous devez d'abord désactiver cette sauvegarde.
• 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 obtenir des étapes détaillées 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égion

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é d'une 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 (au sein de 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 entre les régions.

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

   1. Ajoutez des règles entrantes à 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 où que vous soyez :

         • Type de source : CIDR
         • CIDR source : indiquez le CIDR du VCN où réside la base de données.
         • Protocole IP : TCP
         • Plage de ports d'origine : Tous
         • 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 Add Ingress Rule et ajoutez les détails suivants pour configurer une règle autorisant le trafic SQLNet à partir de n'importe quel emplacement :

         • Type de source : CIDR
         • CIDR source : indiquez le CIDR du VCN où réside la base de données.
         • Protocole IP : TCP
         • Plage de ports d'origine : Tous
         • 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 où que vous soyez :

         • Type de source : CIDR
         • CIDR source : indiquez le CIDR du VCN cible.
         • Protocole IP : TCP
         • Plage de ports d'origine : Tous
         • 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 Add Ingress Rule et ajoutez les détails suivants pour configurer une règle autorisant le trafic SQLNet à partir de n'importe quel emplacement :

         • Type de source : CIDR
         • CIDR source : indiquez le CIDR du VCN cible.
         • Protocole IP : TCP
         • Plage de ports d'origine : Tous
         • 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 qui autorise le trafic HTTPS depuis n'importe où :

         • Type de source : CIDR
         • CIDR source : indiquez le CIDR du VCN source.
         • Protocole IP : TCP
         • Plage de ports d'origine : Tous
         • 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 qui autorise le trafic SQLNet depuis n'importe où :

         • Type de source : CIDR
         • CIDR source : indiquez le CIDR du VCN source.
         • Protocole IP : TCP
         • Plage de ports d'origine : Tous
         • 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é.

      Remarque : assurez-vous que le sous-réseau Recovery Service est présent dans la région source et 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 les 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.