Guide de dépannage de Veritas NetBackup™
- Introduction
- Procédures de dépannage
- À propos des procédures de dépannage
- Dépannage des problèmes de NetBackup
- Dépannage des problèmes d'installation
- Dépannage des problèmes de configuration
- Résolution des problèmes de configuration de périphérique
- Test du serveur maître et des clients
- Test des serveurs de médias et des clients
- Résolution des problèmes de communication réseau avec des clients UNIX
- Résolution des problèmes de communication réseau avec des clients Windows
- Dépannage des connexions au proxy vnetd
- Exigences relatives à la connexion de proxy vnetd
- Première étape de dépannage des connexions de proxy vnetd
- Vérifier que le processus vnetd et les proxys sont actifs
- Vérifier que les connexions de l'hôte sont traitées par proxy
- Tester les connexions de proxy vnetd
- Examiner les fichiers journaux des processus de connexion et d'acceptation
- Affichage des fichiers journaux de proxy vnetd
- Dépannage de la révocation des certificats de sécurité
- Dépannage des problèmes avec les certificats SSL révoqués du fournisseur cloud
- Dépannage des problèmes de téléchargement de liste de révocation des certificats du fournisseur cloud
- Impact de la liste de révocation d'un hôte sur le dépannage de la révocation de certificats
- Le travail NetBackup échoue parce qu'un certificat est révoqué ou que les listes CRL sont indisponibles
- Le travail NetBackup échoue en raison d'une erreur réseau apparente
- Le travail NetBackup échoue en raison d'une ressource indisponible
- Le certificat de sécurité du serveur maître est révoqué
- Détermination de l'état du certificat d'un hôte NetBackup
- Dépannage des problèmes de révocation des certificats signés par une autorité de certification externe
- À propos du dépannage des réseaux et des noms d'hôte
- Vérification du nom d'hôte et des entrées de service dans NetBackup
- Exemple des entrées de nom d'hôte et de service sur le serveur maître et le client d'UNIX
- Exemple d'entrées de nom d'hôte et de service sur le serveur maître et le serveur de médias UNIX
- Exemple d'entrées de nom d'hôte et de services sur des clients PC UNIX
- Exemple des entrées de nom d'hôte et de service sur le serveur UNIX se connectant à plusieurs réseaux
- À propos de l'utilitaire bpclntcmd
- Utilisation de la fenêtre Propriétés de l'hôte pour accéder aux paramètres de configuration
- Résolution des problèmes de disque plein
- Considérations de dépannage d'un média figé
- Résolution des problèmes avec les services Web NetBackup
- Résolution des problèmes avec le certificat de serveur Web NetBackup
- Résolution des problèmes liés à PBX
- Résolution des problèmes de validation de l'hôte distant
- Dépannage d'Auto Image Replication
- Dépannage des performances de la carte d'interface réseau
- À propos des entrées SERVER dans le fichier bp.conf
- À propos des problèmes d'unités de stockage non disponibles
- Résolution d'une défaillance des opérations d'administration NetBackup sous Windows
- Résolution de texte déformé affiché dans NetBackup Administration Console sur un ordinateur UNIX
- Dépannage des messages d'erreur dans la console d'administration NetBackup
- Espace disque supplémentaire pour les journaux et les fichiers temporaires pour la Console d'administration NetBackup.
- Impossible de se connecter à la console d'administration NetBackup après la configuration des autorités de certification externes
- Dépannage des problèmes relatifs aux certificats externes basés sur fichier
- Dépannage des problèmes relatifs au magasin de certificats Windows
- Dépannage des échecs de sauvegarde
- Résolution des problèmes de défaillance de la sauvegarde avec les clients ou les serveurs NAT
- Résolution de problèmes au niveau du service NetBackup Messaging Broker (ou nbmqbroker)
- Problèmes de notification par e-mail pour les systèmes Windows
- Problèmes de configuration du KMS
- Problèmes lors du lancement de la migration de l'autorité de certification NetBackup en raison d'une taille de clé importante
- Utilisation des utilitaires NetBackup
- À propos des utilitaires de dépannage NetBackup
- À propos des utilitaires d'analyse pour les journaux de débogage de NetBackup
- À propos de l'Assistant Consignation
- Utilitaires de dépannage réseau
- À propos de l'utilitaire de support NetBackup (nbsu)
- À propos de l'utilitaire de vérification de la cohérence NetBackup (NBCC)
- À propos de l'utilitaire NBCCR (NetBackup Consistency Check Repair)
- A propos de l'utilitaire nbcplogs
- A propos des utilitaires de test robotique
- Reprise après incident
- À propos de la reprise après incident
- À propos des exigences relatives à la reprise après incident
- Packages de reprise après incident
- À propos des paramètres de reprise après incident
- Pratiques recommandées en matière de sauvegarde
- Procédures de récupération de disque pour UNIX et Linux
- À propos de la récupération d'un serveur NetBackup faisant partie d'un cluster sous UNIX et Linux
- Procédures de récupération de disque pour Windows
- À propos de la récupération d'un serveur NetBackup faisant partie d'un cluster sous Windows
- Génération d'un certificat sur un serveur maître en cluster après une installation de reprise après incident
- À propos de la restauration de package de reprise après incident
- À propos de la variable d'environnement DR_PKG_MARKER_FILE
- Restauration de package de reprise après incident sous Windows
- Restauration de package de reprise après incident sous Unix
- À propos de la récupération du catalogue NetBackup
- A propos de la récupération du catalogue NetBackup sur les ordinateurs Windows
- À propos de la récupération du catalogue NetBackup à partir de périphériques de disque
- A propos de la récupération de catalogue NetBackup et des liens symboliques
- A propos de la récupération de catalogue NetBackup et de l'OpsCenter
- Exemple de message électronique de reprise après incident NetBackup
- À propos de la récupération du catalogue NetBackup entier
- Établissement d'une connexion au serveur de médias NAT avant la récupération de catalogue
- A propos de la récupération des fichiers image du catalogue NetBackup
- A propos de la récupération de la base de données relationnelle NetBackup
- Récupération des fichiers de la base de données relationnelle NetBackup à partir d'une sauvegarde
- Récupération des fichiers de base de données relationnelle NetBackup à partir de l'emplacement intermédiaire
- À propos du traitement de la base de données relationnelle lors de la sauvegarde intermédiaire
- Récupération du catalogue NetBackup lorsque le contrôle d'accès à NetBackup est configuré
- Récupération du catalogue NetBackup à partir d'une copie secondaire d'une sauvegarde de catalogue
- Récupération du catalogue NetBackup sans fichier de reprise après incident
- Récupération d'une sauvegarde de catalogue en ligne dirigée par l'utilisateur NetBackup depuis la ligne de commande
- Restauration des fichiers d'une sauvegarde de catalogue en ligne NetBackup
- Déblocage des médias de récupération de catalogue en ligne de NetBackup
- Étapes à exécuter quand vous recevez l'état de sortie 5988 pendant une récupération de catalogue
- Index
À propos du dépannage des réseaux et des noms d'hôte
Dans une configuration avec de multiples réseaux et des clients portant plusieurs noms d'hôte, les administrateurs NetBackup doivent configurer les entrées de la politique avec soin. Ils doivent tenir compte de la configuration réseau (configuration physique, noms d'hôte et alias, NIS/DNS, tables de routage, etc.). Si les administrateurs veulent lancer les sauvegardes et restaurer les données sur plusieurs chemins réseau spécifiques, ils doivent étudier ces éléments.
Pour une sauvegarde, NetBackup se connecte au nom d'hôte configuré dans la politique. Le code réseau du système d'exploitation résout ce nom et envoie la connexion via le chemin réseau défini par les tables de routage du système. Le fichier bp.conf n'est pas pris en compte dans cette décision.
Pour les restaurations à partir du client, le client se connecte au serveur maître. Par exemple, sur un système UNIX, le serveur maître est le premier nommé dans le fichier /usr/openv/netbackup/bp.conf. Sur un système Windows, le serveur maître est spécifié dans la liste déroulante de la boîte de dialogue Spécifier les ordinateurs NetBackup et le type de politique. Pour ouvrir cette boîte de dialogue, lancez l'interface Sauvegarde, archivage et restauration de NetBackup et cliquez sur dans le menu Fichier. Le code réseau du client qui mappe le nom du serveur à une adresse IP détermine le chemin d'accès réseau au serveur.
Lorsque la connexion est établie, le serveur détermine le nom configuré du client à partir du nom d'homologue de sa connexion au serveur.
Le nom d'homologue est dérivé de l'adresse IP de la connexion. Cela signifie que l'adresse doit être traduite en nom d'hôte (à l'aide de la routine réseau gethostbyaddr()). Ce nom est visible dans le journal de débogage de bprd lorsqu'une connexion est établie, comme l'illustre la ligne suivante :
Connection from host peername ipaddress ...
Le nom configuré du client est alors dérivé du nom d'homologue en interrogeant le processus bpdbm sur les systèmes UNIX. Sur les systèmes Windows, vous devez interroger le service Gestionnaire de bases de données de NetBackup.
Le processus bpdbm compare le nom d'homologue à une liste comprenant les noms de :
Tous les clients pour lesquels une sauvegarde a été tentée
Tous les clients de toutes les politiques
La comparaison est d'abord une comparaison de chaînes. La comparaison est effectuée en comparant les noms d'hôte et les alias récupérés à l'aide de la fonction réseau gethostbyname().
Si aucune des comparaisons ne réussit, une méthode, plus brutale, compare tous les noms et alias à l'aide de gethostbyname().
Le nom configuré correspond à la première comparaison réussie. Notez que d'autres comparaisons peuvent également trouver des correspondances si des alias ou d'autres "noms réseau" sont configurés.
Si la comparaison échoue, le nom d'hôte du client tel qu'il est renvoyé par la fonction gethostname() sur le client est utilisé comme nom configuré. Exemple d'échec de comparaison : le client change de nom d'hôte mais son nouveau nom d'hôte ne se trouve encore dans aucune politique.
Ces comparaisons sont consignées dans le journal de débogage de bpdbm si l'option VERBOSE est définie. Vous pouvez déterminer le nom configuré d'un client à l'aide de la commande bpclntcmd sur le client. Par exemple :
# /usr/openv/netbackup/bin/bpclntcmd -pn (UNIX)
# install_path\NetBackup\bin\bpclntcmd -pn (Windows)
expecting response from server wind.abc.me.com danr.abc.me.com danr 194.133.172.3 4823
Où la première ligne de sortie identifie le serveur vers lequel la demande est dirigée. La deuxième ligne de sortie correspond à la réponse du serveur dans l'ordre suivant :
Nom d'homologue de la connexion au serveur
Nom configuré du client
Adresse IP de la connexion au serveur
Numéro de port qui est utilisé dans la connexion
Lorsque le client se connecte au serveur, il envoie les trois noms suivants au serveur :
Browse client (Client de navigation)Requesting client (Client émetteur de la demande)Client cible
Le nom "browse client" est utilisé pour identifier les fichiers client à lister ou à partir desquels effectuer la restauration. L'utilisateur sur le client peut modifier ce nom pour restaurer les fichiers d'un autre client. Par exemple, sur un client Windows, l'utilisateur peut modifier le nom du client à partir de l'interface Sauvegarde, archivage et restauration. Consultez l'aide en ligne de NetBackup pour obtenir des instructions. Cependant, pour que cette modification fonctionne, il faut que l'administrateur ait également apporté la modification correspondante sur le serveur.
Consultez le Guide de l'administrateur NetBackup, Volume I.
La valeur "requesting client" correspond à la valeur de la fonction gethostname() sur le client.
Le nom "destination client" est utilisé seulement si un administrateur transfère une restauration à un client depuis un serveur. Dans le cas d'une restauration utilisateur, les éléments destination client et requesting client sont identiques. Dans le cas d'une restauration d'administrateur, l'administrateur peut spécifier un nom différent pour "destination client".
Au moment où ces noms apparaissent dans le journal de débogage de bprd, le nom requesting client a été traduit en nom configuré du client.
Le nom utilisé pour se connecter de nouveau au client et effectuer la restauration correspond au nom d'homologue du client ou à son nom configuré. Le type de demande de restauration (par exemple, de la racine sur un serveur, d'un client vers un autre client, etc.) influence cette action.
Lorsqu'il modifie des noms de clients dans des politiques NetBackup pour des chemins de réseaux spécifiques, l'administrateur doit prendre en compte les éléments suivants :
Le nom client tel qu'il est configuré sur le client. Par exemple, sous UNIX, le nom client est CLIENT_NAME dans le fichier bp.conf du client. Sur un client Windows, il se trouve dans l'onglet Général de la boîte de dialogue Propriétés du client NetBackup. Pour ouvrir cette boîte de dialogue, sélectionnez dans le menu Fichier de l'interface Sauvegarde, archivage et restauration.
Le client tel qu'il est actuellement nommé dans la configuration de la politique.
Les images de sauvegarde et d'archive client qui existent déjà, telles qu'elles sont enregistrées dans le répertoire images sur le serveur maître. Sur un serveur UNIX, le répertoire images se trouve sous /usr/openv/netbackup/db/images. Sur un serveur NetBackup Windows, le répertoire images se trouve sous install_path\NetBackup\db\images.
L'un de ces noms de clients peut nécessiter une modification manuelle de la part de l'administrateur dans le cas suivant : un client possède plusieurs connexions réseau au serveur et les restaurations à partir du client échouent en raison d'un problème de connexion.
Sous UNIX, le programme de domaine public traceroute (non fourni avec NetBackup) peut souvent fournir des informations importantes sur la configuration d'un réseau. Certains fournisseurs de systèmes incluent ce programme dans leurs systèmes. Pour Windows, utilisez la commande tracert.
Le serveur maître ne parviendra peut-être pas à répondre aux demandes client, si les services de nom de domaine (DNS) sont utilisés et si les événements suivants se produisent : le nom que le client obtient via sa bibliothèque gethostname() (UNIX) ou la fonction réseau gethostbyname() (Windows) est inconnu du DNS sur le serveur maître (les configurations client et serveur peuvent déterminer si c'est le cas). La fonction gethostname() ou gethostbyname() sur le client peut renvoyer un nom d'hôte non qualifié que le DNS du serveur maître ne peut pas résoudre.
Bien que vous puissiez modifier le fichier d'hôtes DNS du client ou du serveur maître, cette solution n'est pas toujours désirable. C'est pour cela que NetBackup fournit un fichier spécial sur le serveur maître. Ce fichier se trouve dans :
/usr/openv/netbackup/db/altnames/host.xlate(UNIX)
install_path\NetBackup\db\altnames\host.xlate (Windows)
Vous pouvez créer et modifier ce fichier de façon à forcer la traduction désirée des noms d'hôte de client NetBackup.
Chaque ligne du fichier host.xlate contient trois éléments : une clé numérique et deux noms d'hôte. Chaque ligne est alignée à gauche et un espace sépare chaque élément.
key hostname_from_client client_as_known_by_server
Les indications suivantes décrivent les variables précédentes :
La variable clé est une valeur numérique utilisée par NetBackup pour spécifier les cas où la traduction doit être réalisée. En théorie, cette valeur doit toujours être égale à 0 (zéro) : cela indique une conversion des noms qui sont configurés.
La variable nomhote_client représente la valeur à convertir. Cette valeur doit correspondre au nom que la fonction gethostname() du client obtient et envoie au serveur dans la demande.
La variable client_connu_par_le_serveur représente le nom à remplacer par la variable nom_hôte_client pour répondre aux demandes. Ce nom doit correspondre au nom configuré dans la configuration de NetBackup sur le serveur maître. Il doit également être connu des services réseau du serveur maître.
Voici un exemple :
0 danr danr.eng.aaa.com
Quand le serveur maître reçoit une demande d'un nom client configuré (clé numérique 0), le nom danr remplace toujours le nom danr.eng.aaa.com. Le problème est résolu, lorsque :
La fonction gethostname() du client renvoie le nom
danr.La fonction gethostbyname() des services réseau du serveur maître n'a pas identifié le nom
danr.Le client était configuré et nommé dans la configuration de NetBackup en tant que danr.eng.aaa.com, et ce nom est également connu des services réseau du serveur maître.