Gestion de la sauvegarde et de la récupération de base de données sur Oracle Exadata Database Service sur une infrastructure Exascale

Découvrez comment utiliser les fonctions de sauvegarde et de récupération fournies par Oracle Exadata Database Service sur une infrastructure Exascale.

Options recommandées par Oracle pour effectuer des opérations de sauvegarde et de récupération

Oracle propose les options suivantes pour les opérations de sauvegarde et de récupération de base de données Oracle. Ces options s'excluent mutuellement.

Remarque

Une configuration hybride, c'est-à-dire mélangeant les options, n'est pas prise en charge. Le mélange des options empêche l'automatisation. A partir du 06 août 2025, pour les locations créées dans les régions FRA, PHX ou NRT, Autonomous Recovery Service sera la seule destination de sauvegarde lorsque vous activerez la sauvegarde automatique sur les bases de données.

Option 1 : sauvegardes gérées par Oracle

Les sauvegardes gérées par Oracle sont entièrement gérées par Exadata Cloud Infrastructure (ExaDB-D) ou Exadata Cloud@Customer (ExaDB-C@C) selon une configuration effectuée une seule fois. En plus d'être entièrement intégrées au plan de contrôle des services cloud ExaDB-D ou ExaDB-C@C, ces sauvegardes sont également accessibles via les API OCI. Oracle recommande cette approche.

  • Les commandes dbaascli database backup et dbaascli database recover peuvent être utilisées avec les sauvegardes automatisées pour certaines opérations. Pour plus d'informations, reportez-vous à dbaascli database backup et à dbaascli database recover.
  • Les clients sont autorisés à interroger les vues RMAN ou à exécuter des commandes RMAN de restauration et de récupération, par exemple des commandes de récupération de table, de fichier de données ou de tablespace.
    Remarque

    N'utilisez pas la configuration RMAN pour modifier les paramètres RMAN cloud préréglés.

Option 2 : sauvegardes configurées par l'utilisateur

Les clients peuvent également configurer des sauvegardes à partir de l'hôte à l'aide des commandes dbaascli database backup et dbaascli database recover. Toutefois, ces sauvegardes ne sont pas synchronisées avec le plan de contrôle ni intégrées aux API OCI. De plus, aucune opération de gestion ou de cycle de vie sur ces sauvegardes n'est prise en charge à partir de la console de plan de contrôle du service. Par conséquent, cette approche n'est pas recommandée.

Cette approche est utile lorsque l'accès direct aux destinations de sauvegarde est requis pour effectuer certaines tâches. Par exemple : accès au bucket OSS pour répliquer des sauvegardes entre des régions ou surveiller des destinations de sauvegarde.

Si les clients configurent des sauvegardes vers Object Storage à l'aide de RMAN sans utiliser le plan de contrôle OCI ou les API OCI, ils sont responsables de la configuration manuelle des sauvegardes de portefeuille TDE. Par défaut, l'automatisation du cloud Oracle nettoie les fichiers de journalisation archivés toutes les 24 heures. Lorsque vous utilisez RMAN pour effectuer des sauvegardes manuelles, les fichiers de journalisation archivés risquent d'être supprimés. Pour plus d'informations sur la configuration du nettoyage des journaux d'archivage, reportez-vous à dbaascli database backup. Il est recommandé d'utiliser les sauvegardes gérées par Oracle.

Pour plus d'informations, reportez-vous à Sauvegarde configurée par l'utilisateur.

Option 3 : sauvegardes à l'aide de RMAN

Les sauvegardes peuvent être effectuées directement à l'aide de RMAN avec des scripts personnalisés appartenant au client. Cependant, Oracle ne recommande pas cette approche.

Il n'est pas recommandé d'utiliser des sauvegardes RMAN avec des sauvegardes gérées par Oracle ou configurées par l'utilisateur.

Qui peut utiliser cette option ?
  • Clients souhaitant conserver leurs scripts de sauvegarde/restauration RMAN existants
  • Clients souhaitant configurer des sauvegardes à partir d'une base de données de secours dans des environnements Data Guard pour décharger la charge globale de sauvegarde vers la base de données de secours

Si vous prévoyez d'effectuer des sauvegardes à l'aide de RMAN, vous devez désinscrire la base de données de l'automatisation de la sauvegarde. Pour plus d'informations, reportez-vous à Désactivation des sauvegardes automatiques pour faciliter la gestion manuelle de la sauvegarde et de la récupération.

Gestion des sauvegardes de base de données Exadata

Les sauvegardes de base de données Exadata automatiques sont gérées par Oracle Cloud Infrastructure. Vous configurez cela à l'aide de la console ou de l'API.

Pour les sauvegardes non gérées, reportez-vous à Gestion des sauvegardes de base de données Exadata à l'aide de dbaascli.

Il existe deux destinations possibles pour les sauvegardes de base de données Exadata automatiques : Autonomous Recovery Service ou Oracle Object Storage.

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.

Object Storage

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

Remarque

Si vous avez précédemment utilisé dbaascli afin de configurer des sauvegardes, vous pouvez passer à l'utilisation de la console ou de 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 protéger votre base de données.

Types de sauvegarde gérée et informations d'utilisation

Il existe deux types de sauvegarde de base de données Exadata automatique : Autonomous Recovery Service et Oracle Object Storage.

La base de données et l'infrastructure (cluster de machines virtuelles ou système de base de données) doivent présenter l'état Disponible pour permettre l'exécution d'une opération de sauvegarde. Oracle recommande d'éviter d'effectuer des actions susceptibles d'interférer avec la disponibilité (opérations d'application de patches, par exemple) 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 l'instance Oracle Exadata Database Service sur l'infrastructure Exascale et la disponibilité de la base de données sont restaurées.

Lorsque la fonctionnalité de sauvegarde automatique est activée, l'un ou l'autre des services crée des sauvegardes incrémentielles quotidiennes de la base de données sur la destination de sauvegarde sélectionnée.

Si vous choisissez d'activer les sauvegardes automatiques, vous pouvez contrôler la période de conservation. Le système supprime automatiquement les sauvegardes à l'expiration de la période de conservation affectée.

Période de conservation de la sauvegarde Object Storage

Les périodes de conservation (en jours) sont 7, 15, 30, 45, 60. Valeur par défaut : 30 jours.

Le processus de sauvegarde automatique démarre à tout moment pendant la fenêtre de sauvegarde quotidienne. 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.

