Backup and DR pour Oracle sur un appareil de sauvegarde/restauration

La base de données Oracle est une base de données d'entreprise populaire qui prend en charge les applications critiques. Cette page présente Backup and DR pour les environnements de base de données Oracle. L'architecture associée fournit une sauvegarde incrémentielle à vie cohérente avec les applications sur 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. Installez le disque intermédiaire 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 sauvegarde complète virtuelle.

  5. Démontez le disque intermédiaire du serveur de base de données.

  6. Backup and DR prend un instantané interne. La sauvegarde complète synthétique à un moment précis est prête.

Récupération de données

Backup and DR monte instantanément un disque de préparation réinscriptible sur ISCSI ou NFS, puis met la base de données en ligne.

API de sauvegarde Oracle

Backup and DR utilise les API Oracle suivantes :

  • Copie d'image 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 des fichiers 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 intermédiaire et supprimés de l'emplacement de l'archive de production.

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

Backup and DR peut coexister avec les anciens produits qui capturent les données des 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

Bonne pratique Programmez les jobs de sauvegarde de la base de données Backup and DR pour qu'ils commencent à un moment où l'ancien logiciel de sauvegarde devrait être terminé. Ne programmez 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 Backup and DR.
Motif Si les anciens jobs de sauvegarde et les jobs de sauvegarde de base de données Backup and DR 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é, voire une panne. De plus, pour Oracle, cela peut entraîner des sauvegardes non valides pour l'une ou les deux solutions.

Gestion des journaux d'archive Oracle

Oracle utilise les journaux d'archive générés lors d'une sauvegarde de base de données pour garantir la cohérence et la récupérabilité de cette sauvegarde. Par conséquent, si les journaux d'archive sont supprimés lors d'un job de sauvegarde de base de données, cette copie de sauvegarde est irrécupérable.

Exigence Un seul système peut gérer (capturer et/ou tronquer/purger) les journaux, qu'il s'agisse de l'ancien logiciel de sauvegarde ou de Backup and DR.
Bonne pratique N'autorisez pas la suppression des journaux d'archive Oracle lors d'un job Backup and DR, et n'autorisez pas Backup and DR à supprimer les journaux d'archive lors d'un ancien job RMAN de sauvegarde.
Si l'ancien logiciel gère le journal d'archive, désactivez les jobs de suppression des journaux d'archive dans l'ancien logiciel de sauvegarde au début du job de sauvegarde Backup and DR, et reprenez les jobs 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 purgés lors d'un job de sauvegarde de base de données, il est possible que cette sauvegarde de base de données ne puisse pas être récupérée.

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

Par défaut, le paramètre DO NOT UNCATALOG dans les détails et les paramètres de l'application 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 supprimée du catalogue à la fin du job. Si vous définissez cette option sur Oui, le temps de sauvegarde des bases de données comportant un grand nombre de fichiers de données est optimisé. Pour ce faire, le catalogue de sauvegarde des fichiers de données RMAN est conservé après chaque job de sauvegarde. Toutefois, il interfère avec d'autres produits de sauvegarde.

Exigence Définissez les détails et les paramètres de l'application Backup and DR Do not uncatalog sur Non.
Bonne pratique Les sauvegardes de bases de données Backup and DR sont incrémentielles et permanentes. 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 Backup and DR avec un instantané interne du disque de sauvegarde. Les exécutions de sauvegarde incrémentielle RMAN suivantes avec fusion incrémentielle RMAN sur le disque de sauvegarde Backup and DR mettent à 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 des sauvegardes s'exécute après la sauvegarde de base de données Backup and DR, tous les fichiers de données de sauvegarde sous la sauvegarde Backup and DR sont marqués comme obsolètes dans les métadonnées RMAN. Si le paramètre "Détails et paramètres de l'application Backup and DR" Do not uncatalog est défini sur Oui, l'erreur suivante s'affiche : Échec du catalogage des copies d'images à partir de l'appareil intermédiaire et la sauvegarde échoue. Définissez Do not uncatalog sur Non pour que la fonctionnalité coexiste 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 de base de données Oracle (BCT)

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

  • Backup and DR "incrémentiel pour toujours" est compatible avec les bases de données dont le suivi des modifications de blocs est activé ou désactivé. Si la BCT n'est pas activée, le temps de sauvegarde incrémentielle augmente.

  • Le suivi des blocs modifiés 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 suivi des blocs modifiés 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 de la sauvegarde incrémentielle lorsque le suivi des blocs modifiés sur la base de données n'est pas activé.

Protéger les bases de données Oracle dans un groupe de cohérence Backup and DR

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 à partir 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 et de développement, ainsi que d'agilité métier.

Bases de données Oracle avec TDE

Backup and DR est compatible avec différentes méthodes de capture et de présentation pour les bases de données Oracle sous différentes configurations. Cela inclut les opérations de sauvegarde, de récupération et de montage compatibles avec les applications 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 de portefeuille peuvent être copiés du serveur source de sauvegarde vers le serveur de montage cible, et Oracle est configuré pour y accéder.
  • Si les fichiers de portefeuille Oracle sont stockés sur un appareil central et partagé sur le réseau, l'instance Oracle cible du point de montage Appaware doit être configurée pour y accéder.

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

    1. Montez la base de données sur l'hôte cible de manière standard.
    2. Copiez les fichiers du portefeuille depuis le montage de base de données standard vers l'hôte cible, puis configurez Oracle pour qu'il les utilise.
    3. Démontez la base de données de l'hôte cible.
    4. Effectuez un montage Application Aware 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 appliances 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/récupération est connectée via iSCSI ou Oracle dNFS sur le réseau (et non dans le chemin de données).

  • La sauvegarde RMAN utilise RMAN pour écrire directement dans un 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 les sauvegardes RMAN mises à jour de manière incrémentielle, en faisant progresser les sauvegardes de copie d'image.

Capture Backup and DR des données Exadata et d'ExaCC

L'agent Backup and DR doit être installé sur le serveur Exadata pour faciliter la communication avec l'appliance de sauvegarde/récupération et pour 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 au serveur Exadata en tant que cible iSCSI. Le format de capture des données peut être Groupe de disques ASM ou 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/récupération et 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 Backup and 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 n'existe pas dans le profil CRS.

  4. Créez un groupe de disques ASM en tant que redondance externe à l'aide du disque Backup and DR.

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

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

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

Oracle direct NFS (dNFS) est un client NFS (Network File System) optimisé qui offre un accès plus rapide et plus évolutif au stockage NFS situé sur des périphériques de stockage NAS (accessibles via TCP/IP). Direct NFS 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 le système de fichiers en tant que partage NFS.

L'agent Backup and DR expose et mappe les disques Backup and DR sur le serveur Exadata en tant que partage NFS.

Conditions préalables pour dNFS sur le 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 dans le système de fichiers sur le partage dNFS présenté par l'appliance de sauvegarde/récupération.

Remettre en ligne les 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 sur lequel la copie Backup and DR est montée, ou si des sauvegardes Backup and DR sont en cours pour la base de données au moment du redémarrage/plantage, suivez ces étapes pour remonter le groupe de disques Backup and DR :

  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 l'est également.

  2. Redémarrez l'agent Backup and DR (à partir de la racine).

  3. Définissez 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 est démonté, montez-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.

Étapes suivantes

Découvrez les conditions requises pour sauvegarder une base de données Oracle.

Autre documentation pour Backup and DR for Oracle