Service de sauvegarde et de reprise après sinistre pour Oracle

Oracle Database est une base de données populaire de niveau entreprise qui prend en charge les applications critiques. Cette page présente le service de sauvegarde et de reprise après sinistre pour les environnements de base de données Oracle. L'architecture associée fournit une sauvegarde incrémentielle et indéfinie cohérente avec l'application vers Google Cloud, ainsi qu'une récupération et un clonage instantanés pour les bases de données Oracle de plusieurs téraoctets.

Fonctionnement

Les sections suivantes décrivent le processus de capture et de récupération des données.

Capture de données

  1. L'agent Backup and DR est déployé sur le serveur Oracle.

  2. Montez le disque de préproduction sur le serveur de base de données.

  3. Appelez l'API incrémentielle RMAN pour copier les blocs modifiés.

  4. Appelez la fusion incrémentielle RMAN pour créer une copie complète virtuelle.

  5. Désinstallez le disque de préproduction du serveur de base de données.

  6. Backup and DR prend un instantané interne. La fonctionnalité de capture complète synthétique au moment donné est prête.

Récupération de données

La sauvegarde et la reprise après sinistre installent instantanément un disque d'installation réwritable sur ISCSI ou NFS et mettent la base de données en ligne.

API de sauvegarde Oracle

Backup and DR utilise les API Oracle suivantes:

  • Image Copy RMAN: la restauration d'une copie d'image d'un fichier de données est beaucoup plus rapide, car la structure physique du fichier de données existe déjà. La directive 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: le groupe de disques de sauvegarde ASM est géré à l'aide des API ASM et CRS.

  • API de sauvegarde des journaux d'archive RMAN: les journaux d'archive générés sont sauvegardés sur le disque d'espace de préparation et supprimés de l'emplacement d'archive de production.

Limiter les conflits lorsque vous utilisez le service Backup and DR avec d'autres produits de sauvegarde

Le service Backup and DR peut coexister avec les anciens produits qui collectent des données à partir de bases de données de production. Les bonnes pratiques suivantes peuvent vous aider à améliorer votre expérience:

Calendrier de sauvegarde de la base de données Oracle

Bonnes pratiques Planifiez les tâches de sauvegarde de la base de données du service Backup and DR pour qu'elles commencent à un moment où l'ancien logiciel de sauvegarde doit être terminé. Ne planifiez pas l'exécution de l'ancien logiciel de sauvegarde immédiatement après la fin normale d'une tâche de sauvegarde de base de données du service Backup and DR.
Motif Si les anciennes tâches de sauvegarde et les tâches de sauvegarde de la base de données du service de sauvegarde et de reprise après sinistre s'exécutent simultanément, cela peut avoir un impact important sur les performances du serveur de base de données, ce qui peut entraîner une instabilité et éventuellement une panne. De plus, pour Oracle, cela peut entraîner des images de sauvegarde non valides pour une ou les deux solutions.

Gestion des journaux d'archivage Oracle

Oracle utilise les journaux d'archive générés lors d'une sauvegarde de base de données pour assurer la cohérence et la récupérabilité de cette sauvegarde. Par conséquent, si les journaux d'archivage sont supprimés lors d'une tâche de sauvegarde de base de données, cette copie de sauvegarde ne peut pas être récupérée.

Exigence Un seul système peut gérer (capturer et/ou tronquer/effacer) les journaux, soit l'ancien logiciel de sauvegarde, soit le service Backup and DR.
Bonne pratique N'autorisez pas la suppression des journaux d'archive Oracle lors d'une tâche de sauvegarde et de reprise après sinistre, et n'autorisez pas le service de sauvegarde et de reprise après sinistre à supprimer les journaux d'archive lors d'une tâche de sauvegarde RMAN ancienne.
Si le logiciel ancien gère le journal d'archive, désactivez les tâches de suppression du journal d'archive dans le logiciel de sauvegarde ancien au début de la tâche de sauvegarde et de reprise après sinistre, puis reprenez les tâches de suppression à la fin ou conservez le journal d'archive pendant au moins 24 heures avant de le supprimer.
Motif Si les journaux d'archive sont supprimés lors d'une tâche de sauvegarde de base de données, l'image de sauvegarde de cette base de données peut être irrécupérable.

Conflit des métadonnées RMAN avec les anciennes sauvegardes qui rendent les sauvegardes du service Backup and DR obsolètes

Par défaut, le paramètre DO NOT UNCATALOG dans les détails et paramètres de l'application du service Backup and DR est défini sur Non. Une sauvegarde de fichier de données Backup and DR est cataloguée au début de la sauvegarde et déscataloguée à la fin de la tâche. Si vous définissez cette valeur sur Yes (Oui), le temps de sauvegarde des bases de données contenant un grand nombre de fichiers de données est optimisé, car la sauvegarde du fichier de données RMAN est conservée dans le catalogue après chaque tâche de sauvegarde. Toutefois, il interfère avec d'autres produits de sauvegarde.