Si vous ne spécifiez pas de fenêtre de sauvegarde, la fenêtre par défaut allant de 0 h 00 à 6 h 00 dans le fuseau horaire de la région de l'instance Exadata Cloud Infrastructure est affectée à votre base de données. La fenêtre de programmation de sauvegarde par défaut est de six heures. Les fenêtres de sauvegarde que vous indiquez sont quant à elles de deux heures.

Stratégie de protection Autonomous Recovery Service

  • Bronze : 14 jours
  • Argent : 35 jours
  • Or : 65 jours
  • Platine : 95 jours
  • Personnalisée par vous
  • Valeur par défaut : Argent - 35 jours

Le processus de sauvegarde automatique démarre à tout moment ou dans la fenêtre affectée.

Remarque

  • Data Guard : vous pouvez activer la fonctionnalité de sauvegarde automatique sur une base de données ayant le rôle de base de données de secours dans une association Data Guard. Toutefois, aucune sauvegarde automatique de cette base de données n'est créée tant qu'elle ne prend pas le rôle principal.
  • Modifications de la conservation de sauvegarde : si vous réduisez la période de conservation des sauvegardes de votre base de données ou votre stratégie de protection 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 de stockage de sauvegarde : les sauvegardes automatiques entraînent des coûts d'utilisation du stockage pour Autonomous Recovery Service ou Object Storage en fonction de la destination de sauvegarde sélectionnée.

Vous pouvez créer une sauvegarde complète de la base de données à tout moment à l'aide de l'un ou l'autre service.

Lorsque vous mettez fin à une base de données d'instance Exadata Cloud Service, toutes ses ressources sont supprimées. Les sauvegardes gérées à l'aide de la destination Object Storage sont supprimées et les sauvegardes gérées à l'aide d'Autonomous Recovery Service sont supprimées en fonction de l'option de suppression sélectionnée. Les sauvegardes autonomes créées dans Object Storage resteront une fois la base de données arrêtée et doivent être supprimées manuellement. Vous pouvez utiliser une sauvegarde autonome pour créer une base de données.

Afin d'être en adéquation avec la pratique recommandée par Oracle qui consiste à utiliser le privilège 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 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 de l'opération de sauvegarde ou de récupération. Cette modification de l'automatisation cloud a été apportée à partir de dbaastools version 21.4.1.1.0.

Comportement de destination de sauvegarde lors de l'activation de sauvegardes automatiques et de sauvegardes autonomes à l'aide de la console OCI

Sauvegardes automatiques

À compter du 06 août 2025, lorsque vous activez les sauvegardes automatiques dans la console OCI, Autonomous Recovery Service sera la seule destination de sauvegarde disponible dans les conditions suivantes :

  • La location a été créée le 06 août 2025 ou après.
  • La base de données est déployée dans les régions OCI de Francfort (FRA), Phoenix (PHX) et Tokyo (NRT).
  • La version Oracle Database est postérieure à la version 19.18 ou 23.4.
  • Il existe des limites de capacité et de sauvegarde disponibles dans la région.

    Remarque : Si les limites ou la capacité ne sont pas disponibles, vous serez invité à soumettre une demande d'augmentation de limite.

Quand OCI Object Storage est toujours disponible en tant qu'option de sauvegarde

Vous continuerez à voir OCI Object Storage comme destination de sauvegarde dans les scénarios suivants :

  • La location a été créée avant le 06 août 2025.
  • La version de base de données est antérieure à la version 19.18 ou 23.4.
  • La région n'est pas FRA, PHX ou NRT.
  • Echec de l'intégration d'Autonomous Recovery Service en raison d'une capacité régionale insuffisante pour prendre en charge la taille de la base de données.

Scénarios supplémentaires

  • Configuration Data Guard inter-région : si la base de données principale se trouve dans une région en dehors de FRA, PHX ou NRT, et que la base de données de secours se trouve dans l'une de ces régions, seule la base de données de secours peut être sauvegardée à l'aide d'Autonomous Recovery Service. OCI Object Storage n'est pas pris en charge dans FRA, PHX ou NRT pour les nouvelles locations.
  • Régions de location mixtes : si vous opérez dans deux régions (une avec une location existante (pas dans FRA, PHX ou NRT) et une autre avec une nouvelle location dans FRA, PHX ou NRT), vous bénéficierez d'une configuration de sauvegarde fractionnée, avec OCI Object Storage dans la région existante et Autonomous Recovery Service dans la nouvelle région.
  • Déploiement multi-région après le 06 août 2025 : pour les nouvelles locations créées après le 06 août 2025, avec des déploiements dans FRA, PHX, NRT et IAD, la configuration de sauvegarde sera différente : FRA, PHX et NRT utiliseront Autonomous Recovery Service, tandis qu'IAD continuera à prendre en charge OCI Object Storage.

Sauvegardes autonomes

Pour les nouvelles locations créées dans les régions FRA, PHX et NRT, le comportement existant pour les sauvegardes autonomes reste inchangé dans la console OCI et l'API OCI.

Le comportement est le suivant :

  • Si les sauvegardes automatiques sont configurées sur OCI Object Storage, les sauvegardes autonomes sont stockées dans OCI Object Storage.
  • Si les sauvegardes automatiques sont configurées sur Autonomous Recovery Service, les sauvegardes autonomes sont stockées dans Autonomous Recovery Service.
  • Si les sauvegardes automatiques ne sont pas configurées, les sauvegardes autonomes sont définies par défaut sur OCI Object Storage.

Sauvegarde à long terme avec Recovery Service

La sauvegarde de conservation à long terme (LTR) vous permet de stocker des sauvegardes complètes pour des périodes allant jusqu'à dix ans à des fins de conformité, de 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 exprimée en jours (90 à 3 650) 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 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 plus d'informations, reportez-vous à Procédure de 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 plus d'informations, reportez-vous à Procédure de modification de la période de conservation d'une sauvegarde LTR 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 plus d'informations, reportez-vous à Procédure d'une création de base de données à partir d'une sauvegarde.

Lorsque vous mettez fin à une base de données, les sauvegardes LTR sont supprimées conformément à la valeur "Options de suppression après la fin de la base de données".

  • Supprimer les sauvegardes en 72 heures : toutes les sauvegardes, y compris les sauvegardes à long terme, 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 sélectionner l'option Supprimer en fonction de la stratégie lors de la terminaison d'une base de données pour garantir la conservation des sauvegardes à long terme.

