Cette page a été traduite par l'API Cloud Translation.

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

Présentation

Assurer la résilience de vos bases de données Oracle dans une solution Bare Metal vous devez avoir une stratégie claire pour les sauvegardes de base de données et les sinistres la récupération. Pour vous aider à répondre à cette exigence, l'équipe d'architectes de solutions de l'équipe Google Cloud a réalisé des tests approfondis sur son environnement de sauvegarde et de reprise après sinistre, et compilé leurs résultats dans ce guide. Par conséquent, vous découvrirez les meilleurs moyens de déployer, de configurer et d'optimiser des options de récupération pour les bases de données Oracle dans un environnement de solution Bare Metal en à l'aide du service de sauvegarde et de reprise après sinistre. Nous partagerons également des données sur les performances les résultats des tests afin de pouvoir établir une analyse comparative avec votre propre environnement. Ce guide vous sera utile si vous êtes un administrateur secondaire, administrateur Google Cloud ou DBA Oracle.

Contexte

En juin 2022, l'équipe d'architectes de solutions a lancé une démonstration de faisabilité de la sauvegarde et de la reprise après sinistre Google Cloud pour une entreprise cliente. Pour répondre à leurs critères nous avons dû prendre en charge la récupération de leur base de données Oracle de 50 To et la base de données dans un délai de 24 heures.

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

Au cours de la démonstration de faisabilité, nous avons appris à configurer plusieurs éléments ensemble Oracle, la sauvegarde et la reprise après sinistre Google Cloud, le stockage dans un environnement de solution Bare Metal. Suivez les bonnes pratiques que nous avons apprises, vous pouvez produire vos propres résultats positifs.

"Votre kilométrage peut varier" est une très bonne façon de penser aux résultats globaux de ce document. Notre objectif est de partager quelques connaissances sur ce que nous avons appris, les éléments sur lesquels vous devez vous concentrer, les choses à éviter et les domaines à étudier si vous n'obtenez pas les performances ou les résultats que vous souhaitez. Nous espérons que ce guide vous aidera à prendre confiance dans les solutions proposées et à faire en sorte que votre si les conditions requises sont respectées.

Architecture

La figure 1 présente une vue simplifiée de l'infrastructure dont vous avez besoin pour compiler 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 les 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 ; vos licences logicielles sur site existantes.
Projet de service de sauvegarde et de reprise après sinistre : permet d'héberger votre appareil de sauvegarde/récupération, solution Bare Metal de sauvegarde et Google Cloud charges de travail dans des buckets Cloud Storage.
Projet de service de calcul : ce projet vous fournit un emplacement pour exécuter votre instance Compute Engine. à l'aide de VM.
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 pouvant connecter l'extension régionale de la solution Bare Metal au le service de sauvegarde et de reprise après sinistre, le 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 principaux composants nécessaires au fonctionnement de la solution:

Console de gestion des sauvegardes et de la reprise après sinistre : interface utilisateur HTML5 et point de terminaison de l'API qui vous permet de créer et de gérer des sauvegardes depuis le console Google Cloud.
Appareil de sauvegarde/récupération : cet appareil agit en tant que nœud de calcul des tâches dans effectuant les sauvegardes, ainsi que les tâches d'installation et de restauration.

Google Cloud gère la console de gestion des sauvegardes et de la reprise après sinistre. Toi déployer la console de gestion dans un projet producteur de services ; (côté gestion Google Cloud) et déployer l'appareil de sauvegarde/récupération dans un projet client de service (côté client). Pour en savoir plus sur Sauvegarde et reprise après sinistre, consultez Configurez et planifiez 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 du service, consultez la Glossaire Google Cloud

Avant de commencer

Pour installer le service de sauvegarde et de reprise après sinistre Google Cloud, vous devez effectuer le Suivez la procédure de configuration ci-dessous avant de démarrer le déploiement:

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, il doit comporter au moins 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 recommandez d'ajouter un sous-réseau /23. Qui plus est, vous pouvez ajouter un sous-réseau /20 pour vous assurer de pouvoir ajouter d'autres services par la suite.
Configurez Cloud DNS pour qu'il soit accessible dans le Réseau VPC sur lequel vous déployez le dispositif de sauvegarde/récupération. Ce garantit la résolution correcte de googleapis.com (via des protocoles privés ou recherche publique).
Configurer les routes par défaut du réseau 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. Encore une fois, vous devez de configurer les routes et le pare-feu dans le réseau VPC installer votre dispositif de sauvegarde/récupération. Nous vous recommandons aussi d'utiliser L'accès en tant qu'option privilégiée (consultez la page Configurer l'accès privé à Google pour en savoir plus.
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
Si vous avez activé des règles d'administration, assurez-vous de configurer les éléments suivants :
- Les constraints/cloudkms.allowedProtectionLevels incluent SOFTWARE ou ALL.
Configurez les règles de pare-feu suivantes :
- Ingress en provenance de l'appareil de sauvegarde/récupération dans Compute Engine VPC vers l'hôte Linux (agent) sur le port TCP-5106.
- Si vous utilisez un disque de sauvegarde par blocs avec iSCSI, la sortie du serveur (agent) de la solution Bare Metal vers l'appareil de sauvegarde/récupération VPC Compute Engine sur le port TCP-3260.
- Si vous utilisez un disque de sauvegarde NFS ou dNFS, le trafic sortant de l'hôte Linux dans la solution Bare Metal vers l'appareil de sauvegarde/récupération VPC Compute Engine sur les ports suivants:
  - TCP/UDP-111 (rpcbind)
  - TCP/UDP-756 (état)
  - TCP/UDP-2049 (nfs)
  - TCP/UDP-4001 (installé)
  - TCP/UDP-4045 (nlockmgr)
Configurez Google Cloud DNS. pour résoudre les noms d'hôte et les domaines de la solution Bare Metal, et garantir la résolution des noms la cohérence entre les serveurs de la solution Bare Metal, les VM Les ressources basées sur Compute Engine, telles 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

