Search <book_title>...

Guide de l'administrateur NetBackup™ for VMware

Last Published: 2023-01-17

Product(s): NetBackup (10.1.1)

Remarques et restrictions de restauration

Avant de commencer la restauration, notez ce qui suit :

La restauration multiplateforme de différents fichiers n'est pas prise en charge. Vous pouvez restaurer des fichiers Windows dans des systèmes d'exploitation invités Windows, mais pas Linux. Vous pouvez restaurer des fichiers Linux vers les systèmes d'exploitation Linux d'invité, mais pas vers Windows. En d'autres termes, l'hôte de restauration doit être la même plate-forme que les fichiers que vous souhaitez restaurer.
Se reporter à A propos de la restauration de fichiers spécifiques .
À moins qu'un client NetBackup ne soit installé sur la machine virtuelle, vous devez effectuer la restauration à partir du serveur principal NetBackup.
Pour restaurer des fichiers à l'emplacement d'origine de la machine virtuelle, l'emplacement doit être spécifié en tant que nom d'hôte de machine virtuelle (et non pas en tant que nom d'affichage ou UUID).
Pour restaurer directement sur un serveur ESX, le nom qui est spécifié pour la restauration doit correspondre au nom d'hôte officiel du serveur ESX. Le nom doit être au même format que celui auquel il est enregistré dans le DNS et dans le serveur VMware (nom de domaine court ou complet).
Se reporter à Ajout d'informations d'authentification NetBackup pour VMware.
Si le nom affiché de la machine virtuelle a été modifié après la sauvegarde de la machine virtuelle, la vérification de pré-récupération peut échouer lorsque vous cliquez sur Démarrer la récupération :
```
VM exists overwrite -Failed. Vmxdir for VM exists
```
Vous pouvez ignorer l'erreur et cliquer sur Démarrer la récupération, mais notez : la restauration peut réussir, mais le dossier qui contient le fichier vmx pour la machine virtuelle nouvellement restaurée a un nom différent du dossier vmx de la machine virtuelle existante. VMware ne renomme pas ce dossier lorsque la machine virtuelle est renommée mais continue à utiliser le dossier existant.
Vous pouvez également restaurer la machine virtuelle à un emplacement différent.
Un modèle de machine virtuelle ne peut pas être restauré vers un serveur ESX autonome. Puisque les modèles sont une fonctionnalité des serveurs vCenter, vous devez restaurer le modèle via vCenter. Si vous restaurez un modèle vers un serveur ESX autonome, le modèle est converti en une machine virtuelle normale et n'est plus un modèle.
NetBackup prend en charge la sauvegarde et la récupération des fichiers NVRAM VMware et des périphériques vTPM associés aux machines virtuelles.
- Un hôte de sauvegarde ou de récupération NetBackup 8.3 ou une version ultérieure est requis pour la protection NVRAM et vTPM. Les méthodes de récupération prises en charge incluent la récupération complète de machines virtuelles et la récupération instantanée VMware.
- NetBackup ne prend pas en charge la sauvegarde ou la restauration de NVRAM et de vTPM pour les machines virtuelles dont les noms affichés commencent par un point ("."). Une limitation VMware existante empêche le téléchargement ou le chargement des fichiers du stockage de données commençant par un point (".") dans le répertoire de travail d'une machine virtuelle, car ils apparaissent en tant que fichiers masqués.
Si la machine virtuelle a été sauvegardée par son nom affiché ou UUID et que le nom affiché est différent du nom d'hôte, vous devez spécifier l'emplacement client correct pour la restauration. Utilisez la boîte de dialogue Spécifier les ordinateurs NetBackup et le type de politique dans l'interface Sauvegarde, archivage et restauration NetBackup.
Se reporter à Erreur de client non valide lors de la restauration des fichiers sélectionnés avec l'interface de barre NetBackup installée sur la machine virtuelle.
La restauration de fichiers individuels à partir d'une sauvegarde de machine virtuelle complète n'est pas prise en charge si la machine virtuelle contient des volumes Storage Foundation Volume Manager.
Pour restaurer individuellement des fichiers Windows chiffrés NTFS, installez un client NetBackup sur la machine virtuelle.
Se reporter à Meilleures pratiques pour NetBackup for VMware.
Si la tentative de restauration complète d'une machine virtuelle échoue avec le transport de type SAN, essayez le transport de type NBD.
La restauration d'une machine virtuelle avec un mode de transport NBD ou NBDSSL peut être ralentie dans les cas suivants :
- La machine virtuelle avait de nombreuses petites zones de stockage de données en raison d'une fragmentation lourde. (Une zone de stockage de système de fichiers est une zone de stockage contiguë définie par le décalage et la taille de bloc.)
- La restauration est issue d'une sauvegarde incrémentielle de bloc et les blocs changés sur le disque ont été lourdement fragmentés lorsque la sauvegarde incrémentielle de bloc s'est produite.
Pour accélérer la restauration dans ces cas, utilisez le mode de transport hotadd au lieu de NBD ou NBDSSL.
VMware ne prend pas en charge la restauration des machines virtuelles directement sur un serveur ESX 5.x géré par vCenter. Pour restaurer la machine virtuelle, sélectionnez le serveur vCenter comme destination.
Comme alternative, vous pouvez installer un serveur ESX indépendant à utiliser pour les restaurations. Vous devez ajouter des informations d'authentification de restauration NetBackup pour ce serveur ESX, à l'aide du type de serveur VMware ESX Server.
Se reporter à Ajout d'informations d'authentification NetBackup pour VMware.
Pour le mode de transport SAN, le travail peut être lent en cas de restauration sur un serveur vCenter. Pour une plus grande vitesse, indiquez un serveur VMware ESX comme emplacement pour la restauration.
Se reporter à Ajout d'informations d'authentification NetBackup pour VMware.
Pour le mode de transport SAN et un hôte de restauration sous Windows, la restauration échoue si le LUN du stockage de données est hors ligne. Le journal Etat détaillé du travail contient des messages semblables à ce qui suit :
```
5/22/2013 4:10:12 AM - Info tar32(pid=5832) done. status: 24: 
socket write failed       
5/22/2013 4:10:12 AM - Error bpbrm(pid=5792) client restore EXIT 
STATUS 24: socket write failed     
```
- Assurez-vous que l'état du disque SAN sur l'hôte de restauration est en ligne (et non hors ligne). L'état du disque peut être vérifié ou modifié à l'aide de l'utilitaire Windows diskpart.exe ou de l'utilitaire de gestion de disque (diskmgmt.msc). Lorsque le disque affiche un statut en ligne, relancez la restauration.
- Si le multipathing est activé, assurez-vous que tous les chemins d'accès sont en ligne.
La restauration au moyen du mode de transport SAN peut être lente pour d'autres raisons. L'article suivant de Veritas fournit des détails :
VMware Transport Modes: Best practices and troubleshooting
En raison d'une limitation dans les API du kit de développement de disque virtuel de VMware (Virtual Disk Development Kit, VDDK), la vitesse d'écriture maximale pendant la restauration de machine virtuelle correspond approximativement au tiers de la vitesse maximale du matériel.
Si une machine virtuelle contient des fichiers vmdk dans différents répertoires du même stockage de données, lorsque la machine virtuelle est restaurée vers l'emplacement d'origine, ses fichiers vmdk sont restaurés vers un répertoire unique et non pas vers les répertoires d'origine. (Ce comportement suit la conception VMware en cours.)
Comme solution de contournement, procédez comme suit : supprimez les fichiers vmdk de la machine virtuelle restaurée, déplacez les fichiers vers leurs répertoires respectifs, puis rattachez les fichiers déplacés à la machine virtuelle.
Si la machine virtuelle d'origine contient des fichiers VMDK chiffrés, après avoir restauré la totalité de la machine virtuelle VMware à l'emplacement d'origine ou après une restauration de disque sur place, les disques restaurés peuvent ne pas être conformes à la politique de chiffrement de la machine virtuelle. Par conséquent, la machine virtuelle restaurée doit être reconfigurée manuellement pour se conformer à la politique. Sinon, les disques virtuels de la machine virtuelle restaurée risquent de ne pas être chiffrés.
Lorsque vous restaurez des fichiers volumineux, assurez-vous qu'aucun snapshot n'est activé sur la machine virtuelle de destination. Sinon, les fichiers sont restaurés sur le datastore de configuration VMware, qui peut être ne pas avoir la capacité nécessaire pour contenir les fichiers à restaurer. Auquel cas, la restauration échoue.
Le stockage de données de configuration (parfois appelé répertoire VMX) contient les fichiers de configuration qui décrivent la machine virtuelle, tels que les fichiers *.vmx. Notez que des snapshots actifs de fichiers vmdk sont également enregistrés sur le datastore de configuration.
Si vous annulez la restauration de machine virtuelle avant qu'elle ne se termine, la machine virtuelle qui n'a pas été totalement restaurée reste sur l'emplacement cible. NetBackup ne supprime pas la machine virtuelle incomplète en cas d'annulation de la restauration. Vous devez supprimer manuellement la machine virtuelle incomplète.
Si le nom affiché de la machine virtuelle contient des caractères non pris en charge, la sauvegarde peut réussir mais la restauration échoue. Pour restaurer la machine virtuelle, vous devez modifier le nom affiché afin qu'il contienne uniquement des caractères pris en charge, puis relancer la restauration.
Se reporter à Restrictions de caractère de NetBackup pour l'identifiant de la machine virtuelle principale.
NetBackup for VMware ne prend pas en charge la restauration de fichier individuel via une restauration de client-direct.
Lors d'une restauration, NetBackup recrée la liaison entre un lien physique et son fichier d'origine, uniquement si le fichier de lien et son fichier cible sont restaurés au cours de la même opération. Si les deux fichiers sont restaurés individuellement dans des travaux de restauration distincts, ils sont restaurés en tant que fichiers distincts et le lien n'est pas rétabli.
Si vous restaurez une machine virtuelle dans le vCloud sur un vApp expiré, le vApp est automatiquement renouvelé et rajouté dans l'organisation vCloud. Si le vApp expiré contenait d'autres machines virtuelles, celles-ci sont également supprimées de la liste expirée et ajoutées à l'organisation.
Notez que dans le directeur vCloud, un vApp expiré doit être renouvelé avant de pouvoir y importer une machine virtuelle.
En cas de connexion à distance à partir d'une interface utilisateur graphique Windows-Java qui utilise des paramètres régionaux anglais, la restauration des fichiers contenant des caractères non ASCII peut échouer.
Consultez la note technique suivante pour obtenir plus d'informations sur la restauration des fichiers :
https://www.veritas.com/docs/100022268
Dans VMware vSphere 6.0 U1b et versions ultérieures, la restauration complète d'une machine virtuelle peut déclencher une alarme si la machine virtuelle d'origine n'a pas été supprimée. L'alarme est une alarme de conflit d'adresses MAC de machine virtuelle. Le comportement de cette alarme VMware est voulu. En cas de conflit d'adresses MAC, VMware finit par changer l'adresse MAC de la nouvelle machine virtuelle. Si vous ne souhaitez pas recevoir les alarmes, désactivez les alarmes de conflit d'adresses MAC de machines virtuelles dans vCenter.
Se reporter à NetBackup for VMware : remarques et restrictions.