Tenez compte des facteurs supplémentaires suivants pour les sauvegardes à long terme :

  • 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 à long terme 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.
  • La fonction LTR est prise en charge pour les bases de données avec des fichiers TDE ou des fichiers de clés d'accès KMS.
  • Les clés de cryptage seront conservées pendant toute la période de conservation du LTR.
  • Une sauvegarde LTR peut être annulée lorsqu'elle est à l'état "création".
  • Une sauvegarde LTR peut être supprimée à tout moment après sa création.
  • Pendant la restauration :
    • Si la sauvegarde est d'une version majeure DBHome prise en charge, elle sera restaurée vers la dernière RU de cette version.
    • Si la sauvegarde est d'une version majeure DBHome non prise en charge, elle sera restaurée vers une version majeure prise en charge, après quoi la base de données doit être mise à niveau vers l'une des versions majeures prises en charge.

Allocation de canaux de sauvegarde par défaut

Il s'agit des paramètres par défaut des canaux de sauvegarde de base de données lors de l'utilisation de la sauvegarde gérée par Oracle ou de la sauvegarde configurée par l'utilisateur.

Lorsqu'une base de données est configurée pour la sauvegarde gérée par Oracle ou la sauvegarde configurée par l'utilisateur, les outils utilisent des valeurs par défaut pour les canaux de sauvegarde. Lorsque la valeur par défaut est utilisée, dbaas détermine le nombre de canaux à allouer au moment de l'exécution de la commande de sauvegarde ou de restauration. Le nombre de canaux alloués est déterminé par le nombre de coeurs du noeud. Le tableau suivant fournit les valeurs utilisées et la plage de coeurs. Les valeurs de coeurs et de canaux sont définies par noeud. Les opérations de restauration sont prioritaires. Le nombre total de canaux à l'échelle du cluster correspond à la valeur par noeud multipliée par le nombre de noeuds. L'automatisation utilise le nom SCAN pour distribuer les canaux RMAN sur tous les noeuds du cluster.

Coeurs par noeud Formule Allocation de canaux de sauvegarde par noeud Allocation de canaux de restauration par noeud
Moins de 12 ou 12 Coeurs <= 12 2 4
Plus de 12 et moins de 24 ou 24 Coeurs > 12 et Coeurs <= 24 4 8
Plus de 24 Coeurs > 24 8 16

Si nécessaire, vous pouvez définir une valeur statique par noeud à l'aide de la commande getConfig/configure de DBAASCLI pour générer un fichier bckup cfg et définir le paramètre bkup_channels_node sur le nombre de canaux par noeud de votre choix.

Les valeurs valides sont comprises entre 1 et 32 : le nombre total de canaux correspond à cette valeur multipliée par le nombre de noeuds. Cette valeur ne peut pas dépasser la limite de 255 canaux. La valeur default pour bkup_channels_node définit l'allocation de canaux de base.

Prérequis pour les sauvegardes sur Oracle Exadata Database Service sur une infrastructure Exascale

Recovery Service

Assurez-vous que votre location est configurée pour utiliser Recovery Service.

Tableau 5-4 Passez en revue les tâches prérequises avant d'utiliser Recovery Service comme destination de sauvegarde automatique

Tâche Plus d'informations Requise ou facultative

Création de stratégies IAM

Droits d'accès requis pour que les bases de données Oracle dans OCI utilisent Recovery Service

Obligatoire

Configurez les ressources réseau et inscrivez un sous-réseau Recovery Service

Création d'un sous-réseau de service de récupération dans la base de données VCN

Obligatoire

Créer des stratégies de protection

Création d'une stratégie de protection

facultatif

Pour plus d'informations sur Recovery Service, reportez-vous à Présentation d'Oracle Database Autonomous Recovery Service.

Object Storage

Utilisation de la console pour gérer les sauvegardes

Vous pouvez utiliser la console pour activer les sauvegardes incrémentielles automatiques, créer des sauvegardes complètes à la demande et afficher la liste des sauvegardes gérées d'une base de données. Vous pouvez également vous servir de la console pour supprimer des sauvegardes manuelles (à la demande).

Remarque

  • Toutes les sauvegardes sont cryptées à l'aide de la même clé maître que pour le cryptage transparent des données de portefeuille.
  • Les sauvegardes d'une base de données spécifique sont répertoriées dans la page de détails de cette dernière. La colonne Clé de cryptage indique Clé gérée par Oracle ou un nom de clé si vous utilisez vos propres clés de cryptage pour protéger la base de données. Pour plus d'informations, reportez-vous à Sauvegarde de coffres et de clés.
Remarque

Ne supprimez aucune clé de cryptage nécessaire du coffre, car les bases de données et les sauvegardes protégées par la clé deviendraient indisponibles.

Procédure de configuration de sauvegardes automatiques pour une base de données

Procédure de création d'une sauvegarde à la demande d'une base de données

Remarque

Object Storage crée une sauvegarde complète de la base de données tandis que Recovery Service crée une sauvegarde incrémentielle.
  1. Ouvrez le menu de navigation. Cliquez sur Oracle Database, puis sur Service de base de données Exadata sur une infrastructure Exascale.
  2. Choisissez votre compartiment.
  3. Accédez au cluster de machines virtuelles cloud contenant la base de données à sauvegarder :

    Sous Oracle Exadata Database Service on Exascale Infrastructure, cliquez sur Clusters Exadata de machines virtuelles. Dans la liste des cluster de machines virtuelles, recherchez celui auquel accéder, puis cliquez sur son nom mis en évidence pour afficher la page des détails du cluster.

  4. Dans la liste des bases de données, recherchez celle pour laquelle vous voulez créer une sauvegarde complète à la demande, puis cliquez sur son nom pour afficher les détails la concernant.
  5. Sous Ressources, cliquez sur Sauvegardes.

    La liste des sauvegardes est affichée.

  6. Cliquez sur Créer une sauvegarde.
  7. Dans la fenêtre Create backup qui s'affiche, procédez comme suit :
    • Nom : indiquez un nom descriptif pour la sauvegarde.
    • Sélectionnez une option de conservation de sauvegarde :
      • Conserver les sauvegardes par période de conservation de sauvegarde : sélectionnez cette option pour utiliser la période de conservation de la stratégie de protection pour cette sauvegarde.
      • Indiquer une période de conservation de sauvegarde à long terme : sélectionnez cette option pour indiquer une période LTR avec Autonomous Recovery Service. La période de conservation doit être indiquée en jours (90 - 3 650) ou en années (1 - 10) à partir de la création de la sauvegarde.
    • Cliquez sur Créer.

Pour visualiser le statut de la sauvegarde