Activez le API du service de sauvegarde et de reprise après sinistre si ce n'est pas déjà fait.
Dans la console Google Cloud, utilisez le menu de navigation pour accéder à Opérations, puis sélectionnez Sauvegarde et reprise après sinistre:
Sélectionnez la connexion d'accès aux services privés que vous avez créée précédemment.
Choisissez l'emplacement de la console de gestion des sauvegardes et de la reprise après sinistre. Ce est la région dans laquelle vous déployez l'utilisateur de la console de gestion des sauvegardes et de la reprise après sinistre dans un projet producteur de services. Google Cloud possède et qui gère les ressources de la console de gestion.
Dans le projet client de service, choisissez le réseau VPC vous souhaitez vous connecter au service de sauvegarde et de reprise après sinistre. Il s'agit généralement VPC ou projet hôte.
Après un délai d'une heure, l'écran suivant doit s'afficher lorsque le déploiement est terminé.
Remarque:L'URL de chaque gestion des sauvegardes et de la reprise après sinistre de la console Google Cloud utilisent le format suivant:
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com
Remplacez les variables par ce qui suit:
- Numéro de projet de votre projet Google Cloud qui héberge la console de gestion de la sauvegarde et de la reprise après sinistre.
- L'ID généré, visible entre le numéro de projet et le mot dot dans l'URL de l'API de la console de gestion des sauvegardes et de la reprise après sinistre ;
- La région dans laquelle votre console de gestion des sauvegardes et de la reprise après sinistre se trouve.

Installer le dispositif de sauvegarde/récupération

