The specified network name is no longer available

KB ID:
1735
Produit:
Veeam Backup & Replication
Version:
5.x, 6.x, 7.x, 8.x, 9.x
Publié:
Dernière modification:
2019-09-06
KB langues:
EN | ES | IT

Description

Lorsque vous accédez à des fichiers de sauvegarde sur un repository CIFS (SMB), Veeam Backup and Replication signale l'une des erreurs suivantes :

The specified network name is no longer available. (code 59, 0x8007003B)
An unexpected network error occurred. (code 64, 0x80070040)

Veeam Backup & Replication utilise des connexions SMB pour les repository de sauvegarde, le traitement des invités et l'ajout d'un serveur Windows dans l'infrastructure de sauvegarde. Cette base de connaissances ne traite que les messages d'erreur qui se produisent dans le contexte d'un chemin de fichier de sauvegarde, tels que :

The specified network name is no longer available. Failed to read data from the file [\\10.0.0.81\backups\SQL VM New\SQL VM New2015-09-23T200441.vbk].
 

Remarque : Si l'échec se produit dans un job de sauvegarde sur bande et qu'aucun chemin UNC n'est spécifié dans le message d'erreur, veuillez contacter le support Veeam.
 

Cause

Ces messages d'erreur sont transmis directement depuis Microsoft Windows et indiquent qu'un problème inconnu a entraîné une défaillance soudaine de la connexion entre la passerelle du repository (agissant en tant que client de blocage des messages du serveur) et le serveur SMB (généralement un appareil NAS).

User-added image

Il y a de nombreuses raisons possibles pour lesquelles la connexion SMB peut échouer :

  • Les problèmes de réseau sont une raison courante, constituant une variété potentiellement illimitée de pannes matérielles ou de problèmes de configuration matérielle du réseau ; ces problèmes peuvent impliquer ou non une perte de paquets.
  • De simples pare-feu peuvent bloquer une connexion de manière cohérente, tandis que des pares-feux avancés peuvent détruire une connexion existante dans des circonstances qui peuvent sembler aléatoire ou dans des conditions très spécifiques.
  • Le client ou le serveur peut fermer la connexion en raison d'un délai d'attente ou d'une limite de réessai au niveau de la couche protocole SMB ou de la couche TCP sous-jacente ; ces limites sont souvent rencontrées en raison de la congestion du réseau ou d'une charge excessive sur le stockage.
  • Le NAS peut cesser de répondre entièrement en raison de problèmes matériels ou logiciels ; dans certains cas, il peut être mal configuré. Les appliances utilisant la déduplication post-processus peuvent cesser de répondre si le processus démarre prématurément.

Solution

Solutions de contournement les plus courantes

  • Si le partage du repository est situé sur un serveur Windows, essayez de créer un repository Windows sur ce serveur au lieu d'un repository CIFS (SMB).
  • Redémarrez l'ordinateur client SMB (passerelle de repository) et le serveur SMB (NAS).
  • Si un autre stockage est disponible, essayez d'écrire la sauvegarde sur l'autre stockage à la fois comme vérification du problème et comme solution de contournement temporaire.
  • Envisagez de reconfigurer le NAS en iSCSI ou en montage NFS sur un serveur repository Linux séparé, en fonction de ce qui est pris en charge par le NAS. Ce changement peut entraîner une perte de données. iSCSI offre généralement les meilleures performances.
  • Il n'est pas recommandé d'écrire des fichiers de sauvegarde dans des partages SMB sur un réseau lent ou peu fiable, comme une connexion WAN. Déployez un serveur passerelle avec une connexion rapide au partage.
  • Pour exclure toute interférence d'un pare-feu, désactivez temporairement tout pare-feu logiciel (y compris certains produits antivirus) sur le client ou le serveur SMB, ainsi que tout pare-feu matériel entre eux.

Paramètres du registre

Ces valeurs de registre doivent être créées sur la passerelle SMB, qui est spécifiée dans les paramètres du repository comme “Gateway server”. Si la passerelle est réglée sur “automatique”, ajoutez ces valeurs de registre à tous les serveurs Windows gérés par Veeam Backup & Replication..

  • NetUseShareAccess
    Pour Veeam B&R 8.0.0.0.917 ou version ultérieure, la valeur de registre suivante permet au Data Movers d'ouvrir les fichiers de sauvegarde par une méthode résiliente similaire à la commande Windows net use​​​.
     

    Key: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
    DWORD: NetUseShareAccess
    Value: 1
     

    Remarque: Si des informations d'identification sont requises, spécifiez Domain\User ou Host\User dans les paramètres du repository. Les identifiants utilisateur .\User ne sont pas pris en charge par NetUseShareAccess. Par exemple, spécifiez “NAS-01\Admin” au lieu de “.\Admin”.
  • SessTimeout
    This increases the amount of time the Windows SMB client will wait for a response from an SMB server before it aborts the connection. The default timeout is one minute.
    Note: Reboot Required
     

    Key: HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\
    DWORD: SessTimeout
    Value: 600
     

    Note: This is a value in seconds. Try a value of 600 decimal (10 minutes).
     
  • TcpMaxDataRetransmissions
    This increases the number of times the Windows TCP implementation will retransmit a data segment before it aborts the connection.
    Note: Reboot Required
     

    Key: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
    DWORD: TcpMaxDataRetransmissions
    Value: 10 (Default: 5)

Additional Troubleshooting

  • Open the repository settings and enable Limit combined data rate. If you can measure the existing data rate, start with a limit between 50% and 70% of that value to verify that reducing throughput prevents the error. If the network is still congested after limiting the repository data rate, and the source of the congestion is due to other Veeam processes, enable throttling for the relevant connections. 
  • Change the gateway server in the repository settings to test whether particular routes to the share perform better than others. For example, if connections from any Windows server on an ESXi host tend to fail, but connections from a physical Windows machine do not fail, the root cause probably involves that ESXi host or its network connection. 
  • If the SMB connection consistently fails after 10 hours, it may be due to expiration of a Kerberos service ticket. The most reliable workaround is to create non-domain credentials on the NAS, then specify those credentials in the repository settings. For more information and other possible workarounds, see this SAMBA mailing list discussion and the Authentication Expiration Timer heading in this MSDN blog post.

Évaluez la qualité de cet article: 
4 out of 5 based on 118 ratings

Vous n'avez pas trouvé ce que vous cherchiez ?

Ci-dessous, vous pouvez envoyer une idée pour un nouvel article de base de connaissances.

Pour signaler une erreur sur cette page:

Mettez en relief la faute d'orthographe avec la souris et appuyez Ctrl+Entrée pour nous la signaler.

Spelling error in text:

Envoyer