Procédure d'annulation d'une sauvegarde

Procédure de suppression des sauvegardes complètes dans Object Storage

Procédure de suppression des sauvegardes autonomes dans Object Storage

  1. Ouvrez le menu de navigation. Cliquez sur Oracle Database, puis sur Sauvegardes autonomes sous Ressources.
  2. Dans la liste des sauvegardes autonomes, recherchez celle que vous voulez supprimer.
  3. Cliquez sur le menu Actions de la sauvegarde qui vous intéresse, puis sur Supprimer.
  4. Dans la boîte de dialogue Supprimer, cliquez sur Supprimer pour confirmer la suppression de la sauvegarde.

Pour modifier la période de conservation d'une sauvegarde LTR avec Recovery Service

  1. Ouvrez le menu de navigation. Sélectionnez Oracle Database, puis Exadata Database Service sur l'infrastructure Exascale.
  2. Choisissez votre compartiment.
  3. Accédez aux clusters de machines virtuelles cloud ou aux systèmes de base de_données contenant la base de_données à modifier :

    Sous Exadata Database Service sur l'infrastructure Exascale, cliquez sur Clusters de machines virtuelles Exadata. Dans la liste des clusters de machines virtuelles, recherchez celui auquel accéder, puis cliquez sur son nom mis en évidence pour afficher la page de détails correspondante.

  4. Dans la liste des bases de données, cliquez sur le nom de la base de données pour laquelle vous souhaitez modifier la période de conservation.
  5. Sous Ressources, cliquez sur Sauvegardes.

    La liste des sauvegardes est affichée.

  6. Dans la liste des sauvegardes, cliquez sur le menu Actions de la sauvegarde dont le type est Sauvegarde à long terme et dont vous souhaitez modifier la période de conservation.
  7. Cliquez sur Modifier la période de conservation.
  8. Dans la période de conservation de modification obtenue, modifiez la période de conservation.
    Remarque

    La période de conservation doit être indiquée en jours (90 - 3 650) ou en années (1 - 10) à partir de la création de la sauvegarde.
  9. Cliquez sur Enregistrer.

Procédure de désignation d'un service de récupération autonome en tant que destination de sauvegarde pour une base de données existante

Récupération d'une base de données Exadata à partir de la destination de sauvegarde

Cette rubrique explique comment récupérer une base de données Exadata à partir d'une sauvegarde stockée dans Object Storage ou Autonomous Recovery Service à l'aide de la console ou de l'API.

  • Le service Object Storage est une solution de stockage à la demande sécurisée et évolutive dans Exadata Cloud Infrastructure.
  • OracleDatabase Autonomous Recovery Service est une solution de sauvegarde centralisée, entièrement gérée et autonome pour les bases de données Oracle Cloud Infrastructure (OCI).

Pour plus d'informations sur la sauvegarde de vos bases de données dans Object Storage, reportez-vous à Gestion des sauvegardes de base de données Exadata.

Utilisation de la console pour restaurer une base de données

Vous pouvez utiliser la console pour restaurer la base de données à partir d'une sauvegarde dans une destination de sauvegarde créée à l'aide de la console.

Remarque

Les sauvegardes LTR représentent un point dans le temps unique pour la base de données. Les options suivantes ne sont donc pas prises en charge lors de la restauration.

Vous pouvez effectuer une restauration vers :

  • Restaurer La dernière version : restaure la base de données tel qu'au dernier état correct 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 le SCN : restaure la base d'informations à l'aide du SCN spécifié. Ce numéro SCN doit être valide.
    Remarque

    Vous pouvez déterminer le numéro SCN à utiliser soit en accédant à l'hôte de base de données et en l'interrogant, soit en accédant à des journaux en ligne ou archivés.
Remarque

