Guide de solution: solution de sauvegarde et de reprise après sinistre Google Cloud pour Oracle sur Bare Metal

Présentation

Pour assurer la résilience de vos bases de données Oracle dans un environnement de solution Bare Metal, vous devez disposer d'une stratégie claire pour les sauvegardes de bases de données et la reprise après sinistre. Pour vous aider à répondre à cette exigence, l'équipe d'architectes de solutions Google Cloud a effectué des tests approfondis du service de sauvegarde et de reprise après sinistre de Google Cloud, puis a compilé ses résultats dans ce guide. Par conséquent, nous allons vous montrer les meilleurs moyens de déployer, de configurer et d'optimiser vos options de sauvegarde et de récupération pour les bases de données Oracle dans un environnement de solution Bare Metal à l'aide du service de sauvegarde et de reprise après sinistre. Nous vous communiquerons également certains chiffres de performance issus de nos résultats de test, afin que vous puissiez disposer d'un benchmark que vous pourrez comparer à votre propre environnement. Il vous sera utile si vous êtes un administrateur de sauvegarde, un administrateur Google Cloud ou un administrateur de base de données Oracle.

Expérience

En juin 2022, l'équipe d'architectes de solutions a commencé une démonstration de faisabilité pour la sauvegarde et la reprise après sinistre Google Cloud pour une entreprise cliente. Pour répondre à leurs critères de réussite, nous devions permettre la récupération de leur base de données Oracle de 50 To et la restaurer dans les 24 heures.

Cet objectif posait un certain nombre de défis, mais la plupart des personnes impliquées dans la démonstration de faisabilité estimaient que nous pouvions obtenir ce résultat et que nous devions procéder à cette démonstration. Nous avons estimé que le risque était relativement faible, car les données de test précédentes de l'équipe d'ingénierie de sauvegarde et de reprise après sinistre nous indiquaient qu'il était possible d'obtenir ces résultats. Nous avons également partagé les résultats du test avec le client pour qu'il se sente à l'aise pour procéder à la démonstration de faisabilité.

