Guide de dépannage de Veritas NetBackup™
- Introduction
- Procédures de dépannage
- Dépannage des problèmes NetBackup
- Dépannage des connexion au proxy vnetd
- Dépannage de la révocation des certificats de sécurité
- Vérification du nom d'hôte et des entrées de service dans NetBackup
- 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 liés à PBX
- Résolution des problèmes de validation de l'hôte distant
- Dépannage d'Auto Image Replication
- Utilisation des utilitaires NetBackup
- Utilitaire de support NetBackup (nbsu)
- À propose de l'utilitaire de vérification de la cohérence NetBackup (NBCC)
- A propos des utilitaires de test robotique
- Reprise après incident
- 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
- À propos de la récupération du catalogue NetBackup
- A propos de la récupération de catalogue NetBackup et de l'OpsCenter
- À propos de la récupération du catalogue NetBackup entier
- A propos de la récupération des fichiers image de catalogue de NetBackup
- A propos de la récupération de la base de données relationnelle NetBackup
À 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)
# chemin_installation\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 et 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)
Destination client (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 Chemin_installation\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)
chemin_installation\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.