Recherche dans <book_title>…

Guide de dépannage NetBackup™

Last Published: 2024-05-14

Product(s): NetBackup (10.4)

À 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, services de nom tels que NIS ou 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 principal. Par exemple, sur un ordinateur UNIX, le serveur principal est le premier nommé dans le fichier /usr/openv/netbackup/bp.conf. Sur un ordinateur Windows, le serveur principal est spécifié dans la liste déroulante Serveur à utiliser pour les sauvegardes et les restaurations 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 Spécifier les ordinateurs NetBackup et le type de politique 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, l'hôte cible détermine le nom d'hôte homologue de l'hôte de connexion. Si l'hôte cible est le serveur principal, il détermine également le nom configuré du client à partir du nom d'hôte pair.

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 getnameinfo()). Ce nom est affiché dans le journal de débogage de bpcd ou bprd lorsqu'une connexion est établie, comme l'illustre la ligne suivante :

bpcd: Connection from host peername ipaddress ...

bprd: Connection from host peername ipaddress ...

Sur un client, le nom d'hôte homologue pour le serveur de connexion doit correspondre à une entrée de serveur ou de serveur de médias dans la configuration locale NetBackup (correspondance de chaîne ou comparaison avec les informations getaddrinfo() de chaque entrée de serveur).

Sur le serveur principal, la comparaison est plus complexe.

Le processus bpdbm est interrogé sur les hôtes UNIX/Linux ou le service du gestionnaire de bases de données NetBackup sur les hôtes Windows pour dériver le nom configuré du client à partir du nom d'homologue.

Le processus bpdbm compare le nom d'homologue à une liste comprenant les noms de :

Tous les clients pour lesquels une sauvegarde a été exécutée
Tous les clients de toutes les politiques

La comparaison est d'abord une comparaison de chaînes. La comparaison est effectuée en rapprochant le nom d'homologue de la liste de noms de clients.

Si aucune des comparaisons n'aboutit, une méthode plus agressive/contraignante compare tous les noms et alias trouvés à l'aide de getaddrinfo() pour chaque nom de client figurant dans la liste.

Le nom configuré correspond à la première comparaison réussie.

Si la comparaison échoue, bprd remplace le client émetteur de la demande (comme suit) par le nom d'homologue dans la plupart des cas, car les noms d'hôte figurant dans la demande ne sont pas placés sous contrôle administratif comme le réseau et les configurations NetBackup.

Exemple d'échec de comparaison :

Le client a une nouvelle interface réseau et a modifié la première entrée de serveur pour tirer profit du nouveau réseau. Les services de nom sur le serveur principal résolvent la nouvelle adresse IP source du client en un nom de pair qui n'est un alias réseau pour aucun client dans les politiques.

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
Adresse IP de la connexion au serveur

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.

Le client émetteur de la demande correspond à la valeur de CLIENT_NAME ou 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 reconnecter au client et terminer 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 Propriétés du client NetBackup 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 existantes, telles qu'elles sont enregistrées dans le répertoire images sur le serveur principal. 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 lorsqu'un client dispose de plusieurs connexions réseau au serveur ou lorsque les demandes de liste ou de restauration du client échouent en raison d'un problème de connexion.

Les programmes traceroute (UNIX) et tracert (Windows) peuvent souvent fournir des informations précieuses sur la configuration du réseau.

Le serveur principal peut ne pas répondre aux demandes client si les services de nom de domaine (DNS) sont utilisés et si le nom que le client obtient via sa bibliothèque gethostname() est inconnu du DNS sur le serveur principal. Les configurations du client et du serveur peuvent déterminer si ce cas de figure existe. La fonction gethostname() sur le client peut renvoyer un nom d'hôte non qualifié que le DNS du serveur principal est incapable de résoudre.

Bien que vous puissiez modifier les services de nom, y compris le fichier d'hôtes, cette solution n'est pas toujours souhaitable. C'est pourquoi NetBackup fournit un fichier spécial sur le serveur principal. 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 peername 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.
peername est la valeur à traduire. Il s'agit de la valeur vers laquelle getnameinfo() a résolu sur le serveur principal l'adresse IP source à partir de laquelle le client s'est connecté.
La variable client_as_known_by_server représente le nom à remplacer par la variable peername pour répondre aux demandes. Ce nom doit correspondre au nom défini dans la configuration NetBackup sur le serveur principal, généralement un client d'une politique. Il doit également être connu des services de nom utilisés par le serveur principal et des services réseau du serveur de médias qui effectue la sauvegarde.

Voici un exemple :

0 danr danr.eng.aaa.com

Lorsque le serveur principal reçoit une demande concernant un nom de client configuré (clé numérique 0), le nom remplace toujours le nom de pair.