Guide de l'administrateur Veritas NetBackup™ for Oracle
- Introduction
- Démarrage rapide de NetBackup for Oracle
- Installation de NetBackup for Oracle
- A propos de la liaison d'Oracle RMAN avec NetBackup pour UNIX
- Configuration de politique Oracle
- Préparation à la configuration de NetBackup for Oracle
- Gestion des instances pour une politique intelligente Oracle
- A propos des politiques intelligentes d'Oracle (OIP)
- A propos des politiques Oracle basées sur un modèle ou un script
- A propos de l'ajout de sélections de sauvegarde à une politique Oracle
- A propos de la configuration de l'environnement d'exécution
- A propos de la création de modèles et de scripts de shell
- A propos de la création manuelle de scripts RMAN
- Exécution de sauvegardes et de restaurations Oracle
- A propos de NetBackup pour des sauvegardes d'Oracle
- A propos des restaurations NetBackup for Oracle
- Redirection d'une restauration vers un autre client
- Utilisation de NetBackup for Oracle dans un environnement en cluster Microsoft Windows
- Récupération assistée
- Dépannage de la récupération assistée
- NetBackup for Oracle avec Snapshot Client
- A propos du dépannage de NetBackup for Oracle avec Snapshot Client
- Fonctionnement de NetBackup for Oracle avec Snapshot Client
- A propos de la configuration de Snapshot Client avec NetBackup for Oracle
- Restauration de NetBackup for Oracle à partir d'une sauvegarde par cliché
- A propos de la configuration des sauvegardes BLI NetBackup for Oracle sous UNIX
- A propos des effets de Snapshot Client
- À propos de la prise en charge d'Oracle pour Replication Director
- Dépannage
- Dépannage des erreurs de sauvegarde ou de restauration RMAN
- Annexe A. Clusters d'applications réelles
- Annexe B. Pratiques d'excellence pour protéger Oracle RAC avec NetBackup
- Annexe C. Pratiques d'excellence de déduplication
- Annexe D. Prise en charge Snapshot Client de SFRAC
- Annexe E. Sauvegardes incrémentielles de niveau bloc émanant de scripts sans RMAN sur systèmes UNIX et Linux
- Vérification des paramètres d'installation pour des sauvegardes incrémentielles de blocs sans RMAN
- Création de politiques NetBackup pour les sauvegardes incrémentielles de bloc basées sur les scripts
- Création de scripts de notification pour les sauvegardes incrémentielles de bloc
- Réalisation de sauvegardes et restaurations
- A propos du dépannage des erreurs de sauvegarde ou de restauration
- Annexe F. Archivage XML
- Exportation/importation XML dans NetBackup for Oracle
- Modèles d'exportation XML et scripts shell
- Création de l'archive d'une exportation XML
- Restauration d'une archive d'exportation XML
- A propos de la redirection d'une restauration de l'archive d'une exportation XML vers un autre client
- Dépannage des erreurs d'importation/exportation XML
- Annexe G. Enregistrer des emplacements autorisés
Configuration d'exemple RAC : le nom du basculement existe et la charge de la sauvegarde est répartie
Dans cette configuration, le serveur maître NetBackup peut toujours utiliser le nom de basculement pour accéder à un hôte actif afin d'exécuter le script de sauvegarde. Cependant, étant donné que RMAN assigne les canaux sur les deux hôtes, le serveur de médias NetBackup doit se reconnecter à l'hôte correspondant pour obtenir les données de chaque demande. Par conséquent, les images de sauvegarde sont enregistrées sous deux noms de client différents. Ces derniers diffèrent également du nom de basculement utilisé pour exécuter le script.
Configurez la politique pour spécifier le nom de basculement en tant que nom de client. Par conséquent, la planification automatique exécute le script de sauvegarde sur un hôte actif.
Tous les hôtes du cluster doivent avoir accès au script de sauvegarde ou à une copie identique. Le système de fichiers mis en cluster constitue un bon emplacement.
Ne configurez pas le script de sauvegarde pour envoyer une valeur unique pour NB_ORA_CLIENT. Le serveur de médias NetBackup doit se reconnecter à l'hôte correspondant. Cela dépend de l'hôte ayant lancé la demande de sauvegarde de l'utilisateur. Sélectionnez l'une des trois méthodes suivantes pour effectuer cette tâche :
Configurez la sauvegarde de façon à fournir un nom de client spécifique à l'hôte avec chaque demande de sauvegarde à l'aide de l'une des trois options suivantes :
Configurez RMAN pour lier les canaux spécifiques à des instances spécifiques et pour envoyer les noms de client associés sur chaque canal pour le stockage d'images de sauvegarde. Configurez également RMAN pour qu'il se reconnecte à l'hôte à l'origine de la demande de transfert de données. N'utilisez pas le nom de basculement car ce dernier n'est actif que sur un seul hôte.
ALLOCATE CHANNEL 1 ... PARMS='ENV=(NB_ORA_CLIENT=vipname1)' CONNECT='sys/passwd@vipname1'; ALLOCATE CHANNEL 2 ... PARMS='ENV=(NB_ORA_CLIENT=vipname2)' CONNECT='sys/passwd@vipname2'; ALLOCATE CHANNEL 3 ... PARMS='ENV=(NB_ORA_CLIENT=vipname1)' CONNECT='sys/passwd@vipname1'; ALLOCATE CHANNEL 4 ... PARMS='ENV=(NB_ORA_CLIENT=vipname2)' CONNECT='sys/passwd@vipname2';
Remarque :
Si un ou plusieurs de ces nœuds sont arrêtés, ces opérations d'allocation échouent et entraînent l'échec de la sauvegarde.
Vous pouvez également configurer Oracle pour lier les canaux spécifiques à des hôtes spécifiques.
CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname1' PARMS "ENV=(NB_ORA_CLIENT=vipname1)"; CONFIGURE CHANNEL 2 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname2' PARMS "ENV=(NB_ORA_CLIENT=vipname2)"; CONFIGURE CHANNEL 3 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname1' PARMS "ENV=(NB_ORA_CLIENT=vipname1)"; CONFIGURE CHANNEL 4 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname2' PARMS "ENV=(NB_ORA_CLIENT=vipname2)";
Sinon et par défaut, la sauvegarde utilise des noms de client qui doivent être différents pour chaque hôte et correspondent en général au nom d'hôte physique.
Etant donné que les valeurs de la chaîne CLIENT_NAME ou NB_ORA_CLIENT doivent être différentes du nom de basculement dans la politique, le serveur maître NetBackup ne peut pas accepter les demandes de sauvegarde de l'utilisateur. Vous devez mettre en application une des options suivantes.
: modifiez la politique existante et le script de sauvegarde pour prendre en charge plusieurs noms de client.
Ajoutez les deux noms de VIP ou les deux noms d'hôte à la politique, en plus du nom de basculement.
Modifiez le script pour obtenir le code d'état 0, si le nom du client n'est pas le nom de basculement.
: alternativement, utilisez une politique distincte pour accepter les demandes de sauvegarde.
Créez une deuxième politique pour recevoir les demandes de sauvegarde RMAN.
Définissez le type de politique sur Oracle.
Définissez la politique pour qu'elle contienne NB_ORA_CLIENT ou les noms de client tels que configurés dans les informations précédentes.
La planification de sauvegarde d'application doit disposer d'une fenêtre ouverte pour accepter les sauvegardes.
La politique n'a pas besoin d'un script de sauvegarde ou d'une planification automatique.
Configurez le script de sauvegarde de façon à fournir le nom de cette politique à chaque demande de sauvegarde par l'utilisateur :
ALLOCATE CHANNEL...PARMS='ENV=(NB_ORA_POLICY=<second_policy_name>)'; or SEND 'NB_ORA_POLICY=<second_policy_name>';
La configuration du serveur maître NetBackup doit autoriser l'accès des noms d'hôte physique à toutes les images de sauvegarde. Les images sont stockées sous les noms d'hôte ou les noms de VIP comme suit :
cd /usr/openv/netbackup/db/altnames echo "failover_name" >> hostname1 echo "hostname1" >> hostname1 echo "vipname1" >> hostname1 echo "hostname2" >> hostname1 echo "vipname2" >> hostname1 cp hostname1 hostname2
Vous pouvez utiliser Réseau préféré ou tout autre moyen pour forcer NetBackup à utiliser les adresses IP associées aux noms de VIP pour les demandes de sauvegarde sortantes de l'utilisateur. Si vous utilisez cette méthode, vous devez permettre aux noms de VIP d'accéder à toutes les images de sauvegarde.
cd /usr/openv/netbackup/db/altnames cp hostname1 vipname1 cp hostname1 vipname2
: le planificateur NetBackup démarre trois travaux automatiques et chacun exécute le script de sauvegarde (dont deux sur l'hôte qui héberge le nom de basculement). Les deux exécutions du script de sauvegarde qui reçoivent les noms de VIP ou d'hôte se terminent immédiatement avec l'état 0. Le but est d'éviter une sauvegarde redondante et toute nouvelle tentative de sauvegarde. La troisième exécution du script de sauvegarde recevant le nom de basculement démarre RMAN. RMAN envoie ensuite les données de la sauvegarde à l'aide du nom de client correspondant pour l'instance ou d'hôte pour le canal. NetBackup enregistre les images de sauvegarde dans la politique d'initialisation à l'aide des deux noms de client.
: la première politique exécute le script de sauvegarde à l'aide du nom de basculement. RMAN envoie le nom de la deuxième politique et des noms de client configurés de chaque canal avec la demande de l'utilisateur de chaque hôte. La deuxième politique stocke les images de sauvegarde à l'aide des deux noms de client.
Les deux clients peuvent lancer la restauration. RMAN doit être configuré avec l'option " AUTOLOCATE ON;" pour demander les parties du jeu de sauvegardes de l'hôte ou de l'instance approprié ayant effectué la sauvegarde. Vous pouvez également effectuer une restauration à partir de l'hôte ou de l'instance si vous configurez chaque demande de restauration de façon à inclure le bon nom de client. Ce nom est le nom de client qui est utilisé lors du transfert pour stockage de la partie de jeu de sauvegarde.
SEND 'NB_ORA_CLIENT=client_name_used_by_backup'