La liste des sauvegardes affichée dans la console ne contient aucune sauvegarde non gérée (sauvegardes créées directement à l'aide de dbaascli).

Procédure de restauration d'une base de données

Suivez cette procédure pour restaurer le service Exadata Database Service sur Oracle Database Exascale Infrastructure.

  1. Ouvrez le menu de navigation. Cliquez sur Oracle Database, puis sur Service de base de données Exadata sur une infrastructure Exascale.
  2. Cliquez sur Clusters de machines virtuelles Exadata.
  3. Dans la liste des cluster de machines virtuelles, recherchez celui qui met en évidence la base de données à restaurer, puis cliquez sur son nom mis en évidence pour afficher la page de détails du cluster.
  4. Dans la liste des bases de données, recherchez celle à restaurer, puis cliquez sur son nom pour afficher les détails correspondants.
  5. Cliquez sur Restaurer.
  6. Sélectionnez l'une des options suivantes, puis cliquez sur Restaurer la base de données :
    • 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 l'horodatage : : permet de restaurer la base de données vers l'horodatage spécifié.
    • Restore to System Change Number (SCN) : permet de restaurer la base de données à l'aide du SCN spécifié. Ce numéro SCN doit être valide.

      Remarque

      Vous pouvez déterminer le numéro SCN à utiliser soit en accédant à l'hôte de base de données et en l'interrogant, soit en accédant à des journaux en ligne ou archivés.
  7. Confirmez l'opération lorsque vous y êtes invité.

    Si l'opération de restauration échoue, la base de données indiquera l'état "Echec de la restauration". Vous pouvez réessayer d'effectuer la restauration à l'aide d'une autre option de restauration. Toutefois, Oracle recommande de consulter les journaux RMAN sur l'hôte et de corriger les problèmes éventuels avant la nouvelle tentative de restauration de la base de données. Ces fichiers journaux se trouvent dans des sous-répertoires du répertoire /var/opt/oracle/log.

Gestion des sauvegardes de base de données Exadata à l'aide de dbaascli

Vous pouvez utiliser l'utilitaire de sauvegarde d'Exadata, dbaascli, pour sauvegarder des bases de données sur une instance Oracle Exadata Database Service on Exascale Infrastructure vers un bucket existant dans le service Oracle Object Storage.

Pour les sauvegardes gérées par Oracle Cloud Infrastructure, reportez-vous à Gestion des sauvegardes de base de données Exadata.

Cette rubrique explique les opérations suivantes :

  • Créez un fichier de configuration de sauvegarde par défaut et modifiez les paramètres en fonction de vos besoins pour sauvegarder la base de données vers le service de stockage d'objets.
  • Associer le fichier de configuration de sauvegarde à une base de données. Une fois la configuration effectuée, la base de données est sauvegardée comme programmée ou vous pouvez créer une sauvegarde à la demande avec une balise.

Configuration de sauvegarde par défaut

Recommandations d'Oracle relatives aux meilleures pratiques pour la configuration de sauvegarde par défaut.

La configuration de sauvegarde par défaut suit un ensemble de meilleures pratiques Oracle :

  • Cryptage : toutes les sauvegardes vers Object Storage sont cryptées.
  • Compression pour les sauvegardes : LOW
  • Compression par défaut pour les fichiers de journalisation archivés : false
  • Algorithme de cryptage RMAN : AES256
  • Optimisation pour les sauvegardes : ON

Procédure de création d'un fichier de configuration de sauvegarde

Remarque

La procédure suivante doit être effectuée sur le premier noeud de calcul du cluster d'infrastructures cloud Exadata. Pour déterminer le premier noeud de calcul, connectez-vous à n'importe quel noeud de calcul en tant qu'utilisateur grid et exécutez la commande suivante :
$ $ORACLE_HOME/bin/olsnodes -n

Le numéro 1 figure en regard du nom du premier noeud.

  1. Utilisez SSH pour vous connecter à l'un des noeuds de base de données configurés dans le cluster de machines virtuelles.
    ssh -i <private_key_path> opc@<node_1_ip_address>
  2. Connectez-vous en tant qu'utilisateur opc, puis passez à l'utilisateur root à l'aide de la commande sudo.
    login as: opc [opc@dbsys ~]
    $ sudo su -
  3. Utilisez la commande dbaascli database backup --getConfig pour générer un fichier contenant les paramètres de sauvegarde en cours du déploiement de base de données :
    # dbaascli database backup --getConfig [--configFile <file_name>] --dbname <database_name>
  4. Modifiez les paramètres du fichier en fonction de vos besoins.
    Remarque

    A partir du 06 août 2025, pour les locations créées dans les régions FRA, PHX ou NRT, Autonomous Recovery Service sera la seule destination de sauvegarde lorsque vous activerez la sauvegarde automatique sur les bases de données.

    A propos de l'utilisation de Recovery Service pour sauvegarder et récupérer les bases de données Oracle Cloud

    Paramètre Description
    bkup_disk=[yes|no] Indique si la sauvegarde doit être effectuée localement sur le disque (zone de récupération rapide).
    bkup_oss=[yes|no] Indique si la sauvegarde doit être effectuée sur Object Storage. Si oui, vous devez également fournir les paramètres bkup_oss_url, bkup_oss_user, bkup_oss_passwd et bkup_oss_recovery_window.
    bkup_oss_url=<swift_url>

    Obligatoire si bkup_oss=yes.

    URL Object Storage incluant le locataire et le bucket à utiliser. L'URL est la suivante :

    https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<tenant>/<bucket>

    Où :

    • <tenant> : nom du locataire en minuscules (même s'il contient des caractères en majuscules) que vous indiquez lors de la connexion à la console
    • <bucket> : nom du bucket existant à utiliser pour les sauvegardes.
    bkup_oss_user=<oci_user_name>

    Obligatoire si bkup_oss=yes.

    Nom utilisateur pour le compte utilisateur Oracle Cloud Infrastructure. Nom utilisateur que vous employez pour vous connecter à la console Oracle Cloud Infrastructure.

    Par exemple : jsmith@example.com pour un utilisateur local ou <identity_provider>/jsmith@example.com pour un utilisateur fédéré.

    Pour déterminer le type d'utilisateur dont vous disposez, reportez-vous aux rubriques suivantes :

    L'utilisateur doit être membre du groupe Administrateurs.

    bkup_oss_passwd=<auth_token>

    Obligatoire si bkup_oss=yes.

    jeton d'authentification généré à l'aide de la console ou de l'API IAM, comme indiqué dans Prérequis.

    Il ne s'agit pas du mot de passe de l'utilisateur Oracle Cloud Infrastructure.

    bkup_oss_recovery_window=n

    Obligatoire si bkup_oss=yes.

    Nombre de jours pendant lesquels les sauvegardes et les fichiers de journalisation archivés sont conservés dans le bucket Object Storage. Indiquez une durée comprise entre 7 et 90 jours.

    bkup_daily_time=hh:mm Heure à laquelle la sauvegarde quotidienne est programmée, indiquée en heures et minutes (hh:mm), au format 24 heures.
    bkup_archlog_cron_entry=[yes|no] Si aucune sauvegarde n'est configurée à l'aide de dbaastools, la définition de bkup_archlog_cron_entry=no enlève le travail de nettoyage de journal d'archivage de crontab. La valeur par défaut est "yes".
  5. Utilisez dbaascli database backup --configure pour associer cette configuration de sauvegarde à un nom de base de données.
    # dbaascli database backup --configure --configFile <file_name> --dbname <database_name>
  6. Utilisez dbaascli database backup --status pour vérifier le statut de l'UUID généré pour cette commande.
    # dbaascli database backup --status --uuid <uuid> --dbname <database_name>
    Remarque

    Un fichier de configuration de sauvegarde peut contenir les informations d'identification permettant d'accéder au bucket Object Storage. Ainsi, vous pouvez choisir d'enlever le fichier une fois la sauvegarde configurée.

Vous pouvez modifier les paramètres suivants pour personnaliser la configuration de sauvegarde :

Remarque

Compatible with Console Automatic Backups=Yes indique que le paramètre peut être modifié en toute sécurité, même si vous utilisez les sauvegardes automatiques basées sur une console. Si vous utilisez des paramètres pour lesquels il est indiqué Compatible with Console Automatic Backups=No, n'activez pas les sauvegardes via la console.

Tableau 5-5 Paramètres de configuration de sauvegarde - Programmation des paramètres vers dbaascli

Paramètre Description Compatible avec les sauvegardes automatiques de la console*

Ancien nom : bkup_cron_entry

Nouveau nom : scheduleBackups

Permet la configuration de la sauvegarde automatique.

Les valeurs valides sont yes et no.

Non

Ancien nom : bkup_archlog_cron_entry

Nouveau nom : manageArchivelogs

Active les sauvegardes automatiques des fichiers journaux de la base de données archivée.

Les valeurs valides sont yes et no.

La définition de manageArchivelogs sur no désactive les travaux de nettoyage automatique des fichiers de journalisation archivés. Ce paramètre n'est valide que si aucune sauvegarde automatique de base de données n'est configurée pour la base de données associée.

Non

Ancien nom : bkup_l0_day

Nouveau nom : L0BackupDay

Ce paramètre contrôle le jour du niveau 0 de la semaine.

Jour de la semaine où une sauvegarde de niveau 0 est effectuée.

Les valeurs valides sont mon, tue, wed, thu, fri, sat et sun. Les formats plus longs, par exemple, Monday, Tuesday sont également pris en charge.

Valeur par défaut : sun.

Non

Tableau 5-6 Paramètres de configuration de sauvegarde - Paramètres de configuration RMAN généraux (valides pour toutes les destinations de sauvegarde, à l'exception de la destination Stockage local [zone de récupération rapide])

Paramètre Description Compatible avec les sauvegardes automatiques de la console*

Ancien nom : bkup_rman_compression

Nouveau nom : compressionLevel

Niveau de compression appliqué aux sauvegardes automatiques.

Les valeurs valides sont NONE, basic, low, medium et high.

La valeur par défaut est low.

La valeur NONE désactive les opérations de compression RMAN.

Si la compression RMAN est activée, les fichiers de données cryptés par TDE sont décryptés, compressés et cryptés par RMAN.

Oui

Ancien nom : bkup_section_size

Nouveau nom : sectionSize

Taille de section RMAN utilisée pour les sauvegardes automatiques.

La valeur par défaut est 64G.

Oui

Ancien nom : bkup_channels_node

Nouveau nom : channelsPerNode

Nombre de canaux RMAN par noeud utilisés pour les sauvegardes automatiques.

Les valeurs valides sont comprises entre 1 et 32.

La valeur par défaut est 2.

Oui

Ancien nom : bkup_daily_time

Nouveau nom : autoBackupTime

Heure de début de la sauvegarde quotidienne automatique, au format 24 heures, sous la forme hh:mm.

Oui

Ancien nom : bkup_archlog_frequency

Nouveau nom : backupFrequencyAL

Intervalle en minutes entre les sauvegardes automatiques des fichiers journaux de base de données archivés.

Les valeurs valides sont comprises entre 15, 20, 30, 60, 120 et 1440 par intervalles d'une heure, exprimés en minutes.

La valeur par défaut est 30 pour ExaDB-D.

Oui

Ancien nom : bkup_type

Nouveau nom : backupDestination

Type de l'emplacement où réside la sauvegarde. Indiquez OSS comme destination de sauvegarde, qui est l'option par défaut et la seule.

Oui

Ancien nom : bkup_filesperset_regular

Nouveau nom : filesPerSet

Indique le nombre maximal de fichiers de données pouvant être inclus dans un jeu de sauvegarde pour les sauvegardes standard/d'archivage. Oui

Ancien nom : bkup_filesperset_al

Nouveau nom : filesPerSetAL

Indique le nombre maximal de fichiers de journalisation archivés pouvant être inclus dans un jeu de sauvegarde pour les sauvegardes de journal d'archivage. Oui

Ancien nom : bkup_encryption

Nouveau nom : encryption

Le cryptage indique si les sauvegardes doivent être cryptées ou non.

Par défaut, le cryptage est activé pour OSS et Recovery Service, et ce paramètre ne peut pas être modifié.

Oui

Ancien nom : rmanBackupOptimization

Nouveau nom : optimization

L'optimisation est une fonctionnalité qui réduit la quantité de données à sauvegarder, transférer et restaurer. La valeur recommandée est ON. Oui

Ancien nom : rmanFraCleanupChannels

Nouveau nom : numberOfChannelsForFraCleanup

Indique le nombre de canaux utilisés pour le travail de nettoyage FRA. Oui

Ancien nom : Compress_Archive_Logs

Nouveau nom : compressionAL

Indique si les sauvegardes de journal d'archivage ne doivent pas être compressées.

Non applicable au service de récupération.

Oui

Ancien nom : bkup_archlog_fra_retention

Nouveau nom : archivelogRetentionDays

Indique le nombre de jours pendant lesquels le journal d'archivage doit être conservé dans FRA. Oui

Tableau 5-7 Paramètres de configuration de sauvegarde - Paramètres Object Storage Service (OSS)

Paramètre Description Compatible avec les sauvegardes automatiques de la console*
backupDestination=oss

Permet les sauvegardes vers le stockage cloud.

Les valeurs valides sont yes et no.

Non

Ancien nom : bkup_oss_recovery_window

Nouveau nom : ossRecoveryWindow

Durée de conservation des sauvegardes vers le stockage cloud, exprimée en nombre de jours (jusqu'à 90).

Applicable uniquement lorsque bkup_oss est défini sur yes ou que backupdestination est défini sur OSS.

La valeur par défaut est 30.

Non

Ancien nom : bkup_oss_url

Nouveau nom : ossURL

Emplacement du conteneur de stockage utilisé pour la sauvegarde vers le stockage cloud.

Applicable uniquement lorsque bkup_oss est défini sur yes ou que backupdestination est défini sur OSS.

Non

Ancien nom : bkup_oss_user

Nouveau nom : ossUserName

Nom de l'utilisateur Oracle Cloud disposant de privilèges d'écriture sur le conteneur de stockage cloud indiqué dans bkup_oss_url.

Applicable uniquement lorsque bkup_oss est défini sur yes ou que backupdestination est défini sur OSS.

Non

Ancien nom : bkup_oss_passwd

Nouveau nom : ossAuthToken

Mot de passe de l'utilisateur Oracle Cloud disposant de privilèges d'écriture sur le conteneur de stockage cloud indiqué dans bkup_oss_url.

Applicable uniquement lorsque bkup_oss est défini sur yes ou que backupdestination est défini sur OSS.

Non

Tableau 5-8 Paramètres de configuration de sauvegarde - Paramètres de prise en charge de catalogue RMAN

Paramètre Description Compatible avec les sauvegardes automatiques de la console*

Ancien nom : bkup_use_rcat

Nouveau nom : useCatalog

Permet d'utiliser un catalogue de récupération RMAN existant.

Les valeurs valides sont yes et no.

Oui

Ancien nom : bkup_rcat_user

Nouveau nom : catalogUserName

Nom de l'utilisateur du catalogue de récupération.

Applicable uniquement lorsque bkup_use_rcat est défini sur yes.

Oui

Ancien nom : bkup_rcat_passwd

Nouveau nom : catalogPassword

Mot de passe de l'utilisateur du Catalogue de récupération indiqué dans
bkup_rcat_user
.

Applicable uniquement lorsque bkup_use_rcat est défini sur yes.

Oui

Ancien nom : bkup_rcat_conn

Nouveau nom : catalogConnectionString

Chaîne de connexion du catalogue de restauration RMAN.

Applicable uniquement lorsque bkup_use_rcat est défini sur yes.

Oui
Remarque

Seuls les paramètres ci-dessus pour lesquels il a été indiqué Compatible with Console Automatic Backups = Yes peuvent être modifiés en toute sécurité avec les sauvegardes automatiques basées sur une console. Si d'autres paramètres doivent être modifiés, n'activez pas les sauvegardes via la console.

Procédure de création d'une sauvegarde à la demande

Vous pouvez utiliser dbaascli pour créer une sauvegarde à la demande d'une base de données.

  1. Connectez-vous via SSH à l'un des noeuds configurés de base de données dans la ressource de cluster de machines virtuelles ou de système de base de données.
    ssh -i <private_key_path> opc@<node_1_ip_address>

    Pour déterminer le premier noeud de calcul, connectez-vous à n'importe quel noeud de calcul en tant qu'utilisateur grid et exécutez la commande suivante :

    $ $ORACLE_HOME/bin/olsnodes -n

    Le numéro 1 figure en regard du nom du premier noeud.

  2. Connectez-vous en tant qu'utilisateur opc, puis passez à l'utilisateur root à l'aide de la commande sudo.
    login as: opc [opc@dbsys ~]
    $ sudo su -
  3. Vous pouvez suivre la stratégie de conservation en cours pour la sauvegarde ou créer une sauvegarde à long terme qui persiste jusqu'à ce que vous la supprimiez :
    • Pour créer une sauvegarde qui suit la stratégie de conservation en cours, entrez la commande suivante :
      # dbaascli database backup --start --dbname <database_name>
    • Pour créer une sauvegarde à long terme, entrez la commande suivante :
      # dbaascli database backup --start --archival --dbname --tag <archival_tag>
  4. Quittez le shell de commande root-user et déconnectez-vous du noeud de calcul :
    # exit
    $ exit
  5. Utilisez dbaascli database backup --status pour vérifier le statut de l'UUID généré pour la commande de sauvegarde.
    # dbaascli database backup --status --uuid <uuid> --dbname <database_name>

Procédure de suppression de la configuration de sauvegarde

  1. Connectez-vous via SSH à l'un des noeuds configurés de base de données dans la ressource de cluster de machines virtuelles ou de système de base de données.
  2. Connectez-vous en tant qu'utilisateur opc, puis passez à l'utilisateur root à l'aide de la commande sudo.
  3. Créez un fichier temp avec les paramètres suivants :
    • bkup_oss=no
    • bkup_cron_entry=no
    • bkup_archlog_cron_entry=no
  4. Utilisez le fichier ci-dessus avec dbaascli database backup --configure pour enlever la configuration de sauvegarde d'une base de données.
    # dbaascli database backup --configure --configFile <file_name> --dbname <database_name>
  5. Utilisez dbaascli database backup --status pour vérifier le statut de l'UUID généré pour cette commande.
    # dbaascli database backup --status --uuid <uuid> --dbname <database_name>

Cela désactivera toutes les sauvegardes automatiques.

Procédure de suppression d'une sauvegarde locale

Procédure de suppression d'une sauvegarde dans Object Storage

Vous pouvez supprimer un archivage ou une sauvegarde à long terme d'Object Storage.

# dbaascli database backup --delete --backupTag --dbname <database_name>

Où :

  • --dbname : indique le nom Oracle Database.
  • --delete : supprime la sauvegarde d'archivage.
  • --backupTag : indique la balise de sauvegarde à supprimer.

Les sauvegardes basées sur des stratégies sont supprimées avec des sauvegardes quotidiennes programmées. Vous pouvez également utiliser la commande RMAN delete backup pour supprimer une sauvegarde de la banque d'objets.

Utilisation de l'API pour gérer la sauvegarde et la récupération

Utilisation de l'API pour gérer les sauvegardes

Découvrez comment utiliser l'API pour les sauvegardes de base de données sur Oracle Exadata Database Service sur une infrastructure Exascale.

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 les sauvegardes de base de données :

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

Autres méthodes de sauvegarde

Découvrez les autres méthodes de sauvegarde disponibles en plus de celle de la console OCI.

La sauvegarde des bases de données sur Exadata Cloud Infrastructure peut être effectuée de plusieurs manières, en plus des sauvegardes automatiques configurées dans la console. En général, la console (ou l'API/interface de ligne de commande OCI correspondante) est la méthode privilégiée car elle est la plus simple et la plus automatisée. Il est généralement préférable d'utiliser la console OCI, l'API OCI ou la ligne de commande OCI plutôt que d'autres méthodes de gestion. Toutefois, si les actions requises ne peuvent pas être effectuées via les méthodes privilégiées, deux autres options sont disponibles pour configurer manuellement les sauvegardes : dbaascli et Oracle Recovery Manager (RMAN).

Remarque

Utilisez les commandes dbaascli database backup, dbaascli pdb backup, dbaascli database recover et dbaascli pdb recover pour sauvegarder et récupérer des bases de données Conteneur et des bases de données pluggables. Pour plus d'informations, reportez-vous à Sauvegarde configurée par l'utilisateur dans Options recommandées par Oracle pour effectuer des opérations de sauvegarde et de récupération.

RMAN est l'outil de sauvegarde inclus dans Oracle Database. Pour plus d'informations sur l'utilisation de RMAN, reportez-vous au Guide de l'utilisateur relatif à la sauvegarde et à la récupération d'Oracle Database pour la version 19. L'utilisation de RMAN pour sauvegarder les bases de données sur Exadata Cloud Infrastructure offre la plus grande flexibilité en matière d'options de sauvegarde, mais aussi la plus grande complexité.

Remarque

Bien que l'utilisation de RMAN pour restaurer des bases de données sauvegardées selon n'importe quelle méthode décrite ici soit sûre, RMAN ne doit jamais être utilisé pour configurer des sauvegardes avec la console (et l'API / CLI OCI) ou avec dbaascli. Si vous choisissez d'effectuer des sauvegardes manuellement à l'aide de RMAN, vous ne devez utiliser ni les sauvegardes automatiques de la console ni dbaascli. Vous devez d'abord désactiver complètement les sauvegardes automatiques basées sur la console. Pour plus d'informations, reportez-vous à Désactivation des sauvegardes automatiques pour faciliter la gestion manuelle de la sauvegarde et de la récupération.

La méthode dbaascli offre un juste équilibre entre les sauvegardes automatiques de la console et RMAN en matière de flexibilité et de simplicité. Utilisez dbaascli si les fonctionnalités nécessaires ne sont pas prises en charge par les sauvegardes automatiques de la console mais que vous voulez éviter la complexité liée à l'utilisation directe de RMAN. Dans certains cas, dbaascli peut être utilisé pour modifier la configuration de sauvegarde automatique de console, mais ce n'est généralement pas le cas. En général, dbaascli doit être utilisé au lieu d'activer les sauvegardes dans la console.

Désactivation des sauvegardes automatiques pour faciliter la gestion manuelle de la sauvegarde et de la récupération

Les sauvegardes configurées avec la console Exadata Cloud Service, l'API ou bkup_api fonctionnent pour divers cas d'emploi de sauvegarde et de récupération.

Les sauvegardes configurées avec Oracle Exadata Database Service sur la console d'infrastructure Exascale, l'API ou bkup_api fonctionnent pour divers cas d'emploi de sauvegarde et de récupération. Si vous avez besoin de cas d'emploi non pris en charge par les sauvegardes gérées par le cloud, vous pouvez gérer la sauvegarde et la récupération de base de données manuellement à l'aide de l'utilitaire Oracle Recovery Manager (RMAN). Pour plus d'informations sur l'utilisation de RMAN, reportez-vous au Guide de l'utilisateur relatif à la sauvegarde et à la récupération d'Oracle Database.

La gestion de la sauvegarde et de la récupération à l'aide de RMAN sur Oracle Exadata Database Service sur une infrastructure Exascale nécessite l'obtention de la propriété complète des sauvegardes de base de données et de journal d'archivage, et les sauvegardes gérées par le cloud ne doivent plus être utilisées. Avant de démarrer des sauvegardes manuelles, la fonctionnalité de sauvegarde gérée par le cloud doit être désactivée. Cela est nécessaire pour que les travaux de sauvegarde cloud ne purgent pas les journaux d'archivage avant leur sauvegarde manuelle et n'entrent pas en conflit avec les sauvegardes manuelles.

Vous pouvez utiliser l'utilitaire bkup_api pour désactiver les sauvegardes gérées par le cloud, y compris le travail de purge automatique des journaux d'archivage, en procédant comme suit :

Remarque

Si vous suivez ces étapes, l'automatisation ne purgera/sauvegardera plus les journaux d'archivage dans la zone de récupération rapide pour la base de données.
  1. Connectez-vous en tant qu'utilisateur opc au premier noeud de calcul.

    Pour obtenir des instructions détaillées, reportez-vous à Connexion à un noeud de calcul avec SSH.

  2. Démarrez un shell de commande root-user :
    sudo -s
  3. Utilisez la commande bkup_api get config afin de générer un fichier contenant les paramètres de sauvegarde en cours pour le déploiement de base de données :
    /var/opt/oracle/bkup_api/bkup_api get config [--file=filename] --dbname=dbname
    Où :
    • filename est un paramètre facultatif utilisé pour indiquer le nom du fichier généré.
    • dbname est le nom de la base de données sur laquelle effectuer une opération.
  4. Modifiez les valeurs de paramètre dans le fichier généré pour modifier les paramètres suivants.
    Cette modification enlèvera les entrées crontab de sauvegarde et désactivera toutes les sauvegardes automatiques. Si les valeurs sont définies sur yes, définissez-les sur no.
    bkup_cron_entry=no
    bkup_archlog_cron_entry=no
    bkup_nfs=no
    bkup_oss=no
    bkup_local=no
  5. Utilisez la commande bkup_api set config pour mettre à jour les paramètres de sauvegarde à l'aide du fichier contenant les paramètres de sauvegarde mis à jour :
    /var/opt/oracle/bkup_api/bkup_api set config --file=filename --dbname=dbname
    Où :
    • filename est un paramètre facultatif utilisé pour indiquer le nom du fichier généré.
    • dbname est le nom de la base de données sur laquelle effectuer une opération.

    Le travail de définition de la configuration prendra quelques minutes.

  6. Vous pouvez utiliser la commande bkup_api configure_status pour vérifier le statut de la mise à jour de configuration :
    /var/opt/oracle/bkup_api/bkup_api configure_status --dbname=dbname
    Où :
    • dbname est le nom de la base de données sur laquelle effectuer une opération.

    Le statut de configuration de sauvegarde est d'abord En cours d'exécution, puis passe à Terminé une fois l'opération terminée.

  7. Exécutez à nouveau la commande bkup_api get config et vérifiez que les paramètres répertoriés ci-dessus sont définis sur no.
    /var/opt/oracle/bkup_api/bkup_api get config [--file=filename] --dbname=dbname
    Où :
    • filename est un paramètre facultatif utilisé pour indiquer le nom du fichier généré.
    • dbname est le nom de la base de données sur laquelle effectuer une opération.
    Remarque

    Une fois ces modifications apportées, aucune sauvegarde, y compris les sauvegardes de journal d'archivage, n'est effectuée par l'automatisation du cloud. Assurez-vous que des sauvegardes RMAN manuelles sont en place pour éviter de saturer l'emplacement du journal d'archivage.
    Remarque

    Les modifications apportées à l'aide de la commande bkup_api ne sont pas reflétées dans Oracle Exadata Database Service sur la console d'infrastructure Exascale.
  8. Quittez le shell de commande root-user :
    exit

Récupération d'une base de données à l'aide d'Oracle Recovery Manager (RMAN)

Si vous avez sauvegardé la base de données à l'aide de bkup_api, vous pouvez restaurer manuellement cette sauvegarde de base de données à l'aide de l'utilitaire Oracle Recovery Manager (RMAN).

Si vous avez sauvegardé la base de données à l'aide de bkup_api, vous pouvez restaurer manuellement cette sauvegarde de base de données à l'aide de l'utilitaire Oracle Recovery Manager (RMAN). Pour plus d'informations sur l'utilisation de RMAN, reportez-vous au Guide de l'utilisateur relatif à la sauvegarde et à la récupération d'Oracle Database.

Remarque

Bien que la récupération à l'aide de RMAN soit sécurisée, vous ne devez pas employer RMAN pour lancer des sauvegardes ou modifier des paramètres de sauvegarde si vous utilisez backup_api ou des sauvegardes automatiques de la console. Cela pourrait entraîner des conditions conflictuelles ou des remplacements de paramètres, et les sauvegardes peuvent ne pas s'exécuter correctement.