Exigence Définissez le paramètre Do not uncatalog "Informations et paramètres de l'application Backup and DR" sur Non.
Bonne pratique Les sauvegardes de base de données du service Backup and DR sont incrémentielles. Pour ce faire, utilisez la copie d'image RMAN avec l'API de fusion incrémentielle RMAN. La première sauvegarde RMAN est une copie d'image complète du fichier de données de la base de données sur le disque de sauvegarde et de DR avec un instantané interne du disque de sauvegarde. Les sauvegardes incrémentielles RMAN suivantes s'exécutent avec la fusion incrémentielle RMAN sur le disque de sauvegarde et de sauvegarde de DR, en mettant à jour la dernière sauvegarde complète avec les modifications incrémentielles avant l'instantané. Toutefois, si une sauvegarde de base de données tierce ou une vérification croisée de la sauvegarde s'exécute après la sauvegarde de base de données de sauvegarde et reprise après sinistre, tous les fichiers de données de sauvegarde sous la sauvegarde de sauvegarde et reprise après sinistre sont marqués comme obsolètes dans les métadonnées RMAN. Si le paramètre Do not uncatalog des détails et des paramètres de l'application de sauvegarde et de DR est défini sur Oui, l'erreur suivante s'affiche : Échec de la cataloguation des copies d'images à partir de l'appareil de préproduction, et la sauvegarde échoue. Laissez Do not uncatalog défini sur Non pour coexister avec d'autres anciens produits de sauvegarde.
Motif Par défaut, le paramètre Do not uncatalog> in Backup and DR application details & settings is set to No. Setting this to Yes interferes with other backup products.

Suivi des modifications de blocs (BCT) de la base de données Oracle

Le suivi des modifications de blocs Oracle permet de sauvegarder rapidement les bases de données en identifiant les blocs qui ont changé. Seuls les blocs modifiés sont inclus dans l'opération de sauvegarde.

  • Le service de sauvegarde et de reprise après sinistre incrémentiel-pour toujours est compatible avec les bases de données exécutées avec BCT activé ou désactivé. Lorsque le BCT n'est pas activé, la durée de la sauvegarde incrémentielle augmente.

  • Le suivi des blocs de modifications est activé au niveau de la base de données.

  • Oracle enregistre les blocs modifiés dans chaque fichier de données dans un fichier de suivi, qui est un petit fichier binaire stocké dans la zone de la base de données.

  • Lorsque le BCT est activé, RMAN utilise le fichier BCT pour obtenir les blocs modifiés pour la sauvegarde incrémentielle.

  • RMAN analyse chaque bloc d'un fichier de données pour tous les fichiers de données de la base de données lors d'une sauvegarde incrémentielle lorsque le suivi des blocs modifiés de la base de données n'est pas activé.

Protéger les bases de données Oracle dans un groupe de cohérence de sauvegarde et de reprise après sinistre

Dans la plupart des configurations, un groupe de cohérence peut contenir une seule application de base de données Oracle et un nombre illimité d'applications de système de fichiers du serveur Oracle. Un groupe de cohérence est le choix recommandé pour les bases de données Oracle dans les cas d'utilisation de test-développement et d'agilité commerciale.

Bases de données Oracle avec TDE

Le service Backup and DR est compatible avec diverses méthodes de capture et de présentation pour les bases de données Oracle dans différentes configurations. Cela inclut les opérations de sauvegarde, de récupération et de montage de la base de données Oracle avec le chiffrement transparent des données (TDE) configuré.

Pour les bases de données Oracle avec TDE, les fichiers de portefeuille de l'hôte de sauvegarde source doivent être disponibles pour l'hôte cible de tous les montages Application Aware. Pour ce faire, plusieurs possibilités s'offrent à vous.

  • Les fichiers du portefeuille peuvent être copiés du serveur source de sauvegarde vers le serveur de montage cible, et Oracle peut être configuré pour y accéder.
  • Si les fichiers du portefeuille Oracle sont stockés sur un appareil partagé central sur le réseau, l'instance Oracle cible de l'installation Appaware doit être configurée pour y accéder.

  • Si les fichiers de portefeuille Oracle ont été capturés lors de la sauvegarde du service Backup and DR en définissant le paramètre avancé "Oracle Configuration File Location" (Emplacement du fichier de configuration Oracle), vous pouvez les récupérer en procédant comme suit:

    1. Effectuez un montage standard de la base de données sur l'hôte cible.
    2. Copiez les fichiers du portefeuille à partir du montage de base de données standard vers l'hôte cible et configurez Oracle pour les utiliser.
    3. Désinstallez la base de données de l'hôte cible.
    4. Effectuez un montage compatible avec les applications de la base de données sur l'hôte cible.

Sauvegarde et reprise après sinistre avec la base de données Oracle Exadata ou Oracle ExaCC

