Guide de dépannage de Veritas NetBackup™

Étape 1

Créez les répertoires de journal de débogage.

Pendant les relances de communication, les journaux de débogage fournissent des informations de débogage détaillées, qui peuvent vous aider à analyser le problème.

Utilisez le répertoire de journaux bprd pour déboguer la communication de client à serveur principal, non les problèmes de communication client à serveur de médias.

Étape 2

Testez une configuration nouvelle ou modifiée.

Étape 3

Vérifiez la résolution du nom.

Pour vérifier la résolution du nom, exécutez la commande suivante sur le serveur principal et les serveurs de médias :

# bpclntcmd -hn client name

Si les résultats sont inattendus, passez en revue la configuration de ces services de résolution du nom : fichier nsswitch.conf, fichier hosts, fichier ipnodes et fichier resolv.conf.

Exécutez également les commandes suivantes sur le client pour une recherche en avant et inverse de contrôle de nom du serveur maître et du serveur de médias qui effectuent la sauvegarde :

# bpclntcmd -hn server name

# bpclntcmd -ip IP address of server

Étape 4

Vérifiez la connectivité réseau.

Vérifiez la connectivité réseau entre le client et le serveur en exécutant une commande ping vers le client à partir du serveur.

# ping clientname

Où clientname est le nom du client comme configuré dans la configuration de politique NetBackup.

Par exemple, pour exécuter une commande ping sur un client de politique nommé ant :

# ping ant 
    ant.nul.nul.com: 64 byte packets
    64 bytes from 199.199.199.24: icmp_seq=0. time=1. ms
    ----ant.nul.nul.com PING Statistics----
    2 packets transmitted, 2 packets received, 0% packet 
    loss round-trip (ms)  min/avg/max = 1/1/1

Une commande ping réussie vérifie la connectivité entre le client et le serveur. Si la commande ping échoue et qu'ICMP n'est pas bloqué entre les hôtes, résolvez le problème de réseau en dehors de NetBackup avant de poursuivre.

Certaines formes de la commande ping permettent d'exécuter une commande ping vers le port bpcd sur le client comme dans la commande suivante :

# ping ant 1556 

Exécutez une commande ping 1556 (PBX) et 13724 (vnetd) dans l'ordre, le même ordre que NetBackup essaie par défaut. Vous savez alors quels ports sont fermés de sorte que vous pouvez les ouvrir pour des tentatives de connexion plus efficaces.

Étape 5

Assurez-vous que le client écoute les connexions bpcd sur le port correct.

Sur le client, exécutez une des commandes suivantes (selon la plate-forme et le système d'exploitation) :

netstat -a | grep bpcd
netstat -a | grep 13782
rpcinfo -p | grep 13782

Répétez pour 1556 (PBX) et 13724 (vnetd). Si aucun problème ne se produit avec les ports, la sortie prévue est la suivante :

# netstat -a | egrep '1556|PBX|13724|vnetd|13782|bpcd' | grep LISTEN
 *.1556          *.*      0      0 49152      0 LISTEN
 *.13724         *.*      0      0 49152      0 LISTEN
 *.13782         *.*      0      0 49152      0 LISTEN

LISTEN indique que le client écoute les connexions sur le port.

Si les processus de NetBackup s'exécutent correctement, la sortie prévue est comme suit :

# ps -ef | egrep 'pbx_exchange|vnetd|bpcd' | grep -v grep
root   306 1 0 Jul 18 ? 13:52 /opt/VRTSpbx/bin/pbx_exchange
root 10274 1 0 Sep 13 ?  0:11 /usr/openv/netbackup/bin/vnetd -standalone
root 10277 1 0 Sep 13 ?  0:45 /usr/openv/netbackup/bin/bpcd -standalone

Répétez la procédure sur les serveurs maîtres et de médias pour tester la communication avec le client.

Étape 6

Connectez-vous au client via telnet.

Sur le client, telnet sur 1556 (PBX) et 13724 (vnetd). Vérifiez les deux ports pour vous assurer qu'une connexion est établie sur au moins un d'entre eux. Si la connexion telnet réussit, conservez la connexion jusqu'à après l'étape 8, puis arrêtez-la avec les touches Ctrl-c.

telnet clientname 1556
telnet clientname 13724

Où clientname est le nom du client comme configuré dans la configuration de politique NetBackup.

Par exemple,

# telnet ant vnetd
Trying 199.999.999.24 ...
Connected to ant.nul.nul.com.
Escape character is '^]'.

Dans cet exemple, telnet peut établir une connexion avec le client ant.

Répétez la procédure sur les serveurs maîtres et de médias pour tester la communication avec le client.

Étape 7

Identifiez le socket sortant sur l'hôte de serveur.

Sur les serveurs maîtres et de médias : utilisez la commande suivante pour identifier le socket sortant utilisé pour la commande telnet de l'étape 6. Spécifiez l'adresse IP appropriée à laquelle le serveur résout le client de politique. Notez l'IP source (10.82.105.11), le port source (45856) et le port de destination (1556).

# netstat -na | grep '<client_IP_address>' | egrep '1556|13724' 
10.82.105.11.45856 10.82.104.99.1556 49152 0 49152 0 ESTABLISHED

Si telnet est toujours connecté et qu'un socket n'est pas affiché : supprimez le filtrage de numéro de port et observez le numéro de port auquel le site a mappé le nom de service. Vérifiez que le processus écoute le numéro de port identifié à l'étape 5.

$ netstat -na | grep '<client_IP_address>' 
10.82.105.11.45856 10.82.104.99.1234 49152 0 49152 0 ESTABLISHED

Si le socket est dans un état SYN_SENT au lieu d'un état ESTABLISHED, l'hôte de serveur essaye d'établir la connexion. Cependant, un pare-feu empêche le SYN TCP sortant d'atteindre l'hôte client ou le TCP SYN+ACK revenant d'atteindre l'hôte de serveur.

Étape 8

Confirmez que la connexion telnet atteint cet hôte client.

Sur les serveurs maîtres et de médias, pour confirmer que la connexion telnet atteint cet hôte client, exécutez la commande suivante :

$ netstat -na | grep '<source_port>'
10.82.104.99.1556  10.82.105.11.45856  49152 0 49152 0 ESTABLISHED

Étape 9

Vérifiez les communications entre le client et le serveur maître.

Pour vérifier les communications du client vers le serveur maître, utilisez l'utilitaire bpclntcmd. Quand les commandes -pn et -sv s'exécutent sur un client NetBackup, elles lancent des enquêtes au serveur maître NetBackup (comme configuré dans le fichier client bp.conf). Le serveur maître renvoie les informations au client ayant effectué la demande. Plus d'informations concernant bpclntcmd sont disponibles.

Se reporter à À propos de l'utilitaire bpclntcmd.

Les journaux de débogage PBX, vnetd et bprd doivent fournir des détails sur la nature de toute défaillance restante.