Sur la page Sauvegarde et reprise après sinistre, procédez comme suit : Cliquez sur Log in to the Management Console (Se connecter à la console de gestion) :
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/
```
Sur la page principale de la console de gestion des sauvegardes et de la reprise après sinistre, accédez au Appareils:
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#clusters
```
Remarque :Vous trouverez le numéro de votre projet dans la tableau de bord de la console Google Cloud. Vous devez utiliser le numéro du projet dans lequel vous avez activé le service Backup and DR.
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 que le le déploiement.
Choisissez le projet client dans lequel vous souhaitez installer l'appliance de sauvegarde/restauration.
Choisissez la région, la zone et le sous-réseau de votre choix.
Sélectionnez un type de stockage. Nous vous recommandons d'utiliser Standard Persistent Disk pour Des démonstrations de faisabilité et des disques persistants SSD pour un environnement de production
Cliquez sur le bouton Begin Installation (Commencer l'installation). Le processus devrait prendre une heure de déployer la console de gestion des sauvegardes et de la reprise après sinistre, de sauvegarde/récupération.
Vous pouvez ajouter d'autres appliances de sauvegarde/restauration dans d'autres régions ou zones une fois le processus d'installation initial terminé.

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

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

Configurer un compte de service

À partir de la version 11.0.2 (version de décembre 2022 de la sauvegarde et de la reprise après sinistre), vous pouvez : utiliser un seul compte de service pour exécuter le dispositif de sauvegarde/récupération afin d'accéder vos buckets Cloud Storage, et protégez vos instances de VM (VM) (non abordé dans ce document).

Rôles de compte de service

Le service de sauvegarde et de reprise après sinistre Google Cloud utilise Google Cloud Identity and Access Management (IAM) pour les autorisations et les accès l'authentification unique. Vous pouvez utiliser des rôles prédéfinis pour activer diverses fonctionnalités de sauvegarde des fonctionnalités. Les deux plus importantes sont les suivantes:

Opérateur Cloud Storage de sauvegarde et de reprise après sinistre : attribuez ce rôle au(x) compte(s) de service utilisé(s) par un système de sauvegarde/récupération le ou les bucket Cloud Storage. Ce rôle permet de créer Les buckets Cloud Storage pour les sauvegardes d'instantanés Compute Engine pour accéder aux buckets avec des données de sauvegarde existantes basées sur des agents pour restaurer les charges de travail.
Opérateur Compute Engine de sauvegarde et de reprise après sinistre : attribuez ce rôle au(x) compte(s) de service utilisé(s) par un dispositif de sauvegarde/récupération Instantanés Persistent Disk pour les machines virtuelles Compute Engine En plus des instantanés, ce rôle permet au compte de service de restaurer les VM dans le du même projet source ou d'autres projets.

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

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

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 des données dans des emplacements de stockage physiques. Vous devez utiliser un disque persistant pour vos données les plus récentes (de 1 à 14 jours) ; Cloud Storage pour une conservation à plus long terme (jours, semaines, mois et ans).

Cloud Storage

Créez un bucket standard régional ou multirégional à l'emplacement souhaité. pour stocker les données de sauvegarde.

Suivez ces instructions pour créer un bucket Cloud Storage:
1. Sur la page Buckets Cloud Storage, procédez comme suit : et attribuez un nom au bucket.
2. Sélectionnez l'emplacement de stockage.
3. Choisissez une classe de stockage: standard, Nearline ou Coldline.
4. Si vous choisissez un stockage Nearline ou Coldline, définissez le paramètre Access Control (Contrôle des accès) sur Ultraprécis. Pour le stockage standard, acceptez l'accès par défaut mode de contrôle Uniforme.
5. Enfin, ne configurez aucune option de protection des données supplémentaire et cliquez sur Créer :
Ajoutez ensuite ce bucket au dispositif de sauvegarde/récupération. Accédez au Console de gestion des sauvegardes et de la reprise après sinistre
```
 https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/
 
```

Sélectionnez l'onglet Gérer > Élément de menu "Pools de stockage".

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

Page de la console de gestion des sauvegardes et de la reprise après sinistre affichant le menu Gérer > Pools de stockage.

Cliquez sur l'option située tout à droite +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 l'appareil que vous souhaitez rattacher à Cloud Storage bucket.
4. Saisissez le nom du bucket Cloud Storage.
5. Cliquez sur Enregistrer.

Pools d'instantanés de disque persistant

Si vous avez déployé l'appliance de sauvegarde/restauration avec des options standards ou SSD, le pool d'instantanés Persistent Disk sera de 4 To par défaut. Si votre source bases de données ou systèmes de fichiers nécessitent un pool de plus grande taille, vous pouvez modifier de votre dispositif de sauvegarde/récupération déployé, ajoutez un Persistent Disk, puis créez un pool personnalisé ou configurez-en un autre pool par défaut.

Accédez à Gérer > Appareils.

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

Modifiez l'instance du serveur de sauvegarde et cliquez sur + Ajouter un disque.
1. Attribuez un nom au disque.
2. Sélectionnez un type de disque Vide.
3. Selon vos besoins, optez pour le stockage standard, avec équilibrage ou SSD.
4. Saisissez la taille de disque dont vous avez besoin.
5. Cliquez sur Enregistrer.
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
```
Faites un clic droit sur le nom de l'appareil, puis sélectionnez Configurer le dispositif dans la .
Vous pouvez ajouter le disque au pool d'instantanés existant (extension) ou vous peuvent créer un pool. Toutefois, ne mélangez pas de types de disques persistants d'un pool d'objets). Si vous développez, cliquez sur l'icône en haut à droite du pool que vous souhaitez développer.
Dans cet exemple, vous créez un pool avec l'option Click to add pool (Cliquer pour ajouter un pool). Après avoir cliqué sur ce bouton, patientez 20 secondes pour que la page suivante s'ouvre.
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 ajouter le disque au d'un pool d'utilisateurs.
2. Cliquez sur Envoyer.
3. Confirmez que vous souhaitez continuer en saisissant CONTINUER en majuscules lorsque vous y êtes invité.
4. Cliquez sur Confirmer.
Votre pool va maintenant être développé ou créé avec le disque persistant.

Remarque :À ce stade, vous ne pouvez pas déplacer, développer ni supprimer le disque persistant. jusqu'à ce que vous supprimiez les images de sauvegarde stockées dans ce pool. Contact 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 tout une base de données, une VM ou un système de fichiers. Les plans de sauvegarde intègrent des profils et des modèles.

Les profils vous permettent de définir quand et pendant combien de temps sauvegarder un élément les données doivent être conservées.
Les modèles fournissent un élément de configuration qui vous permet de décider 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

Dans la console de gestion des sauvegardes et de la reprise après sinistre, accédez au Plans de sauvegarde > Profils.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#manageprofiles
```
Deux profils seront déjà créés. Vous pouvez utiliser un seul profil pour des instantanés de VM Compute Engine, et vous pouvez modifier l'autre profil et utiliser pour les sauvegardes de la solution Bare Metal. Vous pouvez avoir plusieurs profils, utile si vous sauvegardez de nombreuses bases de données qui nécessitent différents niveaux de disque pour la sauvegarde. Par exemple, vous pouvez créer un pool pour SSD (performances supérieures), et un pool pour les disques persistants standards (performances standards). Pour chaque vous pouvez choisir un autre pool d'instantanés.
Effectuez un clic droit sur le profil par défaut nommé LocalProfile et sélectionnez Modifier.
Apportez les modifications suivantes :
1. Mettez à jour les paramètres Profils avec un nom de profil plus explicite et la description. Vous pouvez spécifier le niveau de disque à utiliser, où le la localisation du ou des bucket Cloud Storage, ou d'autres informations explique 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

Dans la console de gestion des sauvegardes et de la reprise après sinistre, accédez au Plans de sauvegarde > Modèles.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#managetemplates
```
Cliquez sur + Créer un modèle.
1. Attribuez un nom au modèle.
2. Sélectionnez Oui pour Autoriser le remplacement des paramètres de règle.
3. Ajoutez une description de ce modèle.
4. Cliquez sur Enregistrer le modèle.
Dans votre modèle, configurez les éléments suivants:
1. Dans la section Règles à droite, cliquez sur + Ajouter.
2. Attribuez un nom à la règle.
3. Cochez la case correspondant aux jours pour lesquels vous souhaitez appliquer la règle, ou laissez la par défaut est Tous les jours.
4. Modifiez la fenêtre pour les 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.
Si vous souhaitez effectuer des sauvegardes régulières du journal d'archive (par exemple, (toutes les 15 minutes) et répliquer les journaux d'archive Cloud Storage, vous devez activer les paramètres de stratégie suivants:
1. Définissez Truncate/Purge Log after Backup (Tronquer/Purger le journal après la sauvegarde) sur Truncate (Tronquer) si c'est votre cas voulez.
2. Si vous le souhaitez, définissez l'option Activer la sauvegarde du journal de base de données sur Oui.
3. Définissez RPO (Minutes) (RPO (minutes)) sur l'intervalle de sauvegarde du journal d'archive souhaité.
4. Définissez la durée de conservation de la sauvegarde des journaux (en jours) sur la durée de conservation souhaitée. période.
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 les journaux à dans votre bucket Cloud Storage. Sinon, sélectionnez Non.
7. Cliquez sur Save Changes (Enregistrer les modifications).
Cliquez sur Mettre à jour la règle pour enregistrer vos modifications.
Sous OnVault à droite, effectuez les actions suivantes:
1. Cliquez sur +Ajouter.
2. Ajoutez le nom de la règle.
3. Définissez la conservation en jours, semaines, mois ou années.
4. Cliquez sur Mettre à jour la stratégie.
(Facultatif) Si vous devez ajouter d'autres options de conservation, créez des règles de conservation hebdomadaire, mensuelle et annuelle. Pour ajouter une règle de conservation procédez comme suit:
1. À droite, cliquez sur + Ajouter pour OnVault.
2. Attribuez un nom à la règle.
3. Remplacez la valeur Ces jours-ci par le jour où vous souhaitez déclencher l'événement d'un projet.
4. Définissez la Conservation sur Jours, Semaines, Mois ou Années.
5. Cliquez sur Mettre à jour la stratégie.
Cliquez sur Enregistrer le modèle. Dans l'exemple suivant, vous trouverez une règle d'instantané qui conserve les sauvegardes pendant trois jours dans le niveau de disque persistant, sept jours pour les tâches OnVault et quatre semaines au total. La sauvegarde hebdomadaire s'exécute le samedi soir.

Remarque :Dans la sauvegarde et la reprise après sinistre, les tâches OnVault quotidiennes et hebdomadaires ne sont pas différents emplois. Une tâche hebdomadaire est simplement l'emploi quotidien envoyé par Sauvegarde et reprise après sinistre sur Cloud Storage La tâche hebdomadaire reçoit une valeur de conservation supplémentaire afin que les données n'expirent pas. La sauvegarde et la reprise après sinistre conservent les images du samedi soir Cloud Storage pendant huit jours et quatre fois plus de semaines.

Sauvegarder une base de données Oracle

L'architecture de sauvegarde et de reprise après sinistre de Google Cloud sauvegarde Oracle vers Google Cloud cohérente et incrémentielle en continu, ainsi que la récupération et le clonage instantanés de 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 RMAN Image Copy : une copie d'image d'un fichier de données est beaucoup plus rapide à restaurer. car la structure physique du fichier de données existe déjà. La reprise La directive du gestionnaire (RMAN) BACKUP AS COPY crée des copies d'images pour toutes les données. de l'ensemble de la base de données et conserve le format des fichiers de données.
API ASM et CRS : utiliser la gestion automatique du stockage (ASM) et l'utilisation des clusters API Ready Services (CRS) pour gérer le groupe de disques de sauvegarde ASM
API RMAN archive log backup : cette API génère des journaux d'archive et les sauvegarde. sur un disque de préproduction et les supprime définitivement de l'emplacement d'archive de production.

Configurer les hôtes Oracle

Pour configurer vos hôtes Oracle, vous devez installer l'agent, ajouter les hôtes à la sauvegarde et à la reprise après sinistre, configurer les hôtes et découvrir la ou les bases de données Oracle. Une fois que tout est en place, vous pouvez effectuer vos 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. Toi n'avez besoin d'installer l'agent que la première fois que vous utilisez l'hôte, puis les mises à niveau ultérieures peuvent être effectuées depuis l'utilisateur de la console Google Cloud. Vous devez être connecté en tant que root ou dans une session sudo authentifiée pour exécuter un agent l'installation. Vous n'avez pas besoin de redémarrer l'hôte pour terminer l'installation.

Téléchargez l'agent de sauvegarde depuis l'interface utilisateur ou la page Gérer > Appareils.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#clusters
```
Faites un clic droit sur le nom du dispositif de sauvegarde/récupération, puis sélectionnez Configurer le serveur Une nouvelle fenêtre de navigateur s'ouvre.
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 téléchargé sur les hôtes Oracle pour l'installation.
Vous pouvez également stocker l'agent de sauvegarde dans un bucket Cloud Storage bucket, activer les téléchargements et utiliser les commandes wget ou curl pour télécharger directement à vos hôtes Linux.
```
curl -o agent-Linux-latestversion.rpm https://storage.googleapis.com/backup-agent-images/connector-Linux-11.0.2.9595.rpm
```

Utilisez 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 le 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

Si vous exécutez la commande iptables, ouvrez les ports de l'agent de sauvegarde. le pare-feu (TCP 5106) et les 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

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 configuration.
4. Cliquez sur le ou les appareils auxquels vous souhaitez ajouter l'hôte.
5. Collez la clé secrète. Vous devez effectuer cette tâche moins de deux heures après vous installez l'agent de sauvegarde et la clé secrète est générée.
6. Cliquez sur Ajouter pour enregistrer l'hôte.
Si vous recevez un message d'erreur ou un message Partial Success (Opération réussie partielle), essayez ce qui suit solutions de contournement:
1. La clé secrète de chiffrement de l'agent de sauvegarde a peut-être expiré. Si ce n'est pas le cas ajouter la clé secrète à l’hôte dans les deux heures suivant sa création. Vous pouvez générez une nouvelle clé secrète sur l'hôte Linux à l'aide de la commande suivante : syntaxe de ligne:
```
/opt/act/bin/udsagent secret --reset --restart
```
2. Pare-feu qui permet la communication entre les instances et l'agent installé sur l'hôte peuvent ne pas être configurés correctement. Suivez la procédure pour ouvrir les ports du pare-feu de l'agent de sauvegarde et les services Oracle.
3. La configuration du protocole NTP (Network Time Protocol) pour vos hôtes Linux peut être mal configuré. Vérifiez que vos paramètres NTP sont corrects.
Une fois le problème sous-jacent résolu, le message Certificate Status (État du certificat) devrait s'afficher. passe de N/A à Valid (Valide).

Configurer les hôtes

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
```
Effectuez un clic droit sur l'hôte Linux sur lequel vous souhaitez sauvegarder vos bases de données Oracle. et sélectionnez Modifier.
Cliquez sur Staging Disk Format (Format des disques intermédiaires), puis sélectionnez NFS.

Remarque :Si vous préférez utiliser des disques de préproduction ASM (également appelés disques de sauvegarde disques formatés ASM), sélectionnez Block (Bloquer) pour le Staging Disk Format (Format des disques de préproduction). .
Faites défiler la page jusqu'à la section Applications détectées, puis cliquez sur Découvrir les applications pour lancer le processus de détection d'appareil à agent
Cliquez sur Découvrir pour commencer le processus. Le processus de découverte prend jusqu'à 5 minutes Une fois l'opération terminée, les systèmes de fichiers découverts et les bases de données Oracle dans la fenêtre des applications.
Cliquez sur Enregistrer pour appliquer les modifications à vos hôtes.

Préparer l'hôte Linux

En installant des packages d'utilitaires iSCSI ou NFS sur votre hôte basé sur l'OS Linux, vous pouvez mapper un disque de préproduction sur un appareil qui écrit les données de sauvegarde. Utilisez les 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 permet de vous assurer que vous disposez de 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 un disque intermédiaire de sauvegarde basé sur les blocs (par exemple, une sauvegarde dans le système de fichiers) ou lorsque vous en avez besoin pour stocker le format de disque de préproduction de sauvegarde sur un groupe de disques ASM (dans lequel vous utilisez le dispositif de sauvegarde/récupération pour stocker, créer et gérer des sauvegardes).
Utilisez NFS, également connu sous le nom de Kernel NFS, pour augmenter le nombre de sauvegardes et restaurer les performances. Vous pouvez exploiter plusieurs sessions TCP avec NFS, mais cela La 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 des ressources à NFS, qui est plus rapide que le format NFS standard et améliore la sauvegarde et restaurer le débit. Toutefois, dNFS n'est compatible qu'avec la sauvegarde du système de fichiers disque de préproduction. Pour configurer dNFS, vous devez arrêter la base de données pour que la configuration prenne effet au redémarrage.

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

Ce guide part 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 assurent la protection de bases de données s'exécutant sur des systèmes de fichiers, ASM, Real Application Clusters (RAC) et de nombreuses autres configurations. Pour en savoir plus, consultez la page Sauvegarde et reprise après sinistre pour Oracle. de base de données.

Vous devez configurer quelques éléments avant de démarrer le job de sauvegarde. Quelques exemples sont facultatives. Toutefois, nous recommandons les paramètres suivants pour optimiser performances:

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

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

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

Connectez-vous à SQL*Plus avec le compte sysdba:
```
sqlplus / as sysdba
```

Utilisez les commandes suivantes pour activer le mode ARCHIVELOG. La sortie des commandes ressemble à ceci :

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.

Configurez le service NFS direct pour l'hôte Linux:

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

Configurez le suivi des modifications des blocs. Vérifiez d'abord s'il est activé sont désactivées. L'exemple suivant montre que le suivi des modifications du bloc 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.

Lorsque vous utilisez un système de fichiers, exécutez la commande suivante:

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

Database altered.

Vérifiez que le suivi des modifications de bloc 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

Dans la console de gestion des sauvegardes et de la reprise après sinistre, accédez à la page Gestionnaire d'applications > Applications.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#applications
```
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.
Sélectionnez le modèle et le profil que vous souhaitez utiliser, puis cliquez sur Appliquez un plan de sauvegarde.
Lorsque vous y êtes invité, définissez les paramètres avancés spécifiques à Oracle et à l'ARM requises pour votre configuration. Lorsque vous avez terminé, cliquez sur Appliquez un plan de sauvegarde.

Nombre de chaînes, par exemple, la valeur par défaut est 2. Si vous disposez de cœurs de processeur, vous pouvez augmenter le nombre de canaux d'opérations de sauvegarde et définissez une valeur plus élevée.

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

Boîte de dialogue "Sauvegarde et reprise après sinistre" montrant comment sélectionner la conversion du format ASM au format du système de fichiers.

En plus de ces paramètres, vous pouvez modifier le protocole utilisé par le disque de préproduction pour mapper le disque de l'appliliance de sauvegarde sur l'hôte. Accédez à la page Gérer > Hôtes, puis sélectionnez l'hôte que vous souhaitez modifier. Cochez l'option Préproduction du format de disque en tant qu'invité. Par défaut, le format Block (Bloc) est sélectionné, ce qui mappe le disque de préproduction via iSCSI. Vous pouvez également le remplacer par NFS, auquel cas le disque de préproduction utilisera 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, le système utilise iSCSI pour envoyer la sauvegarde à un système de fichiers. Si vous souhaitez utiliser NFS ou NFS direct (dNFS), vous devez définir les paramètres Hosts (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 de stockage de blocs et iSCSI.

Démarrer le job de sauvegarde

Dans la console de gestion des sauvegardes et de la reprise après sinistre, accédez au Gestionnaire d'applications > Applications.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#applications
```
Effectuez un clic droit sur la base de données Oracle que vous souhaitez protéger et sélectionnez Gérer le plan de sauvegarde dans le menu.
Cliquez sur le menu Instantané à droite, puis sur Exécuter. Cela commence un job de sauvegarde à la demande.
Pour surveiller l'état d'un job de sauvegarde, accédez à Surveiller > Menu "Jobs" et affichez le job état. L'affichage d'un job dans la liste des jobs peut prendre entre 5 et 10 secondes. Voici un exemple de tâche en cours d'exécution :
Lorsqu'une tâche est réussie, vous pouvez utiliser les métadonnées pour afficher les détails d'une un emploi spécifique.
- Appliquez des filtres et des termes de recherche pour trouver des offres d'emploi qui vous intéressent. L'exemple suivant utilise les filtres Succeeded (Succès) et Past Day (Jour précédent), ainsi qu'une recherche de l'hôte test1.
Pour examiner de plus près une tâche spécifique, cliquez dessus dans la section Job (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

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

Installation basée sur l'application
Restaurations (installation et migration, restauration classique)

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

Installation basée sur l'application

Les mounts vous permettent d'obtenir un accès rapide à une copie virtuelle d'une base de données Oracle. Vous pouvez configurer un montage lorsque les performances ne sont pas critiques et que la base de données copier sa durée de vie entre quelques heures et quelques jours.

Le principal avantage d’un montage est qu’il ne consomme pas de grandes quantités un espace de stockage supplémentaire. À la place, l'installation utilise un instantané du disque de sauvegarde qui peut être un pool d'instantanés sur un disque persistant ou un pool OnVault dans Cloud Storage. L'utilisation de la fonctionnalité d'instantané de copie virtuelle réduit pour accéder aux données, car les données n'ont pas besoin d'être copiées au préalable. Le disque de sauvegarde gère toutes les lectures, et un disque du pool d'instantanés les opérations d'écriture. Par conséquent, l'installation de copies virtuelles est rapide et ne permet pas la copie du disque de sauvegarde. Ces supports sont idéaux pour le développement, les activités de base de données pour lesquelles les modifications ou mises à jour du schéma doivent être validées avant et les déployer en production.

Installer une base de données Oracle

Dans la console de gestion des sauvegardes et de la reprise après sinistre, accédez au Sauvegarde et restauration > Récupérer.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#recover/selectapp
```
Dans la liste Application, recherchez la base de données que vous souhaitez installer. Effectuez un clic droit sur le nom de la base de données, puis cliquez sur Suivant:
La vue des rampes de chronologie s'affiche et affiche toutes les des images à un moment précis. Vous pouvez également faire défiler l'écran vers l'arrière pour afficher les images de rétention à long terme si elles ne s'affichent pas dans la vue de la rampe. Le système sélectionne la version la plus récente par défaut.
Si vous préférez afficher les images à un moment précis sous forme de vue Tableau, cliquez sur le bouton Tableau pour modifier la vue:
Recherchez l'image de votre choix, puis sélectionnez Monter :
Choisissez les options d'application pour la base de données que vous installez.
1. Sélectionnez l'hôte cible dans le menu déroulant. Les hôtes apparaissent dans si vous les avez ajoutées précédemment.
2. (Facultatif) Saisissez un libellé.
3. Dans le champ SID de la base de données cible, saisissez l'identifiant de la cible. base de données.
4. Définissez le Nom d'utilisateur sur Oracle. Ce nom devient le nom d'utilisateur du système d'exploitation pour l'authentification unique.
5. Saisissez le répertoire d'accueil Oracle. Pour cet exemple, utilisez /u01/app/oracle/product/19c/dbhome_1
6. Si vous configurez les journaux de la base de données à sauvegarder, Le paramètre Temps d'avance rapide devient disponible. Cliquez sur le sélecteur d'horloge/heure et choisissez le point de déploiement.
7. L'option Restaurer avec la récupération est activée par défaut. Cette option permet d'installer et ouvre la base de données pour vous.
Lorsque vous avez terminé de saisir les informations, cliquez sur Envoyer pour lancer le processus d'installation.

Surveiller la progression et la réussite des jobs

Vous pouvez surveiller le job en cours d'exécution en accédant à la page Surveiller > Jobs.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#jobs
```
La page affiche l'état et le type de mission.
Une fois le job d'installation terminé, vous pouvez en afficher les détails en cliquant sur Numéro de tâche:
Pour afficher les processus Pmon associés au SID que vous avez créé, connectez-vous à l'hôte cible et exécutez la commande ps -ef |grep pmon. Dans l'exemple de résultat suivant, la base de données SCHTEST est opérationnelle et possède 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:

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 la sauvegarde données. Il ne supprime que la base de données virtuelle montée de l'hôte cible et le disque de cache d'instantané qui contenait les écritures stockées pour la base de données.
Accédez à Gestionnaire d'applications > 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) et sélectionnez Accéder.
2. Sur la rampe de gauche, vous voyez un cercle gris avec un chiffre à l'intérieur indique le nombre d'installations actives à partir de ce moment. Cliquez sur cette image et un nouveau menu apparaît.
3. Cliquez sur Actions.
4. Cliquez sur Désinstaller et supprimer.
5. Cliquez sur Envoyer, puis confirmez cette action sur l'écran suivant.
6. Quelques minutes plus tard, le système supprime la base de données de la cible hôte, et nettoie et supprime tous les disques. Cette action libère tout disque dans le pool d'instantanés utilisé pour les écritures sur le disque de rétablissement montages actifs.
Vous pouvez surveiller les tâches désinstallées comme n'importe quelle autre tâche. Accédez au Surveiller > Menu "Jobs" (Tâches) pour surveiller la progression du job en cours de désinstallation et confirmer que le job est terminé.
```
 https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#jobs
 
```
Si vous supprimez accidentellement la base de données Oracle manuellement ou si vous arrêtez avant d'exécuter le job Désinstaller et supprimer, exécutez la Désinstaller et supprimer la tâche et sélectionner l'option Forcer le démontage activée l'écran de confirmation. Cette action supprime de force le disque de préproduction de rétablissement de l'hôte cible et supprime le disque du pool d'instantanés.

Restaurations

Vous utilisez les restaurations pour récupérer des bases de données de production en cas de problème ou de corruption. et que vous devez copier tous les fichiers de la base de données vers un hôte local à partir d'un la copie de sauvegarde. Vous effectuez normalement une restauration après un événement de type sinistre ou, des copies de test hors production. Dans ce cas, vos clients ont généralement vous devez attendre que vous copiiez les fichiers précédents sur l'hôte source avant de ils redémarrent leurs bases de données. Toutefois, Google Cloud Le service de sauvegarde et de reprise après sinistre offre également une fonctionnalité de restauration (copier des fichiers et démarrer base de données), et une fonctionnalité d'installation et de migration, qui consiste à installer la base de données (temps accessible rapidement), et vous pouvez copier les fichiers de données sur la machine locale pendant que est installée et accessible. La fonctionnalité d'installation et de migration avec un objectif de temps de récupération (RTO) faible.

Installer et migrer

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

Phase 1 : la phase de restauration de l'installation fournit un accès immédiat à la base de données à partir de la copie installée.
Phase 2 : phase de migration de restauration migre la base de données vers l'emplacement de stockage de production est en ligne.

Restaurer 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é 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ées à la couche ASM (ou système de fichiers) en fonction de la base de données source de l'image de back-up.
Utilisez l'API RMAN pour effectuer les tâches suivantes:
- Restaurez le fichier de contrôle et le fichier journal de rétablissement sur le contrôle local spécifié. 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 de sauvegarde/récupération.
- Avancer 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 est exécutée à partir de la copie mappée de l'image de back-up présentée par 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 dans la section 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 d'installation réussie, la base de données devient disponible pour des opérations de production. Vous pouvez utiliser l'API Oracle de transfert de fichiers de données en ligne pour déplacer les données vers l'emplacement de stockage de production (groupe de disques ou fichier ASM pendant que la base de données et l'application sont opérationnelles.

Restaurer la migration – Phase 2

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

La migration des données s'exécute en arrière-plan. Utiliser l'API de transfert de fichiers de données en ligne Oracle pour migrer les données.
Vous transférez les fichiers de données de la copie présentée par la sauvegarde et la reprise après sinistre image de sauvegarde dans l'espace de stockage de la base de données cible sélectionné (groupe de disques ou fichier ASM du système d'exploitation).
Une fois le job de migration terminé, le système supprime et annule le mappage Copie de l'image de sauvegarde de sauvegarde et de reprise après sinistre (groupe de disques ou fichier ASM) système) à partir de la cible, et 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 récupération, consultez les pages suivantes: Installez et migrez une image de sauvegarde Oracle pour une récupération instantanée vers n'importe quelle cible.

Restaurer une base de données Oracle

Dans la console de gestion des sauvegardes et de la reprise après sinistre, accédez à la page Sauvegarde et récupération > Restaurer.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#recover/selectapp
```
Dans la liste Application, effectuez un clic droit sur le nom de la base de données que vous à restaurer, puis sélectionnez Suivant:
La vue des rampes de chronologie s'affiche. Elle contient toutes les des images à un moment précis. Vous pouvez également faire défiler la page vers l'arrière des images de rétention à long terme qui n'apparaissent pas dans la rampe. Le système sélectionne l'image la plus récente par défaut.

Pour restaurer une image, cliquez sur le menu Installer et sélectionnez Restaurer:
Choisissez vos options de restauration.
1. Sélectionnez le temps d'avance rapide. Cliquez sur l'horloge et choisissez à un moment précis.
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.
Saisissez DATA LOSS (PERTE DE DONNÉES) pour confirmer que vous souhaitez écraser la base de données source, puis cliquez sur Confirm (Confirmer).

Surveiller la progression et la réussite des jobs

Pour surveiller la tâche, accédez à la page Surveiller > Jobs.

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

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

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

Une fois la tâche de restauration de la base de données terminée, le système ne sauvegarde pas de la base de données après la restauration. Autrement dit, lorsque vous restaurez qui disposait auparavant d'un plan de sauvegarde, le plan de sauvegarde ne s'active pas par défaut.

Pour vérifier que le plan de sauvegarde n'est pas en cours d'exécution, accédez à la page Gestionnaire d'applications > Applications.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#applications
```
Recherchez la base de données restaurée dans la liste. L'icône de protection passe de du vert au jaune, ce qui indique que le système n'est pas programmé pour s'exécuter de sauvegarde de la base de données.
Pour protéger la base de données restaurée, recherchez la base de données que vous souhaitez protéger dans la colonne Application. Effectuez un clic droit sur le nom de la base de données, puis sélectionnez Gérer le plan de sauvegarde.
Réactivez le job de sauvegarde planifié pour la base de données restaurée.
1. Cliquez sur le menu Appliquer, puis 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 résoudre les problèmes Sauvegardes Oracle, optimiser votre système et envisager des ajustements pour RAC et Environnements Data Guard.

Résoudre les problèmes liés aux sauvegardes Oracle

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

Pour vérifier que l'écouteur Oracle du service et de l'instance souhaités à 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

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

Boîte de dialogue "Sauvegarde et reprise après sinistre" affichant les détails de la tâche contenant le code d'erreur 5556.

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

Activer le suivi des modifications de bloc sur la base de données Oracle. Bien que ce ne soit pas obligatoire pour que la solution fonctionne, l'activation du suivi des modifications des blocs empêche la nécessité d'effectuer une quantité importante de post-traitement pour calculer et contribue à réduire la durée des jobs de sauvegarde:
```
SQL> select status,filename from v$block_change_tracking;

STATUS     FILENAME
---------- ------------------------------------------------------------------
ENABLED    +DATADG/ORCL/CHANGETRACKING/ctf.276.1124639617
```

Vérifiez que la base de données utilise spfile:

sqlplus / as sysdba

SQL> show parameter spfile

NAME               TYPE        VALUE
------------------ ----------- ------------
spfile             string      +DATA/ctdb/spfilectdb.ora

Activez NFS direct (dnfs) pour les hôtes de base de données Oracle. Bien que ce 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égier. Pour améliorer davantage le débit, vous pouvez modifier le disque de préproduction par hôte et par hôte activer les fichiers dnfs pour Oracle.

Configurer les noms tnsnames à résoudre pour les hôtes de base de données Oracle Si vous ne incluent ce paramètre, les commandes RMAN échouent souvent. Voici un exemple de la sortie:

[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)

Le champ SERVICE_NAME est important pour les configurations RAC. Le service Le nom 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 pour la base de données protégée, utilisez Paramètre avancé du nom de service Oracle. Saisissez le nom du service spécifique que vous souhaitez utiliser sur les nœuds qui exécutent le job de sauvegarde.

La base de données Oracle utilise le nom du service uniquement pour l'authentification de la base de données. La base de données n'utilise pas le nom de service pour l'authentification du système d'exploitation. Pour Par exemple, le nom de la base de données peut être CLU1_S et le nom de l'instance peut être être CLU1_S.
- Si le nom du service Oracle n'est pas répertorié, créez une entrée de nom de service sur la serveur(s) dans le fichier tnsnames.ora situé à l'adresse $ORACLE_HOME/network/admin ou à $GRID_HOME/network/admin en ajoutant la méthode 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 dans un emplacement non standard, indiquez le Chemin absolu vers le fichier sur la page Informations et paramètres de l'application décrit dans Configurer les détails et les paramètres de l'application pour les bases de données Oracle.
- Vérifiez que vous avez configuré l'entrée du nom de service pour la base de données correctement. 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 à la Application de sauvegarde et de reprise après sinistre:
```
sqlplus act_rman_user/act_rman_user@act_svc_dbstd as sysdba
```
- Sur la page Informations sur l'application et paramètres décrite dans Application Details and Settings for Oracle Databases (Détails et paramètres de l'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) :
Le code d'erreur 870 indique que "les sauvegardes ASM avec ASM sur les disques de préproduction NFS sont non pris en charge." Si ce message d'erreur s'affiche, cela signifie que vous ne disposez pas configuré dans Détails et paramètres pour l'instance que vous souhaitez à protéger. Dans cette mauvaise 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 Convertir le format ASM au format de système de fichiers sur Oui. Après avoir modifié ce paramètre, réexécutez le job de sauvegarde.

Le code d'erreur 15 indique au système de sauvegarde et de reprise après sinistre : "Impossible connectez-vous à l'hôte de sauvegarde. » Si vous recevez cette erreur, elle indique l'une des trois problèmes:

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 (l'agent qui écoute par défaut).
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. Après avoir corrigé la cause sous-jacente, exécutez la service udsagent status. L'exemple de résultat suivant montre que le service de l'agent de sauvegarde et de reprise après sinistre fonctionne 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

Les messages de journal de vos sauvegardes peuvent vous aider à diagnostiquer les problèmes. Vous pouvez accéder les journaux sur l'hôte source sur lequel s'exécutent les jobs de sauvegarde. Pour la base de données Oracle sauvegardes, deux fichiers journaux principaux sont disponibles dans /var/act/log répertoire:
- UDSAgent.log : journal de l'agent de sauvegarde et de reprise après sinistre Google Cloud qui enregistre les requêtes API, les statistiques d'exécution des tâches et d'autres informations.
- SID_rman.log : journal RMAN Oracle qui enregistre toutes les commandes RMAN.

Considérations supplémentaires pour Oracle

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

Remarques concernant Data Guard

Vous pouvez sauvegarder les nœuds Data Guard principaux et de secours. Toutefois, si vous choisissez pour protéger les bases de données uniquement des nœuds de secours, vous devez utiliser Oracle Database Authentication au lieu de l'authentification de l'OS. la base de données.

Remarques concernant RAC

La solution de sauvegarde et de reprise après sinistre n'est pas compatible avec la sauvegarde simultanée depuis plusieurs nœuds dans une base de données RAC si le disque de préproduction est défini en mode NFS. Si votre nécessite une sauvegarde simultanée à partir de plusieurs nœuds RAC, utilisez la fonctionnalité Block (iSCSI) comme mode de disque de préproduction et le définir par hôte.

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

rman target /

RMAN> show all

Si le fichier de contrôle des instantanés ne se trouve pas au bon emplacement, reconfigurez-le. Pour utilisez les paramètres de configuration RMAN suivants pour une base de données ayant une valeur "db_unique_name" de **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é sur un ASM partagé. groupe de disques. Pour attribuer le fichier au groupe de disques ASM, utilisez le 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 caractéristiques qui ont un effet sur la solution globale. Certaines décisions peuvent avoir un impact sur le prix, ce qui peut influer sur les performances, par exemple en choisissant des Disques persistants (pd-standard) ou 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 à optimiser pour le débit des sauvegardes de la base de données Oracle.

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

Lorsque vous utilisez un appareil 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é des transferts de données de l'instance hôte entre les instances Compute Engine.

Les vitesses des disques persistants Compute Engine sont basées sur tels que le type de machine, la quantité totale de mémoire associée et le nombre de vCPU de l'instance.
Dans une instance, le nombre de processeurs virtuels détermine la vitesse du réseau allouée à Compute Engine. Le débit est compris entre 1 Gbit/s et 1 Gbit/s jusqu'à 16 Gbit/s pour huit processeurs virtuels ou plus.
Si vous combinez ces limites, le service de sauvegarde et de reprise après sinistre de Google Cloud utilise par défaut avec une instance e2-standard-16 pour un type de machine de taille standard de sauvegarde/récupération. À partir de ce point de départ, trois possibilités s'offrent à vous pour l'allocation de disque:

Choix	Pool Disk (Disque de pool)	Nombre maximal d'écritures soutenues	Nombre maximal de lectures soutenues
Minimum	10 Go	N/A	N/A
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 alloué pour E/S sur leurs disques persistants associés et réserver 40% pour d'autres utilisations. Pour pour en savoir plus, consultez l'article Autres facteurs qui affectent les performances.

Recommandation: Sélectionnez un type de machine e2-standard-16 et une configuration minimale des 4 096 Go de PD-SSD offrent les meilleures performances pour la sauvegarde/récupération appareils. Vous pouvez également sélectionner une machine n2-standard-16 pour votre dispositif de sauvegarde/récupération. Cette option offre des avantages supplémentaires améliore les performances de l'ordre de 10 à 20 %, mais s'accompagne de coûts supplémentaires. Si cela correspond à votre cas d'utilisation, contactez Cloud Customer Care 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 jobs d'instantanés simultanés à partir de plusieurs sources. Chaque emploi individuel réduit la vitesse de chargement. Toutefois, avec suffisamment de jobs, vous pouvez atteindre la limite d'écriture soutenue pour les volumes Persistent Disk 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 ce constat s'appliquait à de 2 To à 80 To dans un instantané, en supposant que vous avez configuré à la fois l'hôte source et la sauvegarde/récupération à une taille optimale, et situés dans la même région et la même zone.

Choisir le bon disque de préproduction

Si vous avez besoin de performances et d'un débit élevés, le NFS direct peut ajouter présente un avantage significatif par rapport à iSCSI comme disque de préproduction à utiliser pour Oracle. des sauvegardes de base de données. NFS direct consolide le nombre de connexions TCP, ce qui améliore l'évolutivité et les performances du réseau.

Lorsque vous activez le mode NFS direct pour une base de données Oracle, configurez suffisamment de sources CPU (par exemple, 8 vCPU et 8 canaux RMAN), et établir une liaison de 10 Go entre l'extension régionale de votre solution Bare Metal et Google Cloud, vous peuvent sauvegarder une seule base de données Oracle avec un débit supérieur entre 700 et 900 Mo/s. Les vitesses de restauration RMAN bénéficient également de Direct NFS, où vous pouvez voir les niveaux de débit atteignent la plage de 850 Mo/s et plus.

Équilibrer coût et débit

Il est également important de comprendre que toutes les données de sauvegarde sont stockées dans un au pool d'instantanés de l'appareil de sauvegarde/récupération. Cette opération permet de réduire des coûts. L'impact sur les performances de cet avantage de compression est minime. Toutefois, pour les données chiffrées (TDE) ou les ensembles de données fortement compressés, sont plus ou moins mesurables, même s'ils ont un impact marginal sur votre débit.

Comprenez 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 Oracle sur la solution Bare Metal et vos serveurs de sauvegarde dans Google Cloud:

Mémoire flash

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

Latence du réseau

Les jobs de sauvegarde Google Cloud et de reprise après sinistre sont sensibles la latence du réseau entre les hôtes de la solution Bare Metal et le service de sauvegarde/récupération dans Google Cloud. De légères augmentations de la latence peuvent entraîner des modifications aux délais de sauvegarde et de restauration. Différentes zones Compute Engine offrent différentes latences réseau aux hôtes de la solution Bare Metal. C'est une bonne idée de tester chaque zone pour le placement optimal du dispositif de sauvegarde/récupération.

Nombre de processeurs utilisés

Les serveurs de la solution Bare Metal sont disponibles dans plusieurs sizes. Nous vous recommandons d'adapter vos canaux ARM en fonction des processeurs disponibles, avec une plus grande vitesse possible à partir de systèmes plus grands.

Cloud Interconnect

L'interconnexion hybride entre la solution Bare Metal et Google Cloud est disponibles dans différentes tailles (5 Gbit/s, 10 Gbit/s et 2 x 10 Gbit/s, avec avec une double capacité de 10 Go. Il est également possible de configurer un lien d'interconnexion dédié qui sera utilisé exclusivement pour les opérations de sauvegarde et de restauration. Cette option est recommandée pour les clients qui souhaitent le trafic de sauvegarde de la base de données ou du trafic de l'application, qui peut traverser ou garantir une bande passante complète pour les opérations de sauvegarde et de restauration essentiel pour vous assurer d'atteindre votre objectif de point de récupération (RPO) et un objectif de temps de récupération (RTO).

Étape suivante

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

Pour les étapes supplémentaires concernant la configuration de Google Cloud Pour la sauvegarde et la reprise après sinistre, consultez la documentation du produit de sauvegarde et de reprise après sinistre.
Pour voir l'installation du produit et les démonstrations de fonctionnalités, consultez la Playlist vidéo sur la sauvegarde et la reprise après sinistre Google Cloud
Afficher des informations sur la compatibilité de Google Cloud Pour la sauvegarde et la reprise après sinistre, consultez Matrice de support: Sauvegarde et reprise après sinistre. Il est important de vérifier que vous exécutez des versions prises en charge de Linux et Instances de base de données Oracle.
Pour connaître les étapes supplémentaires concernant 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 Sauvegarde et reprise après sinistre 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 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 Cloud Customer Care.

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

Présentation

Contexte

Architecture

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

Avant de commencer

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

Installer le dispositif de sauvegarde/récupération

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

Configurer un compte de service

Rôles de compte de service

Configurer des pools de stockage

Cloud Storage

Pools d'instantanés de disque persistant

Configurer des plans de sauvegarde

Créer un profil

Créer un modèle

Sauvegarder une base de données Oracle

Configurer les hôtes Oracle

Installer l'agent de sauvegarde

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

Configurer les hôtes

Préparer l'hôte Linux

Préparer la base de données Oracle

Protéger une base de données Oracle

Démarrer le job de sauvegarde

Installer et restaurer une base de données Oracle

Installation basée sur l'application

Installer une base de données Oracle

Surveiller la progression et la réussite des jobs

Unmount an Oracle database

Restaurations

Installer et migrer

Restaurer l'installation – Phase 1

Restaurer la migration – Phase 2

Restaurer une base de données Oracle

Surveiller la progression et la réussite des jobs

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

Dépannage et optimisation

Résoudre les problèmes liés aux sauvegardes Oracle

Considérations supplémentaires pour Oracle

Remarques concernant Data Guard

Remarques concernant RAC

Recommandations

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

Optimiser vos instantanés

Choisir le bon disque de préproduction

Équilibrer coût et débit

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

Mémoire flash

Latence du réseau

Nombre de processeurs utilisés

Cloud Interconnect

Étape suivante