Les appareils de sauvegarde/restauration permettent de capturer et de présenter les données Exadata via les protocoles iSCSI ou Oracle dNFS.

  • L'appliance de sauvegarde/restauration est connectée via iSCSI ou Oracle dNFS sur le réseau (et non sur le chemin de données).

  • La sauvegarde RMAN utilise RMAN pour écrire directement dans le datastore de copie présenté par Backup and DR en tant que système de fichiers ou groupe de disques ASM.

  • Formats de capture de données: sous Groupe de disques ASM (iSCSI uniquement) ou sous Système de fichiers (dNFS ou iSCSI).

  • La sauvegarde incrémentielle "forever" de Backup and DR utilise des sauvegardes RMAN mises à jour de manière incrémentielle, en appliquant les sauvegardes de copie d'image de manière continue.

Capture de sauvegarde et de reprise après sinistre des données Exadata et ExaCC

L'agent Backup and DR doit être installé sur le serveur Exadata pour faciliter la communication avec l'appli de sauvegarde/restauration et appeler l'API RMAN pour la sauvegarde de la base de données.

L'agent Backup and DR expose et mappe les disques Backup and DR sur le serveur Exadata en tant que cible iSCSI. Le format de capture de données peut se trouver sous Groupe de disques ASM ou sous Système de fichiers.

Installez l'agent Backup and DR sur chaque hôte Exadata dans l'espace utilisateur pour faciliter la communication avec l'appliance de sauvegarde/restauration et pour appeler l'API RMAN pour la sauvegarde de la base de données.

Format de capture sous le groupe de disques ASM

Lors d'une sauvegarde, l'agent Backup and DR effectue les opérations suivantes:

  1. Mappez et exposez le disque logique au serveur Exadata en tant que cible iSCSI.

  2. Ajoutez le chemin d'accès au disque de sauvegarde et de DR à la chaîne de disque ASM.

  3. Assurez-vous que la chaîne de disque ASM est ajoutée au fichier de paramètres et qu'elle n'existe pas dans le profil CRS.

  4. Créez un groupe de disques ASM en tant que redondance externe à l'aide d'un disque de sauvegarde et de DR.

    • Sauvegarde RMAN à l'aide de RMAN pour écrire directement dans le datastore de copie présenté par l'appareil de sauvegarde/restauration en tant que groupe de disques ASM ou en tant que système de fichiers.

    • Sauvegarde illimitée à l'aide de sauvegardes RMAN mises à jour de manière incrémentielle, avec des sauvegardes de copie d'image incrémentielles.

Format de capture sous le système de fichiers à l'aide de dNFS

NFS direct (dNFS) Oracle est un client NFS (Network File System) optimisé qui fournit un accès plus rapide et plus évolutif au stockage NFS situé sur des appareils de stockage NAS (accessibles via TCP/IP). NFS direct est intégré directement au noyau de la base de données, tout comme ASM.

Le protocole dNFS peut être utilisé pour la sauvegarde basée sur un système de fichiers en tant que partage NFS.

L'agent Backup and DR expose et mappe les disques de sauvegarde et de reprise après sinistre sur le serveur Exadata en tant que partage NFS.

Conditions préalables pour dNFS sur un serveur Exadata:

  • Activez dNFS sur le serveur Exadata:

    cd $ORACLE_HOME/rdbms/lib make -f ins_rdbms.mk nfs on

  • Redémarrez la base de données.

    Utilisez l'API RMAN pour sauvegarder la base de données sur le système de fichiers d'un partage dNFS présenté par l'appliliance de sauvegarde/restauration.

Réactiver des groupes de disques ASM protégés par Backup and DR après le redémarrage d'un serveur de base de données cible

Après tout redémarrage du serveur de base de données où la copie de sauvegarde et de reprise après sinistre est installée, ou lorsque des sauvegardes de sauvegarde et de reprise après sinistre sont en cours pour la base de données au moment du redémarrage/plantage, procédez comme suit pour rétablir l'installation du groupe de disques de sauvegarde et de reprise après sinistre:

  1. Vérifiez que le serveur de base de données cible est de nouveau opérationnel et que le système ASM et RAC est également opérationnel.

  2. Redémarrez l'agent de sauvegarde et de reprise après sinistre (à partir de la racine).

  3. Définir l'environnement ASM

  4. Connectez-vous à ASM sqlplus et vérifiez l'état du groupe de disques:

    select name, state from v$asm_diskgroup where name = '<dg name>';)

  5. Si le groupe de disques n'est pas installé, installez-le: alter diskgroup <dg name> mount;

  6. Connectez-vous à l'OS Oracle et définissez l'environnement de base de données, puis démarrez la base de données.

Étape suivante

Découvrez les conditions préalables à la sauvegarde d'une base de données Oracle.

Autre documentation sur Backup and DR pour Oracle