Au cours de la démonstration de faisabilité, nous avons appris à configurer correctement plusieurs éléments (Oracle, la sauvegarde et la reprise après sinistre Google Cloud, le stockage et les liens d'extension régionaux) dans un environnement de solution Bare Metal. En appliquant les bonnes pratiques que nous avons apprises, vous pouvez obtenir de meilleurs résultats.

"Votre kilométrage peut varier" est une très bonne façon de considérer les résultats globaux de ce document. Notre objectif est de partager quelques enseignements sur ce que nous avons appris, ce que vous devriez vous concentrer, ce que vous devriez éviter et ce que vous devez faire pour vous aider si vous n'obtenez pas les performances ou les résultats escomptés. Nous espérons que ce guide vous aidera à vous familiariser avec les solutions proposées et qu'il vous permettra de répondre à vos exigences.

Architecture

La figure 1 présente une vue simplifiée de l'infrastructure que vous devez créer lorsque vous déployez la sauvegarde et la reprise après sinistre pour protéger les bases de données Oracle exécutées dans un environnement de solution Bare Metal.

Figure 1: Composants permettant d'utiliser la sauvegarde et la reprise après sinistre avec des bases de données Oracle dans un environnement de solution Bare Metal

Comme vous pouvez le voir dans le schéma, cette solution nécessite les composants suivants:

• Extension régionale de la solution Bare Metal : vous permet d'exécuter des bases de données Oracle dans un centre de données tiers adjacent à un centre de données Google Cloud et d'utiliser vos licences logicielles sur site existantes.
• Projet de service de sauvegarde et de reprise après sinistre : vous permet d'héberger votre dispositif de sauvegarde/récupération, et de sauvegarder vos solution Bare Metal et vos charges de travail Google Cloud dans des buckets Cloud Storage.
• Compute service project (Projet de service Compute) : vous fournit un emplacement pour exécuter vos VM Compute Engine.
• Le service de sauvegarde et de reprise après sinistre fournit la console de gestion des sauvegardes et de la reprise après sinistre qui vous permet de gérer vos sauvegardes et la reprise après sinistre.
• Projet hôte : vous permet de créer des sous-réseaux régionaux dans un VPC partagé pouvant connecter l'extension régionale de la solution Bare Metal au service de sauvegarde et de reprise après sinistre, au dispositif de sauvegarde/récupération, à vos buckets Cloud Storage et à vos VM Compute Engine.

Installer la sauvegarde et la reprise après sinistre Google Cloud

La solution de sauvegarde et de reprise après sinistre nécessite au minimum les deux composants principaux suivants pour qu'elle fonctionne:

• Console de gestion des sauvegardes et de la reprise après sinistre : interface utilisateur et point de terminaison d'API HTML 5 qui vous permet de créer et de gérer des sauvegardes à partir de la console Google Cloud.
• Dispositif de sauvegarde/récupération : cet appareil agit en tant que nœud de calcul pour les sauvegardes, et installe et restaure les tâches types.

Google Cloud gère la console de gestion des sauvegardes et de la reprise après sinistre. Vous devez déployer la console de gestion dans un projet producteur de services (côté gestion Google Cloud) et déployer le dispositif de sauvegarde/récupération dans un projet client de service (côté client). Pour en savoir plus sur la sauvegarde et la reprise après sinistre, consultez la page Configurer et planifier un déploiement de sauvegarde et de reprise après sinistre. Pour afficher la définition d'un producteur de services et d'un client de service, consultez le glossaire Google Cloud.

Remarque :Vous ne pouvez pas déployer ces deux composants à l'aide des commandes CLI gcloud ni de Terraform.

Avant de commencer

Pour installer le service de sauvegarde et de reprise après sinistre de Google Cloud, vous devez effectuer les étapes de configuration suivantes avant de démarrer le déploiement:

1. Activez une connexion d'accès aux services privés. Vous devez établir cette connexion avant de pouvoir démarrer l'installation. Même si vous avez déjà configuré un sous-réseau d'accès aux services privés, celui-ci doit au minimum comporter un sous-réseau /23. Par exemple, si vous avez déjà configuré un sous-réseau /24 pour la connexion d'accès aux services privés, nous vous recommandons d'ajouter un sous-réseau /23. Mieux encore, vous pouvez ajouter un sous-réseau /20 pour vous assurer de pouvoir ajouter d'autres services ultérieurement.
2. Configurez Cloud DNS pour qu'il soit accessible dans le réseau VPC où vous déployez le dispositif de sauvegarde/récupération. Cela garantit une résolution correcte de googleapis.com (via une recherche privée ou publique).
3. Configurez des routes réseau par défaut et des règles de pare-feu pour autoriser le trafic de sortie vers *.googleapis.com (via des adresses IP publiques) ou private.googleapis.com (199.36.153.8/30) sur le port TCP 443, ou une sortie explicite pour 0.0.0.0/0. Là encore, vous devez configurer les routes et le pare-feu dans le réseau VPC où vous installez votre appareil de sauvegarde/récupération. Nous vous recommandons également d'utiliser l'accès privé à Google. Pour en savoir plus, consultez la page Configurer l'accès privé à Google.
4. Activez les API suivantes dans votre projet client :
   • API Compute Engine
   • API Cloud Key Management Service (KMS)
   • API Cloud Resource Manager (pour le projet hôte et le projet de service, le cas échéant)
   • API Identity and Access Management
   • API Workflows
   • API Cloud Logging
5. Si vous avez activé des règles d'administration, veillez à configurer les éléments suivants :
   • constraints/cloudkms.allowedProtectionLevels incluent SOFTWARE ou ALL.
6. Configurez les règles de pare-feu suivantes :
   • Ingress depuis le dispositif de sauvegarde/récupération du VPC Compute Engine vers l'hôte Linux (agent) sur le port TCP-5106.
   • Si vous utilisez un disque de sauvegarde par blocs avec iSCSI, sortez de l'hôte Linux (agent) de la solution Bare Metal vers le dispositif de sauvegarde/récupération du VPC Compute Engine sur le port TCP-3260.
   • Si vous utilisez un disque de sauvegarde NFS ou dNFS, sortez de l'hôte Linux (agent) de la solution Bare Metal vers le dispositif de sauvegarde/récupération du VPC Compute Engine sur les ports suivants :
     • TCP/UDP-111 (RPCBIN)
     • TCP/UDP-756 (état)
     • TCP/UDP-2049 (nfs)
     • TCP/UDP-4001 (installé)
     • TCP/UDP-4045 (Nlockmgr)
7. Configurez Google Cloud DNS pour résoudre les noms d'hôte et les domaines de la solution Bare Metal, afin d'assurer la cohérence de la résolution des noms entre les serveurs, les VM et les ressources basées sur Compute Engine de la solution Bare Metal, tels que le service de sauvegarde et de reprise après sinistre.

Installer la console de gestion des sauvegardes et de la reprise après sinistre

1. Activez l'API Backup and DR Service si ce n'est pas déjà fait.

2. Dans la console Google Cloud, utilisez le menu de navigation pour accéder à la section Opérations, puis sélectionnez Sauvegarde et reprise après sinistre:

   

3. Sélectionnez la connexion d'accès aux services privés que vous avez créée précédemment.

4. Choisissez l'emplacement de la console de gestion des sauvegardes et de la reprise après sinistre. Il s'agit de la région dans laquelle vous déployez l'interface utilisateur de la console de gestion des sauvegardes et de la reprise après sinistre dans un projet producteur de services. Google Cloud détient et gère les ressources de la console de gestion.

5. Choisissez le réseau VPC du projet client de services que vous souhaitez connecter au service de sauvegarde et de reprise après sinistre. Il s'agit généralement d'un VPC partagé ou d'un projet hôte.

6. Au bout d'une heure, l'écran suivant doit s'afficher à la fin du déploiement.

   

   Remarque:L'URL de chaque page de la console de gestion des sauvegardes et de la reprise après sinistre utilise le format suivant:

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com

   Remplacez les variables par les éléments suivants:

   • Numéro de projet de votre projet Google Cloud qui héberge la console de gestion des sauvegardes et de la reprise après sinistre.
   • L'ID généré, figurant entre le numéro de projet et le mot dot dans l'URL de l'API pour la console de gestion des sauvegardes et de la reprise après sinistre.
   • Région dans laquelle se trouve la console de gestion des sauvegardes et de la reprise après sinistre.

Installer l'appareil de sauvegarde/récupération

1. Sur la page Sauvegarde et reprise après sinistre, cliquez sur Se connecter à la console de gestion :

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/
   

2. Sur la page principale de la console de gestion des sauvegardes et de la reprise après sinistre, accédez à la page Appareils:

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#clusters
   

   Remarque :Le numéro de votre projet se trouve dans le tableau de bord de la console Google Cloud. Vous devez utiliser le numéro du projet sur lequel vous avez activé le service de sauvegarde et de reprise après sinistre.

3. Saisissez le nom du dispositif de sauvegarde/récupération. Notez que Google Cloud ajoute automatiquement des nombres aléatoires supplémentaires à la fin du nom une fois le déploiement lancé.

4. Choisissez le projet client dans lequel vous souhaitez installer le dispositif de sauvegarde/récupération.

5. Choisissez la région, la zone et le sous-réseau de votre choix.

6. Sélectionnez un type de stockage. Nous vous recommandons de choisir Disque persistant standard pour les démonstrations de faisabilité et Disque persistant SSD pour un environnement de production.

7. Cliquez sur le bouton Commencer l'installation. Le processus peut prendre une heure pour déployer à la fois la console de gestion des sauvegardes et de la reprise après sinistre, ainsi que le premier dispositif de sauvegarde/récupération.

8. Vous pouvez ajouter d'autres dispositifs de sauvegarde/récupération dans d'autres régions ou zones une fois le processus d'installation initiale terminé.

Configurer la sauvegarde et la reprise après sinistre Google Cloud

Dans cette section, vous allez découvrir la procédure à suivre pour configurer le service de sauvegarde et de reprise après sinistre et protéger vos charges de travail.

Configurer un compte de service

Depuis la version 11.0.2 (version de Sauvegarde et reprise après sinistre de décembre 2022), vous pouvez utiliser un seul compte de service pour exécuter le dispositif de sauvegarde/récupération afin d'accéder aux buckets Cloud Storage et de protéger vos machines virtuelles (VM) Compute Engine (non traitées dans ce document).

Rôles de compte de service

La sauvegarde et la reprise après sinistre Google Cloud utilise Google Cloud Identity and Access Management (IAM) pour l'autorisation et l'authentification des utilisateurs et des comptes de service. Vous pouvez utiliser des rôles prédéfinis pour activer diverses fonctionnalités de sauvegarde. Les deux plus importants sont les suivants:

• Opérateur Cloud Storage de sauvegarde et de reprise après sinistre : attribuez ce rôle aux comptes de service utilisés par un dispositif de sauvegarde/récupération qui se connecte aux bucket Cloud Storage. Ce rôle permet de créer des buckets Cloud Storage pour les sauvegardes d'instantanés Compute Engine et d'accéder aux buckets contenant des données de sauvegarde basées sur un agent existantes pour restaurer les charges de travail.
• Opérateur Compute Engine de sauvegarde et de reprise après sinistre : attribuez ce rôle aux comptes de service utilisés par un dispositif de sauvegarde/récupération afin de créer des instantanés de disques persistants pour les machines virtuelles Compute Engine. En plus de créer des instantanés, ce rôle permet au compte de service de restaurer des VM dans le même projet source ou dans d'autres projets.

Pour trouver votre compte de service, affichez la VM Compute Engine exécutant votre dispositif de sauvegarde/récupération dans votre projet client/de service, et consultez la valeur du compte de service indiquée dans la section Gestion des API et des identités.

Pour attribuer les autorisations appropriées à vos dispositifs de sauvegarde/récupération, accédez à la page Identity and Access Management et attribuez les rôles Identity and Access Management suivants à votre compte de service de dispositif de sauvegarde/récupération.

• Opérateur de sauvegarde et de reprise après sinistre pour Cloud Storage
• Opérateur Compute Engine de sauvegarde et de reprise après sinistre (facultatif)

Configurer des pools de stockage

Les pools de stockage stockent les données dans des emplacements de stockage physiques. Vous devez utiliser Persistent Disk pour vos données les plus récentes (1 à 14 jours) et Cloud Storage pour une conservation à plus long terme (jours, semaines, mois et années).

Cloud Storage

Créez un bucket standard régional ou multirégional à l'emplacement où vous devez stocker les données de sauvegarde.

1. Suivez ces instructions pour créer un bucket Cloud Storage:

   1. Sur la page Buckets Cloud Storage, nommez le bucket.
   2. Sélectionnez votre emplacement de stockage.
   3. Choisissez une classe de stockage : standard, Nearline ou Coldline.
   4. Si vous choisissez le stockage Nearline ou Coldline, définissez le mode Contrôle des accès sur Ultraprécis. Pour le stockage standard, acceptez le mode de contrôle des accès par défaut, Uniforme.

   5. Enfin, ne configurez aucune autre option de protection des données et cliquez sur Créer.

      

2. Ajoutez ensuite ce bucket au dispositif de sauvegarde/récupération. Accédez à la console de gestion des sauvegardes et de la reprise après sinistre.

    https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/
    

3. Sélectionnez l'élément de menu Manage > Storage Pools (Gérer > Pools de stockage).

    https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#pools
    

   

4. Cliquez sur l'option +Add OnVault Pool (Ajouter un pool OnVault).

    https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#addonvaultpool
    

   1. Saisissez un nom dans le champ Nom du pool.
   2. Dans le champ Type de pool, choisissez Google Cloud Storage.
   3. Sélectionnez le dispositif que vous souhaitez associer au bucket Cloud Storage.
   4. Saisissez le nom du bucket Cloud Storage.

   5. Cliquez sur Enregistrer.

      

Pools d'instantanés Persistent Disk

Si vous avez déployé le dispositif de sauvegarde/récupération avec des options standards ou SSD, le pool d'instantanés de disque persistant sera de 4 To par défaut. Si vos bases de données ou vos systèmes de fichiers sources nécessitent un pool de taille plus importante, vous pouvez modifier les paramètres du dispositif de sauvegarde/récupération déployé, ajouter un disque persistant, puis créer un pool personnalisé ou configurer un autre pool par défaut.

Remarque :Vous ne pouvez ajouter un disque persistant qu'à un pool existant ou l'utiliser pour créer un pool. Une fois que vous avez ajouté un disque persistant à un pool (procédure ci-dessous), vous ne pouvez pas supprimer, déplacer ni redimensionner le pool.

1. Accédez à la page Gérer > Appareils.

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#clusters
   

2. Modifiez l'instance "backup-server", puis cliquez sur + Ajouter un disque.

   1. Attribuez un nom au disque.
   2. Sélectionnez un type de disque Vide.
   3. Choisissez l'option "Standard", "Équilibrée" ou "SSD" selon vos besoins.
   4. Saisissez la taille de disque dont vous avez besoin.

   5. Cliquez sur Enregistrer.

      

3. Accédez à la page Gérer > Appareils dans la console de gestion des sauvegardes et de la reprise après sinistre.

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#clusters
   

4. Faites un clic droit sur le nom du système, puis sélectionnez Configure Appliance (Configurer le système) dans le menu.

   

5. Vous pouvez soit ajouter le disque au pool d'instantanés existant (expansion), soit créer un pool (cependant, ne mélangez pas des types de disques persistants dans un même pool). Si vous développez, cliquez sur l'icône en haut à droite du pool que vous souhaitez développer.

   

6. Dans cet exemple, vous allez créer un pool avec l'option Cliquez pour ajouter un pool. Après avoir cliqué sur ce bouton, patientez 20 secondes afin que la page suivante s'ouvre.

   

7. Au cours de cette étape, vous allez configurer votre nouveau pool.

   1. Attribuez un nom au pool, puis cliquez sur l'icône + verte pour y ajouter le disque.
   2. Cliquez sur Envoyer.
   3. Confirmez que vous souhaitez continuer en saisissant PROCEED en majuscules lorsque vous y êtes invité.

   4. Cliquez sur Confirm (Confirmer).

      

8. Votre pool est alors développé ou créé avec le disque persistant.

   Remarque :À ce stade, vous ne pouvez pas déplacer, développer ni supprimer le disque persistant tant que vous n'avez pas supprimé les images de sauvegarde stockées dans ce pool. Contactez le Cloud Customer Care si vous avez besoin d'aide. Sinon, fermez l'onglet du navigateur.

Configurer des plans de sauvegarde

Les plans de sauvegarde vous permettent de configurer deux éléments clés pour sauvegarder n'importe quelle base de données, VM ou système de fichiers. Les plans de sauvegarde intègrent des profils et des modèles.

• Les profils vous permettent de définir quand sauvegarder un élément et pendant combien de temps les données de sauvegarde doivent être conservées.
• Les modèles fournissent un élément de configuration qui vous permet de choisir un dispositif de sauvegarde/récupération et un pool de stockage (Persistent Disk, Cloud Storage, etc.). doit être utilisé pour la tâche de sauvegarde.

Créer un profil

1. Dans la console de gestion des sauvegardes et de la reprise après sinistre, accédez à la page Plans de sauvegarde > Profils.

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#manageprofiles
   

2. Deux profils vont déjà être créés. Vous pouvez utiliser un profil pour les instantanés de VM Compute Engine, et modifier l'autre profil et l'utiliser pour les sauvegardes de la solution Bare Metal. Vous pouvez avoir plusieurs profils, ce qui est utile si vous sauvegardez de nombreuses bases de données nécessitant différents niveaux de disque pour la sauvegarde. Par exemple, vous pouvez créer un pool pour les disques SSD (performances supérieures) et un pool pour les disques persistants standards (performances standards). Pour chaque profil, vous pouvez choisir un pool d'instantanés différent.

3. Effectuez un clic droit sur le profil par défaut nommé LocalProfile et sélectionnez Modifier.

   

4. Apportez les modifications suivantes :

   1. Mettez à jour les paramètres Profiles (Profils) avec un nom de profil et une description plus significatifs. Vous pouvez spécifier le niveau de disque à utiliser, l'emplacement du ou des bucket Cloud Storage, ou toute autre information expliquant l'objectif de ce profil.
   2. Remplacez le pool d'instantanés par le pool développé ou nouveau que vous avez créé précédemment.
   3. Sélectionnez un pool OnVault (bucket Cloud Storage) pour ce profil.

   4. Cliquez sur Enregistrer le profil.

      

Créer un modèle

1. Dans la console de gestion des sauvegardes et de la reprise après sinistre, accédez au menu Plans de sauvegarde > Modèles.

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#managetemplates
   

2. Cliquez sur + Créer un modèle.

   1. Attribuez un nom au modèle.
   2. Sélectionnez Oui dans Autoriser le remplacement des paramètres de règle.
   3. Ajoutez une description pour ce modèle.

   4. Cliquez sur Enregistrer le modèle.

      

3. Dans votre modèle, configurez les éléments suivants:

   1. Dans la section Règles à droite, cliquez sur + Ajouter.
   2. Indiquez un nom de règle.
   3. Cochez la case correspondant aux jours pendant lesquels vous souhaitez que la règle s'exécute ou conservez la valeur par défaut Tous les jours.
   4. Modifiez la fenêtre des jobs que vous souhaitez exécuter au cours de cette période.
   5. Sélectionnez une durée de conservation.

   6. Cliquez sur Paramètres de règles avancés.

      

4. Si vous souhaitez effectuer des sauvegardes des journaux d'archives à intervalles réguliers (par exemple, toutes les 15 minutes) et répliquer les journaux d'archive vers Cloud Storage, vous devez activer les paramètres de stratégie suivants:

   1. Définissez Truncate/Purge Log after (Tronquer/Purger le journal après la sauvegarde) sur Truncate (Tronquer) si c'est ce que vous souhaitez.
   2. Si vous le souhaitez, définissez Activer la sauvegarde du journal de la base de données sur Oui.
   3. Définissez le paramètre RPO (Minutes) sur l'intervalle de sauvegarde des journaux d'archives que vous souhaitez.
   4. Définissez Durée de conservation des sauvegardes des journaux (en jours) sur la durée de conservation souhaitée.
   5. Définissez Répliquer les journaux (utilise la technologie Streamsnap) sur Non.
   6. Définissez Send Logs to OnVault Pool (Envoyer les journaux au pool OnVault) sur Yes (Oui) si vous souhaitez envoyer des journaux à votre bucket Cloud Storage. Sinon, sélectionnez Non.

   7. Cliquez sur Save Changes (Enregistrer les modifications).

      

5. Cliquez sur Mettre à jour la règle pour enregistrer vos modifications.

6. Dans la section OnVault située à droite, effectuez les actions suivantes:

   1. Cliquez sur +Ajouter.
   2. Ajoutez le nom de la règle.
   3. Définissez la durée de conservation en jours, semaines, mois ou années.

   4. Cliquez sur Mettre à jour la règle.

      

7. (Facultatif) Si vous devez ajouter d'autres options de conservation, créez des règles supplémentaires pour la conservation hebdomadaire, mensuelle ou annuelle. Pour ajouter une autre règle de conservation, procédez comme suit:

   1. À droite d'OnVault, cliquez sur + Ajouter.
   2. Ajoutez un nom de règle.
   3. Remplacez la valeur de Ces jours-là par le jour où vous souhaitez déclencher cette tâche.
   4. Définissez la fidélisation en jours, semaines, mois ou années.

   5. Cliquez sur Mettre à jour la règle.

      

8. Cliquez sur Enregistrer le modèle. L'exemple suivant montre une règle d'instantané qui conserve les sauvegardes pendant trois jours avec le niveau Persistent Disk, sept jours pour les tâches OnVault et quatre semaines au total. La sauvegarde hebdomadaire est effectuée le samedi soir.

   

   Remarque :Dans la sauvegarde et la reprise après sinistre, les tâches OnVault quotidiennes et hebdomadaires ne sont pas différentes. Un job hebdomadaire correspond simplement à une tâche quotidienne envoyée par la sauvegarde et la reprise après sinistre à Cloud Storage. Le job hebdomadaire reçoit une valeur de conservation supplémentaire afin que les données n'expirent pas. La fonctionnalité de sauvegarde et de reprise après sinistre conserve les images du samedi soir dans Cloud Storage pendant huit jours et quatre semaines.

Sauvegarder une base de données Oracle

L'architecture de sauvegarde et de reprise après sinistre de Google Cloud fournit une sauvegarde Oracle cohérente et incrémentielle ininterrompue sur Google Cloud, ainsi que des fonctionnalités de récupération et de clonage instantanées pour les bases de données Oracle de plusieurs téraoctets.

La sauvegarde et la reprise après sinistre Google Cloud utilisent les API Oracle suivantes:

• API de copie d'image RMAN : il est beaucoup plus rapide de restaurer une copie d'image d'un fichier de données, car la structure physique du fichier de données existe déjà. La directive Recovery Manager (RMAN) BACKUP AS COPY crée des copies d'image pour tous les fichiers de données de l'ensemble de la base de données et conserve le format de fichier de données.
• API ASM et CRS : utilisez les API ASM (Automatic Storage Management) et CRS (Cluster Ready Services) pour gérer le groupe de disques de sauvegarde ASM.
• API de sauvegarde des journaux d'archive RMAN : cette API génère des journaux d'archive, les sauvegarde sur un disque de préproduction, puis les supprime définitivement de l'emplacement de l'archive de production.

Configurer les hôtes Oracle

Les étapes de configuration de vos hôtes Oracle incluent l'installation de l'agent, l'ajout des hôtes à la sauvegarde et à la reprise après sinistre, la configuration des hôtes et la découverte de la ou des bases de données Oracle. Une fois que tout est en place, vous pouvez effectuer des sauvegardes de la base de données Oracle vers la sauvegarde et la reprise après sinistre.

Installer l'agent de sauvegarde

L'installation de l'agent de sauvegarde et de reprise après sinistre est relativement simple. Vous ne devez installer l'agent que la première fois que vous utilisez l'hôte. Vous pouvez ensuite effectuer les mises à niveau suivantes depuis l'interface utilisateur Sauvegarde et reprise après sinistre de la console Google Cloud. Vous devez être connecté en tant qu'utilisateur root ou à une session authentifiée sudo pour effectuer une installation de l'agent. Vous n'avez pas besoin de redémarrer l'hôte pour terminer l'installation.

1. Téléchargez l'agent de sauvegarde à partir de l'interface utilisateur ou de la page Gérer > Appareils.

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#clusters
   

2. Effectuez un clic droit sur le nom du dispositif de sauvegarde/récupération, puis sélectionnez Configurer l'appareil. Une nouvelle fenêtre de navigateur s'ouvre.

   

3. Cliquez sur l'icône Linux 64 bits pour télécharger l'agent de sauvegarde sur l'ordinateur qui héberge votre session de navigateur. Utilisez scp (copie sécurisée) pour déplacer le fichier de l'agent téléchargé vers les hôtes Oracle pour l'installation.

   

4. Vous pouvez également stocker l'agent de sauvegarde dans un bucket Cloud Storage, activer les téléchargements et utiliser les commandes wget ou curl pour télécharger l'agent directement sur vos hôtes Linux.

   curl -o agent-Linux-latestversion.rpm https://storage.googleapis.com/backup-agent-images/connector-Linux-11.0.2.9595.rpm
   

5. Exécutez la commande rpm -ivh pour installer l'agent de sauvegarde.

   Il est très important de copier la clé secrète générée automatiquement. À l'aide de la console de gestion des sauvegardes et de la reprise après sinistre, vous devez ajouter la clé secrète aux métadonnées de l'hôte.

   La sortie de la commande ressemble à ceci :

   [oracle@host `~]# sudo rpm -ivh agent-Linux-latestversion.rpm
   Verifying... ################################# [100%]
   Preparing... ################################# [100%]
   Updating / installing…
     1:udsagent-11.0.2-9595 ################################# [100%]
   Created symlink /etc/systemd/system/multi-user.target.wants/udsagent.service → /usr/lib/systemd/system/udsagent.service.
   Action Required:
   -- Add this host to Backup and DR management console to backup/recover workloads from/to this host. You can do this by navigating to Manage->Hosts->Add Host on your management console.
   -- A secret key is required to complete this process. Please use b010502a8f383cae5a076d4ac9e868777657cebd0000000063abee83 (valid for 2 hrs) to register this host.
   -- A new secret key can be generated later by running: '/opt/act/bin/udsagent secret --reset --restart
   

6. Si vous utilisez la commande iptables, ouvrez les ports du pare-feu de l'agent de sauvegarde (TCP 5106) et des services Oracle (TCP 1521):

   sudo iptables -A INPUT -p tcp --dport 5106 -j ACCEPT
   sudo iptables -A INPUT -p tcp --dport 1521 -j ACCEPT
   sudo firewall-cmd --permanent --add-port=5106/tcp
   sudo firewall-cmd --permanent --add-port=1521/tcp
   sudo firewall-cmd --reload
   

Ajouter des hôtes à la sauvegarde et à la reprise après sinistre

1. Dans la console de gestion des sauvegardes et de la reprise après sinistre, accédez à Gérer > Hôtes.

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#hosts
   

   1. Cliquez sur + Ajouter un hôte.
   2. Ajoutez le nom d'hôte.
   3. Ajoutez une adresse IP pour l'hôte, puis cliquez sur le bouton + pour confirmer la configuration.
   4. Cliquez sur le ou les dispositifs dans lesquels vous souhaitez ajouter l'hôte.
   5. Collez la clé secrète. Vous devez effectuer cette tâche moins de deux heures après l'installation de l'agent de sauvegarde et la génération de la clé secrète.

   6. Cliquez sur Ajouter pour enregistrer l'hôte.

      

2. Si vous recevez un message d'erreur ou un message de réussite partiel, essayez les solutions suivantes:

   

   1. La clé secrète de chiffrement de l'agent de sauvegarde a peut-être expiré. Vous n'avez pas ajouté la clé secrète à l'hôte dans les deux heures suivant sa création. Vous pouvez générer une nouvelle clé secrète sur l'hôte Linux à l'aide de la syntaxe de ligne de commande suivante:

      /opt/act/bin/udsagent secret --reset --restart
      

   2. Le pare-feu qui autorise la communication entre le dispositif de sauvegarde/récupération et l'agent installé sur l'hôte n'est peut-être pas configuré correctement. Suivez la procédure pour ouvrir les ports du pare-feu de l'agent de sauvegarde et des services Oracle.

   3. Il est possible que la configuration ntp (Network Time Protocol) de vos hôtes Linux soit mal configurée. Vérifiez que vos paramètres NTP sont corrects.

3. Lorsque vous aurez résolu le problème sous-jacent, vous devriez constater que l'état du certificat passe de N/A à Valide.

   

Configurer les hôtes

1. Dans la console de gestion des sauvegardes et de la reprise après sinistre, accédez à Gérer > Hôtes.

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#hosts
   

2. Effectuez un clic droit sur l'hôte Linux dans lequel vous souhaitez sauvegarder vos bases de données Oracle, puis sélectionnez Modifier.

3. Cliquez sur Staging Disk Format (Format de disque de préproduction) et choisissez NFS.

   

   Remarque :Si vous préférez utiliser des disques de préproduction ASM (également appelés sauvegarde sur des disques au format ASM), sélectionnez Block (Bloquer) pour le paramètre Staging Disk Format (Format de disque de préproduction).

4. Faites défiler la page vers le bas jusqu'à la section Applications découvertes, puis cliquez sur Découvrir des applications pour lancer le processus de découverte entre les dispositifs et les agents.

   

5. Cliquez sur Découvrir pour commencer le processus. Le processus de découverte prend jusqu'à cinq minutes. Une fois l'opération terminée, les systèmes de fichiers et les bases de données Oracle détectés s'affichent dans la fenêtre des applications.

   

6. Cliquez sur Enregistrer pour mettre à jour les modifications apportées à vos hôtes.

Préparer l'hôte Linux

En installant des packages d'utilitaires iSCSI ou NFS sur votre hôte basé sur un système d'exploitation Linux, vous pouvez mapper un disque de préproduction à un appareil qui écrit les données de sauvegarde. Exécutez les commandes suivantes pour installer les utilitaires iSCSI et NFS. Bien que vous puissiez utiliser l'un ou l'autre des ensembles d'utilitaires, ou les deux, cette étape garantit que vous disposez de ce dont vous avez besoin, quand vous en avez besoin.

Conseil:Quand dois-je utiliser iSCSI, NFS ou Oracle Direct NFS (dNFS) ?

• Utilisez iSCSI lorsque vous souhaitez enregistrer votre sauvegarde sur un disque de préproduction de sauvegarde basé sur des blocs (par exemple, sauvegarde dans un système de fichiers) ou lorsque vous devez stocker le format de disque de préproduction de sauvegarde sur un groupe de disques ASM (sur lequel vous utilisez le dispositif de sauvegarde/récupération pour stocker, créer et gérer des sauvegardes).
• Utilisez NFS, également appelé Kernel NFS, pour augmenter les performances de sauvegarde et de restauration. Vous pouvez exploiter plusieurs sessions TCP avec NFS, mais cette méthode de stockage de fichiers n'est compatible qu'avec l'option de disque de préproduction de sauvegarde du système de fichiers.
• Utilisez Direct NFS (dNFS) lorsque vous souhaitez déployer l'amélioration d'Oracle sur NFS, qui est plus rapide que le NFS standard et améliore le débit de sauvegarde et de restauration. Toutefois, dNFS n'est compatible qu'avec l'option de disque de préproduction de sauvegarde du système de fichiers. Pour que la configuration de dNFS soit prise en compte au redémarrage, vous devez arrêter la base de données.

• Pour installer les utilitaires iSCSI, exécutez la commande suivante:

  sudo yum install -y iscsi-initiator-utils
  

• Pour installer les utilitaires NFS, exécutez la commande suivante:

  sudo yum install -y nfs-utils
  

  Préparer la base de données Oracle

Dans ce guide, nous partons du principe que vous avez déjà configuré une instance et une base de données Oracle. La sauvegarde et la reprise après sinistre Google Cloud sont compatibles avec la protection des bases de données exécutées sur des systèmes de fichiers, ASM, des clusters d'application réelle (RAC) et de nombreuses autres configurations. Pour en savoir plus, consultez la page Sauvegarde et reprise après sinistre pour les bases de données Oracle.

Vous devez configurer quelques éléments avant de démarrer le job de sauvegarde. Certaines de ces tâches sont facultatives, mais nous vous recommandons les paramètres suivants pour des performances optimales:

1. Utilisez SSH pour vous connecter à l'hôte Linux et connectez-vous en tant qu'utilisateur Oracle avec les privilèges su.

2. Définissez l'environnement Oracle sur votre instance spécifique:

   . oraenv
   ORACLE_SID = [ORCL] ?
   The Oracle base remains unchanged with value /u01/app/oracle
   

3. Connectez-vous à SQL*Plus avec le compte sysdba:

   sqlplus / as sysdba
   

4. Exécutez les commandes suivantes pour activer le mode ARCHIVELOG : Le résultat des commandes ressemble à ce qui suit:

   SQL> shutdown
   
   Database closed.
   Database dismounted.
   ORACLE instance shut down.
   
   SQL> startup mount
   
   ORACLE instance started.
   
   Total System Global Area 2415918600 bytes
   Fixed Size 9137672 bytes
   Variable Size 637534208 bytes
   Database Buffers 1761607680 bytes
   Redo Buffers 7639040 bytes
   Database mounted.
   
   SQL> alter database archivelog;
   
   Database altered.
   
   SQL> alter database open;
   
   Database altered.
   
   SQL> archive log list;
   Database log mode Archive Mode
   Automatic archival Enabled
   Archive destination /u01/app/oracle/product/19c/dbhome_1/dbs/arch
   Oldest online log sequence 20
   Next log sequence to archive 22
   Current log sequence 22
   
   SQL> alter pluggable database ORCLPDB save state;
   
   Pluggable database altered.
   

5. Configurez la commande NFS directe pour l'hôte Linux:

   cd $ORACLE_HOME/rdbms/lib
   make -f [ins_rdbms.mk](http://ins_rdbms.mk/) dnfs_on
   

6. Configurez le suivi des modifications des blocages. Vérifiez d'abord si elle est activée ou désactivée. Dans l'exemple suivant, le suivi des modifications de blocage est désactivé:

   SQL> select status,filename from v$block_change_tracking;
   
   STATUS     FILENAME
   ---------- ------------------------------------------------------------------
   DISABLED
   

   Exécutez la commande suivante lorsque vous utilisez ASM :

   SQL> alter database enable block change tracking using file +ASM_DISK_GROUP_NAME/DATABASE_NAME/DBNAME.bct;
   
   Database altered.
   

   Exécutez la commande suivante lorsque vous utilisez un système de fichiers:

   SQL> alter database enable block change tracking using file '$ORACLE_HOME/dbs/DBNAME.bct';;
   
   Database altered.
   

   Vérifiez que le suivi des modifications des blocages est désormais activé:

   SQL> select status,filename from v$block_change_tracking;
   
   STATUS     FILENAME
   ---------- ------------------------------------------------------------------
   ENABLED    +DATADG/ORCL/CHANGETRACKING/ctf.276.1124639617
   

Protéger une base de données Oracle

1. Dans la console de gestion des sauvegardes et de la reprise après sinistre, accédez à la page App Manager > Applications.

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#applications
   

2. Effectuez un clic droit sur le nom de la base de données Oracle que vous souhaitez protéger, puis sélectionnez Gérer le plan de sauvegarde dans le menu.

3. Sélectionnez le modèle et le profil que vous souhaitez utiliser, puis cliquez sur Appliquer un plan de sauvegarde.

   

4. Lorsque vous y êtes invité, définissez les paramètres avancés spécifiques à Oracle et à RMAN nécessaires pour votre configuration. Lorsque vous avez terminé, cliquez sur Appliquer un plan de sauvegarde.

   Par exemple, le nombre de canaux est défini par défaut sur 2. Ainsi, si vous avez un plus grand nombre de cœurs de processeur, vous pouvez augmenter le nombre de canaux pour les opérations de sauvegarde parallèles et définir un nombre supérieur.

   Pour en savoir plus sur les paramètres avancés, consultez Configurer les détails et les paramètres d'une application pour les bases de données Oracle.

   

Remarque :Lorsque vous définissez le champ Convertir le format ASM en format du système de fichiers sur Oui, la copie de sauvegarde est créée dans un format de système de fichiers, par opposition à un format de disque ASM dans le pool d'instantanés de sauvegarde et de reprise après sinistre.

En plus de ces paramètres, vous pouvez modifier le protocole utilisé par le disque de préproduction pour mapper le disque du dispositif de sauvegarde à l'hôte. Accédez à Gérer > Hôtes, puis sélectionnez l'hôte que vous souhaitez modifier. Cochez l'option Staging Disk Format to Guest (Mettre le format de disque en mode Invité). Par défaut, le format Block est sélectionné, ce qui mappe le disque de préproduction via iSCSI. Sinon, il peut être remplacé par NFS. Le disque de préproduction utilise alors le protocole NFS.

Les paramètres par défaut dépendent du format de votre base de données. Si vous utilisez ASM, le système utilise iSCSI pour envoyer la sauvegarde à un groupe de disques ASM. Si vous utilisez un système de fichiers, il utilise iSCSI pour envoyer la sauvegarde à un système de fichiers. Si vous souhaitez utiliser NFS ou Direct NFS (dNFS), vous devez définir les paramètres Hôtes du disque de préproduction sur NFS. Si vous utilisez le paramètre par défaut, tous les disques de préproduction de sauvegarde utilisent le format de stockage de blocs et iSCSI.

Démarrer le job de sauvegarde

1. Dans la console de gestion des sauvegardes et de la reprise après sinistre, accédez à la page App Manager > Applications.

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#applications
   

2. Effectuez un clic droit sur la base de données Oracle que vous souhaitez protéger, puis sélectionnez Gérer le plan de sauvegarde dans le menu.

3. Cliquez sur le menu Snapshot (Instantané) à droite, puis sur Run Now (Exécuter). Cette opération lance un job de sauvegarde à la demande.

   

4. Pour surveiller l'état du job de sauvegarde, accédez au menu Monitor > Jobs (Surveiller > Jobs), puis affichez l'état. L'affichage d'une tâche dans la liste peut prendre entre 5 et 10 secondes. Voici un exemple de tâche en cours d'exécution:

   

5. Lorsqu'une tâche aboutit, vous pouvez utiliser les métadonnées pour afficher les détails d'une tâche spécifique.

   • Appliquez des filtres et ajoutez des termes de recherche pour trouver les emplois qui vous intéressent. L'exemple suivant utilise les filtres Succeeded et Past Day, ainsi qu'une recherche sur l'hôte test1.

   

6. Pour examiner de plus près une tâche spécifique, cliquez dessus dans la colonne Tâche. Dans la fenêtre qui s'ouvre, Comme vous pouvez le voir dans l'exemple suivant, chaque tâche de sauvegarde capture une grande quantité d'informations.

   

Installer et restaurer une base de données Oracle

La sauvegarde et la reprise après sinistre Google Cloud offrent un certain nombre de fonctionnalités différentes pour accéder à une copie d'une base de données Oracle. Les deux principales méthodes sont les suivantes:

• Installations compatibles avec les applications
• Restaurations (installation et migration, restauration traditionnelle)

Chacune de ces méthodes présente des avantages différents. Vous devez donc choisir celle que vous souhaitez utiliser en fonction de votre cas d'utilisation, des exigences de performances et de la durée de conservation de la copie de la base de données. Les sections suivantes contiennent des recommandations pour chaque fonctionnalité.

Installations compatibles avec les applications

Les montages permettent d'accéder rapidement à une copie virtuelle d'une base de données Oracle. Vous pouvez configurer une installation lorsque les performances ne sont pas critiques et que la copie de la base de données n'est valable que de quelques heures à quelques jours.

Le principal avantage d'une installation est qu'elle ne consomme pas beaucoup de stockage supplémentaire. À la place, l'installation utilise un instantané du pool de disques de sauvegarde, qui peut être un pool d'instantanés sur un disque persistant ou un pool OnVault dans Cloud Storage. La fonctionnalité d'instantané de copie virtuelle réduit le temps d'accès aux données, car il n'est pas nécessaire de les copier au préalable. Le disque de sauvegarde gère toutes les lectures, et un disque du pool d'instantanés stocke toutes les écritures. Par conséquent, l'installation de copies virtuelles est rapide et n'écrase pas la copie du disque de sauvegarde. Les installations sont idéales pour le développement, les tests et les activités de base de données qui nécessitent de valider les modifications ou les mises à jour de schéma avant de les déployer en production.

Installer une base de données Oracle

1. Dans la console de gestion de la sauvegarde et de la reprise après sinistre, accédez à la page Sauvegarde et récupération > Récupérer.

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#recover/selectapp
   

2. Dans la liste Application, recherchez la base de données que vous souhaitez installer, effectuez un clic droit sur son nom, puis cliquez sur Suivant:

   

3. La vue chronologique s'affiche et affiche toutes les images disponibles à un moment précis. Vous pouvez également faire défiler la page vers l'arrière pour voir les images de conservation à long terme si elles n'apparaissent pas dans la vue en mode Rampe. Par défaut, le système sélectionne l'image la plus récente.

   

4. Si vous préférez afficher une vue Tableau pour les images à un moment précis, cliquez sur l'option Tableau pour modifier la vue:

   

5. Recherchez l'image souhaitée, puis sélectionnez Monter:

   

6. Choisissez les Options d'application pour la base de données que vous installez.

   1. Sélectionnez Target Host (Hôte cible) dans le menu déroulant. Les hôtes apparaissent dans cette liste si vous les avez déjà ajoutés.
   2. (Facultatif) Saisissez un libellé.
   3. Dans le champ SID de la base de données cible, saisissez l'identifiant de la base de données cible.
   4. Définissez le Nom d'utilisateur sur Oracle. Ce nom devient le nom d'utilisateur du système d'exploitation pour l'authentification.
   5. Accédez au répertoire d'accueil Oracle. Pour cet exemple, utilisez /u01/app/oracle/product/19c/dbhome_1.
   6. Si vous configurez les journaux de base de données à sauvegarder, le délai de rollback devient disponible. Cliquez sur le sélecteur d'horloge/d'heure et choisissez le point de défilement avant.
   7. L'option Restaurer avec la récupération est activée par défaut. Cette option permet d'installer et d'ouvrir la base de données pour vous.

7. Une fois les informations saisies, cliquez sur Envoyer pour démarrer le processus d'installation.

   

Surveiller l'avancement et la réussite d'un job

1. Vous pouvez surveiller la tâche en cours d'exécution en accédant à la page Monitor > Jobs (Surveiller > Tâches).

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#jobs
   

   La page affiche l'état et le type de job.

   

2. Une fois la tâche d'installation terminée, vous pouvez afficher les détails de la tâche en cliquant sur son numéro de tâche:

   

3. Pour afficher les processus pmon du SID que vous avez créé, connectez-vous à l'hôte cible et exécutez la commande ps -ef |grep pmon. Dans l'exemple de sortie suivant, la base de données SCHTEST est opérationnelle et porte l'ID de processus 173953.

   [root@test2 ~]# ps -ef |grep pmon
   oracle 1382 1 0 Dec23 ? 00:00:28 asmpmon+ASM
   oracle 56889 1 0 Dec29 ? 00:00:06 ora_pmon_ORCL
   oracle 173953 1 0 09:51 ? 00:00:00 ora_pmon_SCHTEST
   root 178934 169484 0 10:07 pts/0 00:00:00 grep --color=auto pmon
   

Unmount an Oracle database

After you finish using the database, you should unmount and delete the database. There are two methods to find a mounted database:

1. Go to App Manager > Active Mounts page.

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#activemounts
   

   Cette page contient une vue globale de toutes les applications installées (systèmes de fichiers et bases de données) actuellement utilisées.

   1. Effectuez un clic droit sur le support à nettoyer, puis sélectionnez Désinstaller et supprimer dans le menu. Cette action ne supprimera pas les données de sauvegarde. Elle ne supprime que la base de données installée virtuelle de l'hôte cible et le disque de cache d'instantanés contenant les écritures stockées pour la base de données.

      

2. Accédez à la page App Manager > Applications.

    https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#applications
    

   1. Effectuez un clic droit sur l'application source (base de données), puis sélectionnez Access (Accès).
   2. Sur la rampe de gauche, vous voyez un cercle gris contenant un chiffre qui indique le nombre de montages actifs à partir de ce moment-là. Cliquez sur cette image pour afficher un nouveau menu.
   3. Cliquez sur Actions.
   4. Cliquez sur Unmount and Delete (Désinstaller et supprimer).
   5. Cliquez sur Envoyer, puis confirmez l'opération sur l'écran suivant.

   6. Quelques minutes plus tard, le système supprime la base de données de l'hôte cible, puis nettoie et supprime tous les disques. Cette action libère tout espace disque dans le pool d'instantanés utilisé pour les écritures sur le disque de rétablissement pour les installations actives.

      

3. Vous pouvez surveiller les jobs désinstallés de la même manière que n'importe quel autre job. Accédez au menu Monitor > Jobs (Surveiller > Tâches) pour surveiller la progression de la désinstallation de la tâche et confirmer qu'elle est terminée.

    https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#jobs
    

   

4. Si vous supprimez accidentellement la base de données Oracle manuellement ou si vous arrêtez la base de données avant d'exécuter la tâche Unmount and Delete, effectuez à nouveau la tâche Unmount and Delete et sélectionnez l'option Force Unmount sur l'écran de confirmation. Cette action supprime de force le disque de restauration de préproduction de l'hôte cible et supprime le disque du pool d'instantanés.

   

Restaurations

Vous utilisez des restaurations pour récupérer des bases de données de production en cas de problème ou de corruption, et vous devez copier tous les fichiers de la base de données vers un hôte local à partir d'une copie de sauvegarde. Vous effectuez normalement une restauration après un événement de type sinistre ou pour des copies de test hors production. Dans ce cas, vos clients doivent généralement attendre que vous ayez copié les fichiers précédents sur l'hôte source avant de redémarrer leurs bases de données. Toutefois, Google Cloud Sauvegarde et reprise après sinistre est également compatible avec une fonctionnalité de restauration (copier des fichiers et démarrer la base de données), ainsi qu'une fonctionnalité d'installation et de migration qui vous permet d'installer la base de données (le temps d'accès est rapide) et de copier des fichiers de données sur l'ordinateur local pendant que la base de données est installée et accessible. La fonctionnalité d'installation et de migration est utile pour les scénarios d'objectif de temps de récupération (RTO).

Remarque :Si vous configurez des sauvegardes de journaux d'archive dans votre plan de sauvegarde, toutes les fonctionnalités permettent de déployer les journaux dans le cadre du processus de récupération.

Installer et migrer

La récupération basée sur l'installation et la migration comporte deux phases:

1. Phase 1 : la phase d'installation de restauration permet d'accéder instantanément à la base de données à partir de la copie installée.
2. Phase 2 : la phase de migration de restauration migre la base de données vers l'emplacement de stockage de production pendant qu'elle est en ligne.

Restauration de l'installation – Phase 1

Cette phase vous permet d'accéder instantanément à la base de données à partir d'une image sélectionnée présentée par le dispositif de sauvegarde/récupération.

• Une copie de l'image de back-up sélectionnée est mappée sur le serveur de base de données cible et présentée à la couche ASM ou à la couche de système de fichiers en fonction du format de l'image de back-up de la base de données source.
• Utilisez l'API RMAN pour effectuer les tâches suivantes :
  • Restaurez le fichier de contrôle et le fichier journal de rétablissement dans le fichier de contrôle local spécifié et l'emplacement du fichier de rétablissement (groupe de disques ou système de fichiers ASM).
  • Basculez la base de données sur la copie de l'image présentée par le dispositif de sauvegarde/récupération.
  • Déployez tous les journaux d'archive disponibles vers le point de récupération spécifié.
  • Ouvrez la base de données en mode lecture et écriture.
• La base de données s'exécute à partir de la copie mappée de l'image de sauvegarde présentée par le dispositif de sauvegarde/récupération.
• Le fichier de contrôle et le fichier journal de rétablissement de la base de données sont placés sur l'emplacement de stockage de production local sélectionné (groupe de disques ou système de fichiers ASM) sur la cible.
• Après une opération de restauration ou d'installation réussie, la base de données devient disponible pour les opérations de production. Vous pouvez utiliser l'API de déplacement de fichiers de données en ligne d'Oracle pour replacer les données dans l'emplacement de stockage de production (groupe de disques ou système de fichiers ASM) lorsque la base de données et l'application sont opérationnelles.

Migration avec restauration – Phase 2

Déplace le fichier de données de la base de données en ligne vers le stockage de production:

• La migration des données s'exécute en arrière-plan. Utilisez l'API Oracle Online Datafile Movement pour migrer les données.
• Vous déplacez les fichiers de données de la copie présentée lors de la sauvegarde et de reprise après sinistre de l'image de sauvegarde vers l'espace de stockage de la base de données cible sélectionnée (groupe de disques ou système de fichiers ASM).
• Une fois le job de migration terminé, le système supprime de la cible et annule le mappage de la copie de l'image de back-up présentée lors de la sauvegarde et de la reprise après sinistre (groupe de disques ou système de fichiers ASM), puis la base de données s'exécute à partir de votre espace de stockage de production.

Pour en savoir plus sur l'installation et la migration de la récupération, consultez la page Installer et migrer une image de sauvegarde Oracle pour une récupération instantanée sur n'importe quelle cible.

Restaurer une base de données Oracle

1. Dans la console de gestion de la sauvegarde et de la reprise après sinistre, accédez à la page Sauvegarde et récupération > Récupérer.

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#recover/selectapp
   

2. Dans la liste Application, effectuez un clic droit sur le nom de la base de données que vous souhaitez restaurer, puis sélectionnez Suivant:

   

3. La vue chronologique de la rampe s'affiche et affiche toutes les images disponibles à un moment précis. Vous pouvez également faire défiler la page vers l'arrière si vous avez besoin d'afficher les images de conservation à long terme qui n'apparaissent pas sur la rampe. Le système sélectionne toujours l'image la plus récente par défaut.

   Pour restaurer une image, cliquez sur le menu Installer et sélectionnez Restaurer:

   

4. Choisissez vos options de restauration.

   1. Sélectionnez la durée du rollback. Cliquez sur l'horloge et choisissez le moment souhaité.
   2. Saisissez le nom d'utilisateur que vous prévoyez d'utiliser pour Oracle.
   3. Si votre système utilise l'authentification de base de données, saisissez un mot de passe.

   4. Pour démarrer la tâche, cliquez sur Envoyer.

      

5. Saisissez PERTE DE DONNÉES pour confirmer que vous souhaitez écraser la base de données source, puis cliquez sur Confirmer.

   

Surveiller l'avancement et la réussite d'un job

1. Pour surveiller le job, accédez à la page Monitor > Jobs (Surveiller > Jobs).

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#jobs
   

2. Une fois la tâche terminée, cliquez sur le numéro de tâche pour examiner les détails et les métadonnées de la tâche.

   

Protéger la base de données restaurée

Une fois le job de restauration de base de données terminé, le système ne sauvegarde pas automatiquement la base de données après sa restauration. En d'autres termes, lorsque vous restaurez une base de données qui disposait précédemment d'un plan de sauvegarde, ce plan ne s'active pas par défaut.

1. Pour vérifier que le plan de sauvegarde n'est pas en cours d'exécution, accédez à la page App Manager > Applications.

   https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#applications
   

2. Recherchez la base de données restaurée dans la liste. L'icône de protection passe du vert au jaune, ce qui indique que le système n'est pas programmé pour exécuter des tâches de sauvegarde pour la base de données.

   

3. Pour protéger la base de données restaurée, recherchez dans la colonne Application la base de données à protéger. Effectuez un clic droit sur le nom de la base de données, puis sélectionnez Gérer le plan de sauvegarde.

   

4. Réactivez le job de sauvegarde planifié pour la base de données restaurée.

   1. Cliquez sur le menu Appliquer et sélectionnez Activer.

   2. Confirmez les paramètres avancés Oracle, puis cliquez sur Enable backup plan (Activer le plan de sauvegarde).

      

Dépannage et optimisation

Cette section fournit des conseils utiles pour vous aider à dépanner vos sauvegardes Oracle, à optimiser votre système et à ajuster les environnements RAC et Data Guard.

Résoudre les problèmes liés à la sauvegarde Oracle

Les configurations Oracle contiennent un certain nombre de dépendances pour garantir la réussite de la tâche de sauvegarde. Les étapes suivantes fournissent plusieurs suggestions pour configurer les instances, les écouteurs et les bases de données Oracle afin de garantir la réussite de l'opération.

1. Pour vérifier que l'écouteur Oracle du service et de l'instance que vous souhaitez protéger est configuré et en cours d'exécution, exécutez la commande lsnrctl status:

   [oracle@test2 lib]$ lsnrctl status
   
   LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 29-DEC-2022 07:43:37
   
   Copyright (c) 1991, 2021, Oracle. All rights reserved.
   
   Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
   STATUS of the LISTENER
   ------------------------
   Alias                     LISTENER
   Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
   Start Date                23-DEC-2022 20:34:17
   Uptime                    5 days 11 hr. 9 min. 20 sec
   Trace Level               off
   Security                  ON: Local OS Authentication
   SNMP                      OFF
   Listener Parameter File   /u01/app/19c/grid/network/admin/listener.ora
   Listener Log File         /u01/app/oracle/diag/tnslsnr/test2/listener/alert/log.xml
   Listening Endpoints Summary...
    (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=test2.localdomain)(PORT=1521)))
    (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
   Services Summary...
   Service "+ASM" has 1 instance(s).
    Instance "+ASM", status READY, has 1 handler(s) for this service...
   Service "+ASM_DATADG" has 1 instance(s).
    Instance "+ASM", status READY, has 1 handler(s) for this service...
   Service "ORCL" has 1 instance(s).
    Instance "ORCL", status READY, has 1 handler(s) for this service...
   Service "ORCLXDB" has 1 instance(s).
    Instance "ORCL", status READY, has 1 handler(s) for this service...
   Service "f085620225d644e1e053166610ac1c27" has 1 instance(s).
    Instance "ORCL", status READY, has 1 handler(s) for this service...
   Service "orclpdb" has 1 instance(s).
    Instance "ORCL", status READY, has 1 handler(s) for this service...
   The command completed successfully
   

2. Vérifiez que vous avez configuré la base de données Oracle en mode ARCHIVELOG. Si la base de données s'exécute dans un mode différent, il est possible que des jobs ayant échoué s'affichent avec le message Code d'erreur 5556 comme suit:

   

   Remarque :Vous trouverez votre chemin d'accès à la page d'accueil Oracle dans le répertoire /etc/oratab. Vous pouvez également trouver le nom de l'instance de base de données en exécutant la commande ps -ef | grep pmon.

   export ORACLE_HOME=ORACLE_HOME_PATH
   export ORACLE_SID=DATABASE_INSTANCE_NAME
   export PATH=$ORACLE_HOME/bin:$PATH
   
   sqlplus / as sysdba
   SQL> set tab off
   SQL> archive log list;
   
   Database log mode             Archive Mode
   Automatic archival            Enabled
   Archive destination           +FRA
   Oldest online log sequence    569
   Next log sequence to archive  570
   Current log sequence          570
   

3. Activez le suivi des modifications de blocs dans la base de données Oracle. Bien que cela ne soit pas obligatoire pour que la solution fonctionne, l'activation du suivi des modifications de blocs évite d'avoir à effectuer une quantité importante de tâches de post-traitement pour calculer les blocs modifiés et permet de réduire la durée des tâches de sauvegarde:

   SQL> select status,filename from v$block_change_tracking;
   
   STATUS     FILENAME
   ---------- ------------------------------------------------------------------
   ENABLED    +DATADG/ORCL/CHANGETRACKING/ctf.276.1124639617
   

4. Vérifiez que la base de données utilise l'spfile:

   sqlplus / as sysdba
   
   SQL> show parameter spfile
   
   NAME               TYPE        VALUE
   ------------------ ----------- ------------
   spfile             string      +DATA/ctdb/spfilectdb.ora
   

5. Activez Direct NFS (dnfs) pour les hôtes de base de données Oracle. Bien que cela ne soit pas obligatoire, si vous avez besoin de la méthode la plus rapide pour sauvegarder et restaurer les bases de données Oracle, dnfs est le choix privilégié. Pour améliorer davantage le débit, vous pouvez modifier le disque de préproduction par hôte et activer dnfs pour Oracle.

6. Configurez les noms de domaine à résoudre pour les hôtes de base de données Oracle. Si vous n'incluez pas ce paramètre, les commandes RMAN échouent souvent. Voici un exemple du résultat:

   [oracle@test2 lib]$ tnsping ORCL
   
   TNS Ping Utility for Linux: Version 19.0.0.0.0 - Production on 29-DEC-2022 07:55:18
   
   Copyright (c) 1997, 2021, Oracle. All rights reserved.
   
   Used parameter files:
   
   Used TNSNAMES adapter to resolve the alias
   Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = test2.localdomain)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ORCL)))
   OK (0 msec)
   

7. Le champ SERVICE_NAME est important pour les configurations RAC. Le nom du service représente l'alias utilisé pour annoncer le système aux ressources externes qui communiquent avec le cluster. Dans les options Détails et paramètres de la base de données protégée, utilisez le paramètre avancé de nom de service Oracle. Saisissez le nom du service spécifique que vous souhaitez utiliser sur les nœuds qui exécutent la tâche de sauvegarde.

   La base de données Oracle n'utilise le nom du service que pour l'authentification de la base de données. La base de données n'utilise pas le nom du service pour l'authentification du système d'exploitation. Par exemple, le nom de la base de données peut être CLU1_S et le nom de l'instance peut être CLU1_S.

   • Si le nom du service Oracle ne figure pas dans la liste, créez une entrée de nom de service sur le ou les serveurs dans le fichier tnsnames.ora situé dans $ORACLE_HOME/network/admin ou $GRID_HOME/network/admin en ajoutant l'entrée suivante:

     CLU1_S =
     (DESCRIPTION =
     (ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT = 1521))
     (CONNECT_DATA =
     (SERVER = DEDICATED)
     (SERVICE_NAME = CLU1_S)
     ) )
     

   • Si le fichier tnsnames.ora se trouve à un emplacement non standard, indiquez le chemin absolu vers le fichier sur la page Détails et paramètres de l'application décrite dans Configurer les détails et les paramètres de l'application pour les bases de données Oracle.

   • Vérifiez que vous avez correctement configuré l'entrée du nom de service pour la base de données. Connectez-vous à Oracle Linux et configurez l'environnement Oracle:

     TNS_ADMIN=TNSNAMES.ORA_FILE_LOCATION
     tnsping CLU1_S
     

   • Examinez le compte utilisateur de la base de données pour vous assurer que la connexion à l'application de sauvegarde et de reprise après sinistre a réussi:

     sqlplus act_rman_user/act_rman_user@act_svc_dbstd as sysdba
     

   • Sur la page Application Details and Settings (Détails et paramètres de l'application) décrite dans Application Details and Settings for Oracle Databases (Détails et paramètres d'application pour les bases de données Oracle), saisissez le nom du service que vous avez créé (CLU1_S) dans le champ Oracle Service Name (Nom du service Oracle) :

     

8. Le code d'erreur 870 indique que "Les sauvegardes ASM avec ASM sur les disques de préproduction NFS ne sont pas compatibles". Si vous recevez cette erreur, cela signifie que le paramètre approprié n'est pas configuré dans Détails et paramètres pour l'instance à protéger. Dans cette erreur de configuration, l'hôte utilise NFS pour le disque de préproduction, mais la base de données source s'exécute sur ASM.

   

   Pour résoudre ce problème, définissez le champ Convert ASM Format to Filesystem Format (Convertir le format ASM au format du système de fichiers) sur Yes (Oui). Après avoir modifié ce paramètre, exécutez à nouveau le job de sauvegarde.

9. Le code d'erreur 15 indique au système de sauvegarde et de reprise après sinistre "Impossible de se connecter à l'hôte de sauvegarde". Si vous recevez cette erreur, cela indique l'un des trois problèmes suivants:

   • Le pare-feu entre le dispositif de sauvegarde/récupération et l'hôte sur lequel vous avez installé l'agent n'autorise pas le port TCP 5106 (port d'écoute de l'agent).
   • Vous n'avez pas installé l'agent.
   • L'agent n'est pas en cours d'exécution.

   Pour résoudre ce problème, reconfigurez les paramètres du pare-feu si nécessaire et assurez-vous que l'agent fonctionne. Une fois la cause sous-jacente corrigée, exécutez la commande service udsagent status. L'exemple de résultat suivant montre que le service de l'agent de sauvegarde et de reprise après sinistre s'exécute correctement:

   [root@test2 ~]# service udsagent status
   Redirecting to /bin/systemctl status udsagent.service
   udsagent.service - Google Cloud Backup and DR service
   Loaded: loaded (/usr/lib/systemd/system/udsagent.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2022-12-28 05:05:45 UTC; 2 days ago
   Process: 46753 ExecStop=/act/initscripts/udsagent.init stop (code=exited, status=0/SUCCESS)
   Process: 46770 ExecStart=/act/initscripts/udsagent.init start (code=exited, status=0/SUCCESS)
   Main PID: 46789 (udsagent)
   Tasks: 8 (limit: 48851)
   Memory: 74.0M
   CGroup: /system.slice/udsagent.service
    ├─46789 /opt/act/bin/udsagent start   
    └─60570 /opt/act/bin/udsagent start
   
   Dec 30 05:11:30 test2 su[150713]: pam_unix(su:session): session closed for user oracle
   Dec 30 05:11:30 test2 su[150778]: (to oracle) root on none
   

10. Les messages de journal de vos sauvegardes peuvent vous aider à diagnostiquer les problèmes. Vous pouvez accéder aux journaux de l'hôte source où les tâches de sauvegarde sont exécutées. Pour les sauvegardes de base de données Oracle, deux fichiers journaux principaux sont disponibles dans le répertoire /var/act/log:

    • UDSAgent.log : journal de l'agent de sauvegarde et de reprise après sinistre Google Cloud qui enregistre les requêtes API, exécute des statistiques sur les tâches et d'autres informations.
    • SID_rman.log : journal Oracle RMAN qui enregistre toutes les commandes RMAN.

Considérations supplémentaires concernant Oracle

Lorsque vous implémentez la sauvegarde et la reprise après sinistre pour des bases de données Oracle, tenez compte des points suivants lorsque vous déployez Data Guard et RAC.

Remarques concernant la protection des données

Vous pouvez sauvegarder le nœud principal et le nœud de protection des données de secours. Toutefois, si vous choisissez de ne protéger les bases de données que depuis les nœuds de secours, vous devez utiliser l'authentification pour les bases de données Oracle plutôt que l'authentification du système d'exploitation lors de la sauvegarde de la base de données.

Considérations liées à RAC

La solution de sauvegarde et de reprise après sinistre n'accepte pas la sauvegarde simultanée de plusieurs nœuds dans une base de données RAC si le disque de préproduction est défini sur le mode NFS. Si votre système nécessite une sauvegarde simultanée de plusieurs nœuds RAC, utilisez Block (iSCSI) comme mode de disque de préproduction et définissez ce paramètre pour chaque hôte.

Pour une base de données Oracle RAC utilisant ASM, vous devez placer le fichier de contrôle d'instantané sur les disques partagés. Pour vérifier cette configuration, connectez-vous à l'ARM et exécutez la commande show all:

rman target /

RMAN> show all

Si le fichier de contrôle d'instantané ne se trouve pas au bon emplacement, reconfigurez-le. Par exemple, utilisez les paramètres de configuration RMAN suivants pour une base de données avec le paramètre "db_unique_name" défini sur **ctdb**, qui utilise le système de fichiers local :

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/mnt/ctdb/snapcf_ctdb.f';

Dans un environnement RAC, vous devez mapper le fichier de contrôle d'instantané à un groupe de disques ASM partagé. Pour attribuer le fichier au groupe de disques ASM, utilisez la commande Configure Snapshot Controlfile Name:

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+/snap_.f';

Recommandations

En fonction de vos besoins, vous devrez peut-être prendre des décisions concernant certaines fonctionnalités qui affectent la solution dans son ensemble. Certaines décisions peuvent avoir une incidence sur le prix, ce qui peut avoir un impact sur les performances. C'est par exemple le cas du choix de disques persistants standards (pd-standard) ou de disques persistants de performance (pd-ssd) pour les pools d'instantanés du dispositif de sauvegarde/récupération.

Dans cette section, nous partageons les choix que nous recommandons pour vous aider à garantir des performances optimales de débit de sauvegarde de base de données Oracle.

Sélectionner le type de machine et le type de disque persistant optimaux

Lorsque vous utilisez un dispositif de sauvegarde/récupération avec une application telle qu'un système de fichiers ou une base de données, vous pouvez mesurer les performances en fonction de la rapidité avec laquelle les données de l'instance hôte transfèrent les données entre les instances Compute Engine.

• La vitesse des appareils de disques persistants Compute Engine est basée sur trois facteurs: le type de machine, la quantité totale de mémoire associée à l'instance et le nombre de processeurs virtuels de l'instance.
• Le nombre de processeurs virtuels dans une instance détermine la vitesse du réseau allouée à une instance Compute Engine. Le débit est compris entre 1 Gbit/s pour un processeur virtuel partagé et 16 Gbit/s pour huit processeurs virtuels ou plus.
• Lorsque ces limites sont combinées, la sauvegarde et la reprise après sinistre Google Cloud utilisent par défaut un type de machine e2-standard-16 pour un type de machine de taille standard en tant que dispositif de sauvegarde/récupération. Trois options s'offrent à vous pour l'allocation de disque:

Choix	Pool de disque	Nombre maximal d'écritures soutenues	Nombre maximal de lectures soutenues
Minimum	10 Go	Non disponible	Non disponible
Standard	4 096 Go	400 Mio/s	1 200 Mio/s
SSD	4 096 Go	1 000 Mio/s	1 200 Mio/s

Les instances Compute Engine utilisent jusqu'à 60% du réseau qui leur est alloué pour les E/S avec les disques persistants associés, et réservent 40% à d'autres utilisations. Pour en savoir plus, consultez la section Autres facteurs influant sur les performances.

Recommandation: Pour bénéficier des meilleures performances pour les dispositifs de sauvegarde/récupération, sélectionnez un type de machine e2-standard-16 et un minimum de 4 096 Go de disque dur SSD. Vous pouvez également sélectionner un type de machine n2-standard-16 pour votre appareil de sauvegarde/récupération. Cette option offre des gains de performances supplémentaires (de l'ordre de 10 à 20 %), mais engendre des coûts supplémentaires. Si cela correspond à votre cas d'utilisation, contactez le service client Cloud pour effectuer cette modification.

Optimiser vos instantanés

Pour augmenter la productivité d'un seul dispositif de sauvegarde/récupération, vous pouvez exécuter des tâches d'instantanés simultanées à partir de plusieurs sources. Chaque tâche devient plus rapide. Toutefois, avec suffisamment de tâches, vous pouvez atteindre la limite d'écriture soutenue pour les volumes de disque persistant du pool d'instantanés.

Lorsque vous utilisez iSCSI pour le disque de préproduction, vous pouvez sauvegarder une seule instance volumineuse sur un dispositif de sauvegarde/récupération avec une vitesse d'écriture soutenue d'environ 300 à 330 Mo/s. Lors de nos tests, nous avons constaté que cela s'appliquait aux données allant de 2 To à 80 To dans un instantané, en supposant que vous configuriez à la fois l'hôte source et le dispositif de sauvegarde/récupération à une taille optimale, et qu'ils se trouvent dans la même région et la même zone.

Choisir le disque de préproduction approprié

si vous avez besoin de performances et d'un débit importants, Direct NFS peut offrir des avantages considérables par rapport à iSCSI en tant que disque de préproduction à utiliser pour les sauvegardes de bases de données Oracle. NFS direct consolide le nombre de connexions TCP, ce qui améliore l'évolutivité et les performances du réseau.

Lorsque vous activez Direct NFS pour une base de données Oracle, configurez un nombre suffisant de processeurs sources (par exemple, huit processeurs virtuels et huit canaux RMAN) et établissez une liaison de 10 Go entre votre extension régionale de solution Bare Metal et Google Cloud, vous pouvez sauvegarder une seule base de données Oracle avec un débit supérieur entre 700 et 900 Mo/s. Les vitesses de restauration du RMAN bénéficient également de Direct NFS, qui vous permet de voir que les niveaux de débit atteignent au moins 850 Mo/s.

Remarque :Si vous passez du disque de préproduction iSCSI à NFS, vous ne pouvez pas effectuer de sauvegarde sur un disque de préproduction ASM. Vos fichiers de sauvegarde sont placés sur un système de fichiers plutôt que sur un périphérique de stockage en mode bloc. Découvrez ce que vous gagnez et ce que vous perdez en passant à NFS, et choisissez vos préférences en conséquence.

Équilibrer coût et débit

Il est également important de comprendre que toutes les données de sauvegarde sont stockées dans un format compressé dans le pool d'instantanés du dispositif de sauvegarde/récupération, ce qui permet de réduire les coûts. L'impact de cette compression sur les performances est minime. Toutefois, pour les données chiffrées (TDE) ou les ensembles de données très compressés, il y aura probablement une incidence mesurable, bien que marginale sur vos chiffres de débit.

Comprendre les facteurs qui influent sur les performances du réseau et de vos serveurs de sauvegarde

Les éléments suivants affectent les E/S réseau entre la solution Oracle sur Bare Metal et vos serveurs de sauvegarde dans Google Cloud:

Mémoire flash

À l'instar des disques persistants Google Cloud, les baies de stockage flash qui fournissent le stockage aux systèmes de la solution Bare Metal augmentent les capacités d'E/S en fonction de la quantité d'espace de stockage que vous attribuez à l'hôte. Plus vous allouez d'espace de stockage, meilleures sont les E/S. Pour obtenir des résultats cohérents, nous vous recommandons de provisionner au moins 8 To de stockage Flash.

Latence du réseau

Les tâches de sauvegarde et de reprise après sinistre Google Cloud sont sensibles à la latence réseau entre les hôtes de la solution Bare Metal et le dispositif de sauvegarde/récupération dans Google Cloud. De légères augmentations de la latence peuvent entraîner des modifications importantes des délais de sauvegarde et de restauration. Chaque zone Compute Engine offre des latences réseau différentes aux hôtes de la solution Bare Metal. Il peut être judicieux de tester chaque zone pour vérifier l'emplacement optimal du dispositif de sauvegarde/récupération.

Nombre de processeurs utilisés

Les serveurs de la solution Bare Metal sont disponibles dans plusieurs tailles. Nous vous recommandons d'adapter vos canaux RMAN aux processeurs disponibles, avec la plus grande vitesse possible pour les systèmes plus importants.

Cloud Interconnect

L'interconnexion hybride entre la solution Bare Metal et Google Cloud est disponible en plusieurs tailles (5 Gbit/s, 10 Gbit/s et 2x10 Gbit/s), offrant des performances optimales avec l'option double 10 Go. Il est également possible de configurer une liaison d'interconnexion dédiée qui sera utilisée exclusivement pour les opérations de sauvegarde et de restauration. Cette option est recommandée pour les clients qui souhaitent isoler leur trafic de sauvegarde de celui des bases de données ou des applications pouvant traverser la même liaison, ou garantir une bande passante complète lorsque les opérations de sauvegarde et de restauration sont essentielles pour vous assurer d'atteindre votre objectif de point de récupération (RPO) et votre objectif de temps de récupération (RTO).

Étape suivante

Voici quelques liens et informations supplémentaires sur la sauvegarde et la reprise après sinistre Google Cloud qui pourraient vous être utiles.

• Pour obtenir des étapes supplémentaires sur la configuration de la sauvegarde et de la reprise après sinistre Google Cloud, consultez la documentation du produit Sauvegarde et reprise après sinistre.
• Pour voir l'installation du produit et des démonstrations de fonctionnalités, consultez la playlist de vidéos sur la sauvegarde et la reprise après sinistre Google Cloud.
• Pour afficher les informations de compatibilité pour la sauvegarde et la reprise après sinistre Google Cloud, consultez la page Matrice d'assistance: sauvegarde et reprise après sinistre. Il est important de vérifier que vous exécutez des versions compatibles des instances de base de données Linux et Oracle.
• Pour en savoir plus sur la protection des bases de données Oracle, consultez Sauvegarde et reprise après sinistre pour les bases de données Oracle et Protéger une base de données Oracle découverte.
• Les systèmes de fichiers tels que NFS, CIFS, ext3 et ext4 peuvent également être protégés par la sauvegarde et la reprise après sinistre de Google Cloud. Pour afficher les options disponibles, consultez Appliquer un plan de sauvegarde pour protéger un système de fichiers.
• Pour activer les alertes pour la sauvegarde et la reprise après sinistre Google Cloud, consultez la page Configurer une alerte basée sur les journaux et regardez la vidéo sur la configuration des notifications d'alerte de sauvegarde et de reprise après sinistre Google Cloud.
• Pour ouvrir une demande d'assistance, contactez le Cloud Customer Care.