Arcserve |
Les problèmes suivants peuvent apparaître dans cette version.
Problèmes liés au navigateur
Problèmes liés à la console
Symptôme
Imaginez que vous disposez de deux machines virtuelles, VM1 et VM2, portant le même GUID dans les hôtes ESXi et gérées par des serveurs vCenter différents, VC1 et VC2 respectivement. Vous importez VM1 dans la console (vous ne pouvez pas importer les deux machines virtuelles car la console ne permet pas d'avoir plusieurs nœuds portant le même GUID). Toutefois, vous importez également les machines virtuelles à partir du serveur vCenter VC2. Lorsque la détection automatique s'exécute, elle se connecte d'abord à VC1 et détecte VM1 en fonction de son GUID ; la colonne Hyperviseur est mise à jour avec les informations de VC1. Par la suite, lorsqu'elle se connecte à VC2, elle détecte VM2 en fonction de son GUID et la colonne Hyperviseur est mise à jour avec les informations de VC2.
Solution
C'est très rare que deux machines virtuelles portent le même GUID. Dans le pire des cas, si cela arrive, la sauvegarde sans agent basée sur un hôte risque de sauvegarder la mauvaise machine virtuelle car Arcserve UDP utilise le GUID pour identifier une machine virtuelle. Pour résoudre ce problème, vous pouvez modifier manuellement le GUID de l'une des deux machines virtuelles. Pour plus d'informations sur cette procédure, reportez-vous à la rubrique associée dans le Manuel des solutions.
Symptôme
Vous ne parvenez pas à vous connecter à la console Arcserve UDP. Celle-ci affiche le message suivant même après cinq minutes de connexion :
Identity Service is starting
Solution
Pour résoudre ce problème, ouvrez la console des services Windows et redémarrez le service de la console Arcserve UDP, service de gestion d'Arcserve UDP.
Problèmes liés à la console de gestion des utilisateurs Arcserve UDP
Problèmes liés à la vue Point de récupération Arcserve UDP
Symptôme
Si le volume est encore monté, la vue Point de récupération Arcserve UDP ouvre directement le volume monté par le système d'exploitation, pas la session de sauvegarde.
Si le volume est démonté, rien ne s'affiche dans la vue Point de récupération Arcserve UDP sous le chemin d'accès à ce fichier.
Solution
Utilisez l'option Monter le point de récupération pour monter ce type de volume.
Problèmes liés à Agent Arcserve UDP (Linux)
Problèmes liés à la sauvegarde
Symptôme
Le filtre supérieur BLI de Registre de classe de volume étant supprimé, le pilote BLI ne peut pas surveiller les volumes.
Solution
Vous pouvez continuer à effectuer une sauvegarde incrémentielle après avoir réinstallé le pilote de suivi des modifications.
Procédez comme suit :
<chemin_installation>\Arcserve\Unified Data Protection\Engine\BIN\DRIVER
<chemin_installation>\Arcserve\Unified Data Protection\Engine\BIN\DRIVER
Symptôme
Les messages suivants peuvent s'afficher dans le journal d'événements : "Tentative d'opération non autorisée sur une clé du Registre marquée pour suppression", ou "Windows a détecté que votre fichier de Registre est toujours utilisé par d'autres applications ou services". Le fichier va être déchargé. Les applications ou services qui ont accès à votre Registre risquent de ne pas fonctionner correctement après cela.
Solution
Pour plus d'informations sur la cause et la solution, reportez-vous à l'article de connaissances de Microsoft 2287297.
Symptôme
Le montage d'une session sur un lecteur échoue.
Un tel échec du montage a lieu lorsque la destination est un dossier local et un volume FAT32. En effet, le montage d'un pilote prend uniquement en charge la création du fichier cache sur le volume NTFS.
Solution
Ajoutez une nouvelle clé de registre et définissez le chemin d'accès au fichier cache sur un autre volume.
Suivez ces étapes:
Informations complémentaires :
Le fichier cache est créé par le biais du montage d'un pilote au moment du montage d'un volume accessible en écriture. Pour le job de restauration/catalogue de restauration détaillée, un volume accessible en écriture est créé. Les sessions de sauvegarde de volumes requièrent le montage d'un volume accessible en écriture au moment du montage d'une session vers un pilote lorsqu'elles ont lieu sur un système d'exploitation Windows 8, Windows 2012, ou ultérieur.
Symptôme
La sauvegarde soumise s'affiche correctement, mais aucun moniteur de jobs n'apparaît dans l'interface utilisateur de l'Agent Arcserve UDP (Windows). Ce problème s'explique par le fait que le job de sauvegarde remplit le paramètre de nombre maximum de noeuds simultanés dans le référentiel de données et est donc mis en attente.
Solution
Ouvrez la console Arcserve UDP. Le moniteur de jobs en attente apparaît dans la vue des nœuds.
Symptôme
Lorsqu'un job de sauvegarde par vérification sans agent et utilisant un hôte est en cours d'exécution et si la compression a été activée dans le plan, le pourcentage de compression affiché dans le moniteur de jobs est plus élevé que le pourcentage réel.
Tous les autres jobs de sauvegarde n'ont pas ce problème, notamment les jobs de l'agent de sauvegarde et des jobs de sauvegarde complète/incrémentielle sans agent et utilisant un hôte.
Solution
Le pourcentage de compression enregistré dans le journal d'activité est correct. Consultez-le une fois que le job de sauvegarde par vérification sans agent et utilisant un hôte est terminé.
Problèmes liés à la récupération à chaud
Echec de l'intégration du package linguistique à l'image ISO de récupération à chaud
Symptôme
Ce problème est dû au pilote de filtre du logiciel antivirus tiers McAfee, mais il peut également survenir avec d'autres filtres tiers.
Solution
Désactivez votre logiciel antivirus et réessayez de créer le kit de démarrage.
Symptôme
Lorsque l'ordinateur source est un serveur Active Directory effectuant une récupération à chaud sur un ordinateur physique équipé d'un autre appareil ou sur une machine virtuelle installée sur un serveur Hyper-V, le serveur ne démarre pas et une fenêtre bleue s'affiche avec le message suivant :
STOP: c00002e2 Les services d'annuaire n'ont pas pu démarrer en raison de l'erreur suivante : un périphérique attaché au système ne fonctionne pas correctement. Statut d'erreur : 0xc0000001.
Solution
Redémarrez le système sur l'environnement PE de récupération à chaud, renommez tous les fichiers *.log dans le dossier C:\Windows\NTDS et redémarrez le système. Par exemple, remplacez le nom du fichier edb.log par edb.log.old et redémarrez le système.
Symptôme
Le mappage du disque ou du volume pendant la récupération à chaud peut être impossible à réaliser lorsque l'ordinateur cible est une machine virtuelle équipée d'un disque IDE sur un serveur Hyper-V 2008 ou 2008 R2.
Si vous restaurez des données sur une machine virtuelle dotée d'un disque IDE sur un serveur Hyper-V 2008 ou 2008 R2 à l'aide de la fonctionnalité de récupération à chaud, le mappage du disque ou du volume source vers le disque ou le volume cible est impossible, même si la taille des deux disques affichée est identique. Ce problème s'explique par le fait que la taille de disque réelle est inférieure à la taille spécifiée, lors de la création d'un disque IDE sur un serveur Hyper-V 2008 ou 2008 R2.
Solution
Créez un disque plus grand sur la machine virtuelle. Par exemple, si vous voulez restaurer des données à partir d'un disque de 25 Go, il est recommandé de créer un disque de 26 Go sur la machine virtuelle cible.
Symptôme
Ce problème a été observé sur les serveurs VMware ESX. Pour des machines virtuelles Windows 2003, le contrôleur de disque par défaut est l'adaptateur SCSI de logique de LSI et le pilote pour ce type d'adaptateur SCSI n'est pas inclus dans Windows ADK 8.1. Vous pouvez également observer cela sur certains anciens serveurs contenant d'anciens adaptateurs SCSI.
Solution
Pour résoudre ce problème, obtenez les pilotes à partir du site Web du fournisseur de matériel et chargez-les à partir de l'interface utilisateur de récupération à chaud.
Problèmes liés au cliché matériel
[VDDKLOG] SSLCheckLockingCallback : rappel de verrouillage remplacé 7FEE3A836E0 attendu, 113C2420 reçu
Pour résoudre ce problème, définissez la clé de Registre VDDKLogLevel sur 0 à l'emplacement suivant :
\HKEY_LOCAL_MACHINE\Software\Arcserve\Unified Data Protection\Engine\
Impossible de créer la copie de cliché {xxx}_backup sur plusieurs volumes du système de stockage xxx après 100 tentatives selon un intervalle de 10 secondes.
Pour créer la clé de Registre, procédez comme suit :
HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine
DoNotUseFlexCloneLicenseToCloneLun
Problèmes liés à la sauvegarde d'une machine virtuelle basée sur un hôte
Symptôme
VMware a récemment publié un article de connaissances qui indique que, sous ESXi 6.0 ou ESXi 6.0.x, un bogue a été introduit au niveau de la fonction de suivi des blocs modifiés (CBT), de sorte que cette dernière renvoie une liste incorrecte des secteurs modifiés. Il se peut que Arcserve UDP soit concerné par ce problème, qui entraîne une incohérence des sauvegardes de machines virtuelles (complètes et incrémentielles). Pour plus d'informations, consultez la base de connaissances VMware.
Si le problème se produit, le job de catalogage peut échouer et la vérification du point de récupération peut signaler des erreurs.
Solution
VMware a publié un patch pour ce problème. Appliquez ce patch sur les hôtes ESXi. Pour plus d'informations, consultez l'article de connaissances de VMware ou l'article de connaissances de Microsoft.
Symptôme
Ce problème survient si l'hôte Hyper-V est Windows Server 2012 R2 et que le système d'exploitation invité de la machine virtuelle est SUSE Linux Enterprise Server (SLES) 12 avec un niveau d'exécution 5 (avec l'interface graphique). Dans ce cas, le job de sauvegarde sans agent se bloque au niveau de la prise d'instantané et finit par échouer. Ensuite, le système d'exploitation invité de la machine virtuelle ne répond plus.
Solution
Il ne s'agit pas d'une défectuosité de Arcserve UDP, mais d'un problème de compatibilité entre Windows et SUSE. Le même problème se produit lors de la création d'un cliché instantané de volume à l'aide de la commande diskshadow sur l'hôte Hyper-V. Pour vérifier le problème, procédez comme suit :
Il n'existe aucune solution pour l'instant. Nous vous suggérons de travailler avec Microsoft pour résoudre la cause première. Vous pouvez également essayer de modifier le niveau d'exécution de SLES 12 de 5 à 3 (sans interface graphique), mais cela ne garantit pas la résolution du problème.
Symptôme
Pour une machine virtuelle VMware, la vérification préalable (PFC) renvoie le message d'avertissement suivant pour la vérification de la cohérence des données, même lorsque vous avez déjà entré des informations d'identification correctes.
Aucune vérification n'a été effectuée, car l'application n'a pas pu accéder à la machine virtuelle. Vérifiez que les informations d'identification utilisateur sont correctes et qu'elles sont associées à des droits d'administration.
Solution
Ce problème de vérification préalable concerne uniquement les machines virtuelles VMware. Les autres fonctionnalités telles que la sauvegarde ne sont pas affectées. La solution consiste à installer l'agent Arcserve UDP sur la machine qui héberge la console Arcserve UDP (le service d'agent ne doit pas être démarré).
Symptôme
Même lorsqu'un transport en mode SAN est possible, les jobs de sauvegarde et de restauration utilisent toujours le mode de transport Ajout à chaud, NBD ou NBDSSL.
Solution
Il s'agit d'un problème connu de VMware VDDK 6.0.1. VMware ne propose toutefois aucune solution pour le moment. Pour plus d'informations, référez-vous à la section Known Issues du document VDDK 6.0.1 Release Notes.
Symptôme
Même lorsqu'un transport en mode SAN est possible, les jobs de sauvegarde et de restauration utilisent toujours le mode de transport Ajout à chaud, NBD ou NBDSSL lorsque la taille provisionnée du disque virtuel de la machine virtuelle est de 4 To ou un multiple de 4 To.
Solution
Il s'agit problème connu de VMware qui, selon le fabricant, concerne les patchs suivants :
• Pour ESXi 5.5 - Patch version ESXi550-201504001 (2112672)
• Pour ESXi 6.0 - Patch version ESXi600-201505001 (2116125)
La solution consiste à éviter d'utiliser une taille provisionnée qui est un multiple de 4 To. Par exemple, n'utilisez pas 4 ou 8 To ; optez plutôt pour 3,9 ou 8,1 To.
Symptôme
Lorsque vous suspendez une machine virtuelle VMware à l'aide de VMware Tools, le cliché contient des données endommagées. La sauvegarde lisant les données à partir du cliché, les données sauvegardées sont également endommagées. Pour plus d'informations concernant ce problème, consultez l'article de connaissances VMware suivant :
Remarque : Ce problème se produit avec toutes les versions de VMware ESXi et sur les machines virtuelles dotées d'un système d'exploitation invité Windows 2008 R2 SP1 ou Windows 2012. Arcserve UDPne détecte pas le problème d'endommagement des données, car VMware ne retourne aucune erreur dans ce cas. Il se peut dès lors que vous ne vous rendiez compte du problème que lorsque vous tentez de restaurer les données.
Solution
Exécutez les tâches suivantes pour détecter et résoudre le problème :
Symptôme
Lors de la sauvegarde d'une machine virtuelle à l'aide de la méthode de suspension des clichés Microsoft VSS sur la machine virtuelle, la sauvegarde risque d'être incohérente, surtout en cas de sauvegarde d'une machine virtuelle sur laquelle des applications (telles qu'Exchange) sont installées.
Solution
La solution consiste à utiliser la méthode de suspension des clichés VMware Tools et à désactiver les enregistreurs VSS MSSearch Service Writer et Shadow Copy Optimization Writer dans le système d'exploitation invité de la machine virtuelle.
Impossible de connecter l'adaptateur réseau <<nom de l'adaptateur>> au commutateur virtuel.
Symptôme
Lorsque vous sauvegardez une machine virtuelle, un basculement intervient pour la machine virtuelle mise en cluster avant la prise d'un cliché. Cela entraîne une incohérence entre l'hôte Hyper-V enregistré dans la session de sauvegarde et la configuration de machine virtuelle.
Solution
Vous pouvez relier manuellement l'adaptateur réseau à un commutateur virtuel sur l'hôte Hyper-V ou utiliser l'option de restauration vers un autre emplacement pour récupérer la machine virtuelle avec laquelle vous pouvez définir la configuration de la restauration pour la machine virtuelle.
Symptôme
Bien que le job de sauvegarde d'une machine virtuelle soit déjà fini, le statut de la machine virtuelle reste Sauvegarde dans le gestionnaire Hyper-V. Par conséquent, si un autre job de sauvegarde pour cette machine virtuelle commence à ce moment-là, il échoue avec un message "Une erreur s'est produite au niveau de l'enregistreur VSS Hyper-V pendant le traitement de cette machine virtuelle.". De plus, à ce moment-là, certaines opérations comme allumer/éteindre la machine sont impossibles pour la machine virtuelle au niveau du gestionnaire Hyper-V. Si la machine virtuelle est un cluster Hyper-V, vous ne pouvez pas effectuer de migration en direct pour cette machine.
Ce problème survient dans les situations suivantes :
Solution
Lorsque la machine virtuelle est verrouillée, vous pouvez malgré tout utiliser le système d'exploitation invité. Par conséquent, ce problème n'a aucun impact sur l'utilisation ni sur la disponibilité du système d'exploitation d'invité. Toutefois, si vous avez des questions et que vous souhaitez éviter cette situation, vous pouvez procéder de l'une des façons suivantes :
Symptôme
Il s'agit d'un problème connu de VMware affectant le suivi des blocs modifiés. Avec la suspension au niveau application, le suivi des blocs modifiés amplifie les modifications.
Solution
Le problème est résolu dans VMware ESXi 5.5 ou version ultérieure et VMware ESX 5.1 Patch 02. Si VMware vCenter Server 5.5 gère des hôtes VMware ESXi 5.1, le patch doit leur être appliquer. Pour plus d'informations sur cette résolution, consultez la base de connaissances de VMware.
Si le problème persiste, définissez le Registre suivant sur le serveur proxy :
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\<UUID_instance_VM>]
"ResetCBT"=dword:00000001
Exemple :
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\502d3c43-e3c9-9919-78f9-89082ca5e1cc]
"ResetCBT"=dword:00000001
Remarque : Une fois la valeur de registre définie, le job de sauvegarde incrémentielle suivant se convertit en job de sauvegarde par vérification. La taille des autres jobs de sauvegarde incrémentielle sera ensuite correcte.
Pour plus d'informations, consultez l'article de connaissances 2055943 de VMware.
Symptôme
Les fichiers VMDK de la machine virtuelle de la source de sauvegarde occupent plus de 2 To, or les serveurs ESX/ESX(i) d'une version inférieure à la version 5.5 peuvent uniquement prendre en charge un disque virtuel de 2 To maximum. Toutefois, pendant la récupération de la machine virtuelle, les erreurs suivantes peuvent se produire :
Solution
Il s'agit d'une restriction de VMware. La taille maximum que les serveurs VMware ESX/ESX(i) d'une version inférieure à la version 5.5 prennent en charge est de 2 To-16 Go, soit 2032 Go.
Nous vous recommandons d'utiliser un serveur VMware ESX(i) 5.5 comme destination lorsque vous effectuez une conversion avec un disque de grande taille.
Pour plus d'informations, consultez l'article de connaissances 1012384 de VMware.
Symptôme
Le job de sauvegarde échoue lorsque vous l'exécutez sur une machine virtuelle dotée d'un contrôleur SCSI avec plus de 7 disques VMDK. Cela est dû au fait que VMware requiert la présence d'un nombre maximum de logements libres pour que les disques VMDK d'un contrôleur SCSI puissent créer un cliché. Le nombre maximum de logements pour un contrôleur SCSI est 15. Par exemple, si un contrôleur SCSI possède 7 disques VMDK, vous pouvez créer un cliché pour chacun d'entre eux (14 logements sont utilisés au total et l'un d'entre eux est libre). En revanche, le job de sauvegarde échoue pour les contrôleurs SCSI équipés de 8 disques VMDK, car la création du cliché est impossible étant donné que seuls 15 logements sont disponibles.
Remarque : La création manuelle d'un cliché échoue également.
Solution
Pour les machines virtuelles dotées de plus de sept disques sur un contrôleur SCSI unique, procédez comme suit :
Vous pouvez désormais créer des clichés pour chaque disque VMDK.
Ce problème est lié à une restriction VMware qui limite la prise en charge par Arcserve Backup au nombre de disques VMDK pour les sauvegardes.
Pour plus d'informations, consultez l'article de la base de connaissances VMware suivant : http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2015181
Pour résoudre ce problème, supprimez l'ancienne machine virtuelle au niveau de CA ARCserve Central Protection Manager et importez la nouvelle machine virtuelle.
Symptôme
Il s'agit d'un problème connu sous VMware, qui affecte les hôtes ESXi 5.0, 5.1 et 5.5 et les machines virtuelles utilisant des adaptateurs réseau virtuels E1000 et E1000e.
Remarque : Ce problème est résolu dans les mises à jour VMware suivantes.
Solution
Optez pour un adaptateur VMXNET3. Pour plus d'informations, consultez l'article de connaissances 2059053 de VMware.
Symptôme
Lorsqu'une machine virtuelle est importée dans la vue des nœuds, l'opération échoue si une autre machine virtuelle possédant le même UUID d'instance a déjà été ajoutée à la vue.
Symptôme
Lorsqu'un plan de sauvegarde de machine virtuelle utilisant un hôte inclut un ordinateur proxy doté d'une version précédente de Arcserve D2D (par exemple, la version r16.5), le message d'erreur "Cannot find dispatch method" (Méthode de distribution introuvable) s'affiche à l'enregistrement du plan.
Solution
Ce problème s'explique par le fait que l'API de la version actuelle de Arcserve D2D n'est pas compatible avec l'API de la version précédente. Pour contourner ce problème, vous pouvez mettre manuellement à niveau le Arcserve D2D vers la version actuelle de l'Agent Arcserve UDP (Windows).
Symptôme
Le job de sauvegarde se bloque pendant des heures et ne peut pas se poursuivre.
Solution
Arrêtez le processus afbackend.exe en fonction de son ID dans le journal d'activité, supprimez le cliché de machine virtuelle le cas échéant, puis resoumettez le job de sauvegarde.
Symptôme
Le comportement du système d'exploitation crée l'état Hors ligne par défaut.
La stratégie SAN a été introduite dans Windows Server 2008 pour protéger les disques partagés par plusieurs serveurs. La stratégie de SAN par défaut à partir de la machine virtuelle source est Mettre hors connexion les disques partagés pour tous les disques SAN, sauf le disque de démarrage. La définition de la stratégie sur Hors ligne permet aux disques SAN d'être hors ligne pendant le démarrage. Après la récupération, un nouveau disque est créé pour la machine virtuelle. Le fichier de disque de la machine virtuelle est un disque SAN identifié par le système d'exploitation comme étant hors ligne. Une fois le disque de nouveau en ligne, il le reste même après le redémarrage du système.
Solution
Pour contourner le problème, spécifiez la commande DISKPART.exe : SAN POLICY=OnlineAll setting for the source VM before backup. Etant donné que les disques peuvent être partagés par d'autres serveurs, un endommagement des données peut se produire. Il est important que vous utilisiez la stratégie SAN correcte pour protéger les données.
Ligne de commande DISKPART.EXE
Interrogation de la stratégie SAN :
DISKPART > san
Stratégie SAN : Mode hors ligne partagé
Modification de la stratégie SAN :
DISKPART > san policy=OnlineAll
DISKPART modifie la stratégie SAN pour le système d'exploitation actuel.
Symptôme
Les volumes présents sur les unités iSCSI ne sont pas répertoriés dans l'interface utilisateur de restauration après la sauvegarde d'une machine virtuelle Hyper-V.
Solution
Créez un plan de sauvegarde basé sur un agent dans Arcserve UDP ou utilisez Agent Arcserve UDP (Windows) pour sauvegarder la machine virtuelle.
Symptôme
Si vous avez des jobs de sauvegarde sans agent et utilisant un hôte sur une machine virtuelle Hyper-V, les commandes de pré/post-sauvegarde ne peuvent pas être exécutées si le système d'exploitation invité est Windows Server 2003. Le journal d'activité enregistre l'avertissement Le nom de la machine virtuelle n'est pas celui attendu. Les commandes de pré/post-sauvegarde ne pourront pas être exécutées.
Solution
Ce problème ne concerne pas les systèmes d'exploitation Windows Server 2008, Windows Vista et ultérieurs ; il est donc recommandé de les utiliser.
Problèmes liés au déploiement à distance et à l'installation (agent)
Symptôme
L'API d'installation de Windows renvoie l'erreur 1460, qui indique que le délai a expiré. La valeur du délai d'expiration par défaut est de 300 secondes pour la mise à jour du pilote d'unité.
Solution
Pour ajuster le délai d'expiration, procédez comme suit :
Configuration ordinateur\Modèles d'administration\Système\Installation de périphériques
Configurer le délai d’attente d’installation de périphérique
Machine virtuelle instantanée associée
Symptôme
Lorsque vous utilisez les informations ESX pour vous connecter à un pool de ressources et le sélectionner comme emplacement de la machine virtuelle instantanée, cette dernière se trouve sous le système hôte ESX et non dans le pool de ressources. Si vous supprimez la machine virtuelle instantanée de la console et que vous en recréez une autre portant le même nom, un suffixe (1) sera ajouté au nom de la machine virtuelle instantanée, mais pas à l'horodatage.
Solution
Cela est dû au fait que le serveur ESX est géré par un système vCenter. Utilisez les informations de connexion vCenter pour créer la machine virtuelle instantanée.
Symptôme
Lorsque je lance la machine virtuelle instantanée, puis redémarre le serveur de récupération Hyper-V, il arrive que la machine virtuelle instantanée ne démarre pas.
Solution
Pour résoudre ce problème de démarrage, redémarrez la machine virtuelle instantanée.
Symptôme
J'ai affecté un volume Windows comme dossier partagé NFS et fourni ce chemin d'accès de volume partagé en tant que chemin du fichier de machine virtuelle instantanée. Lorsque je formate le volume Windows, puis que j'essaie de créer la machine virtuelle instantanée, la création échoue. La création de la machine virtuelle instantanée échoue car l'hôte ESXi ne parvient pas à ajouter le référentiel de données NFS. VMware affiche un message d'erreur similaire au suivant :
VMware n'a pas pu créer la machine virtuelle.
Un journal d'erreur semblable au suivant s'affiche dans le fichier vmkernal.log :
Aucune unité sous-jacente pour majeur, mineur
Solution
Pour corriger ce problème, effectuez les étapes suivantes sur le serveur de récupération :
La boîte de dialogue Outils d'administration s'affiche.
La boîte de dialogue Services s'ouvre.
La machine virtuelle instantanée est créée.
Problèmes liés à la vue de journal
Symptôme
Dans la vue de journal, si une machine virtuelle protégée n'a aucun nom d'hôte, la valeur du nom de noeud est affichée sous la forme VM(nom_noeud). Dans ce cas, d'autres filtres ne peuvent également pas être appliqués.
Solution
Pour pouvoir appliquer les filtres correctement, vous pouvez manuellement remplacer le nom de noeud de la machine virtuelle (nom d'hôte) par le nom d'hôte. Par exemple, remplacez le nom de noeud VM(xxxxx01-AB) par "xxxxx01-AB".
Problèmes liés à Microsoft Exchange
Symptôme
Ce problème survient lorsque le serveur Exchange est installé sur une machine virtuelle et qu'il exécute l'Agent Arcserve UDP (Windows) dans le cadre de la protection de cette machine virtuelle. Au cours de la sauvegarde, si vous restaurez la machine virtuelle sur un cliché préalablement enregistré et que vous essayez de récupérer la base de données Exchange à son emplacement d'origine, la restauration échoue avec un message d'erreur indiquant que la base de données ou le groupe de stockage Exchange [nom_BdD] a été restauré(e) à son emplacement original, mais n'a pas pu être monté(e).
La cause première fait toujours l'objet d'une étude, mais elle semble être liée à l'horodatage enregistré dans la base de données Exchange et dans les tout derniers fichiers journaux de transaction.
Solution
Lancez la récupération de la base de données Exchange dans un autre répertoire, ou démontez la base de données, puis supprimez tous les fichiers dans le dossier de destination et lancez la restauration.
Problèmes liés à Microsoft SQL Server
Symptôme
Microsoft SQL Server doit parfois allouer davantage de mémoire pour le traitement d'une requête, en particulier lorsque la base de données Arcserve UDP inclut une grande quantité de données. Toutefois, s'il ne peut pas acquérir davantage de mémoire en raison de la non-disponibilité de mémoire supplémentaire ou parce que la taille maximum de mémoire définie a été atteinte, le traitement de la requête devient très lent, ce qui ralentit la réactivité de la console Arcserve UDP.
Solution
Supprimez des journaux dans la base de données à l'aide de l'option Journal/Supprimer et redémarrez le Service SQL.
Problèmes liés au serveur de points de récupération ou au référentiel de données
Symptôme
Lorsque vous soumettez un job de fusion manuellement, le job ne s'exécute pas et le message suivant s'affiche dans le journal d'activité :
Impossible d'exécuter le job de fusion pour <nom_nœud>, car un autre job est en cours d'exécution.
Solution
Cette erreur peut être due au fait que d'autres jobs sont en cours d'exécution pour le nœud sur le même serveur de points de récupération, mais dans un référentiel de données différent. Pour résoudre ce problème, attendez que ces jobs se terminent, puis réessayez.
Symptôme
Le job de sauvegarde ou de réplication échoue et un message d'erreur indique que le fichier spécifié est introuvable.
Vérifiez le journal d'événements Windows. McAfee détecte le fichier de référentiel de données (par exemple, P0000000042.data) comme étant un virus de type cheval de Troie Exploit-ScriptNull et le supprime.
Solution
Configurez le paramètre d'antivirus de sorte à définir l'emplacement du référentiel de données du serveur de points de récupération dans la liste d'exclusion.
Remarque : Certains logiciels antivirus requièrent la définition de la liste d'exclusion côté serveur.
Symptôme
Ce problème survient lorsque vous définissez la limitation du réseau sur une valeur de bande passante faible ou que le débit réseau vers le serveur de points de récupération de destination est lent. Par conséquent, l'envoi des données placées dans la file d'attente peut prendre plusieurs minutes.
Solution
Patientez jusqu'à la finalisation du job de réplication.
Problèmes liés au serveur de points de récupération, à l'importation à partir d'un serveur Hyper-V ou aux noeuds
Symptôme
Si vous tentez d'ajouter un noeud par adresse IP ou nom de noeud sur des systèmes d'exploitation Windows qui prennent en charge le contrôle de compte d'utilisateur (Windows Vista ou versions ultérieures) ou que vous essayez d'importer des machines virtuelles à partir d'un serveur Hyper-V qui prend en charge le contrôle de compte d'utilisateur et que vous utilisez un nouveau compte d'utilisateur Windows qui est un compte local du groupe d'administrateurs, mais qu'il ne s'agit pas de l'administrateur intégré, le message suivant s'affiche :
Des droits d'administrateur sont requis.
Solution
Utilisez un administrateur intégré ou un administrateur de domaines, ou désactivez la fonctionnalité de contrôle de compte d'utilisateur à distance.
Il s'agit du comportement Windows par défaut connu comme restrictions distantes de contrôle de compte d'utilisateur. Si vous voulez encore utiliser ce compte pour ajouter le noeud, désactivez Remote UAC en procédant comme suit :
L'Editeur du Registre Windows s'affiche.
Remarque : L'ouverture de l'Editeur du Registre Windows peut requérir la saisie d'informations d'identification d'administration.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Pour plus de détails concernant les comportements Windows, reportez-vous à l'article http://support.microsoft.com/kb/951016.
Symptôme
La suppression de la fonction d'hyperviseur pour un noeud n'est pas prise en charge dans cette version.
Solution
Supprimez le noeud et rajoutez-le.
Symptôme
L'interface utilisateur tout en un de Arcserve UDP n'envisage pas l'utilisation de plusieurs consoles Arcserve UDP, c'est pourquoi le déplacement de l'agent d'un serveur à un autre est considéré comme pouvant avoir lieu uniquement lorsque l'ancien serveur est retiré.
Solution
Il est très rare d'avoir à déplacer le noeud d'une console à une autre.
Problèmes liés au registre
Symptôme
McAfee ou un autre logiciel tiers est défini sur EnableECP=1 dans le registre lorsqu'ils sont installés sous Windows Server 2012.
Solution
Dans le registre, remplacez la valeur EnableECP 1 par 0 sous la clé suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanManServer\Parameters
Pour plus d'informations, consultez l'article http://support.microsoft.com/kb/2817216.
Problèmes liés à la réplication
Symptôme
Le deuxième job de réplication se bloque au statut de préparation et renvoie un échec après 10 minutes.
Solution
Aucune action n'est requise, car après l'échec du deuxième job de réplication, le job de rattrapage sera déclenché.
Problèmes relatifs à l'utilitaire Arcserve UDP Exchange Granular Restore (AEGR)
Symptôme
A l'issue d'un job de restauration, les propriétés d'élément suivantes peuvent ne pas être correctement restaurées :
Solution
Utilisez l'option d'exportation au format PST pour restaurer les éléments manquants.
Problèmes relatifs à la restauration
Symptôme
Lorsque vous utilisez la mise à jour 4 ou des versions antérieures de l'agent, les erreurs suivantes se produisent :
La base de données ou le groupe de stockage Exchange a été restauré(e) à son emplacement original, mais n'a pas pu être monté(e).
Solution
Mettez à niveau les agents vers la version 6.0 de l'agent Arcserve UDP.
Symptôme
Lorsque la destination de restauration est un dossier de partage distant comme \\FileServer\ShareFolder\RestDest et que la destination de sauvegarde est un dossier de partage distant avec le même chemin d'accès (\\FileServer\ShareFolder\RestDest), une erreur se produit.
Si le compte d'utilisateur utilisé pour la connexion au dossier de partage racine ne figure pas dans la liste d'autorisation, le job de restauration échouera quel que soit le compte utilisé pour le dossier de destination de la restauration.
Solution
Ajoutez le compte d'utilisateur affecté à la destination de sauvegarde pour créer la connexion dans la liste d'autorisation du dossier de partage racine et veillez à ce que le compte d'utilisateur dispose des autorisations appropriées pour la restauration du fichier.
Ajoutez le compte d'utilisateur dans le groupe Opérateurs de sauvegarde et vérifiez qu'il dispose des autorisations nécessaires pour ignorer des restrictions de sécurité.
Symptôme
Si le chiffrement est activé pour le point de récupération, il n'est pas nécessaire d'entrer le mot de passe pour les points de récupération sauvegardés à partir du serveur actuel. Toutefois, si vous mettez à niveau le système d'exploitation Windows (par exemple, de Windows 2008 à Windows R2 2008), les mots de passe ne sont pas automatiquement saisis dans l'interface utilisateur de l'Agent Arcserve UDP (Windows) et vous devez les ressaisir.
Solution
Enregistrez le mot de passe de chiffrement du point de récupération ou le mot de passe de session et conservez-le en lieu sûr en vue de sa consultation lorsque nécessaire.
Symptôme
Lors de la restauration d'une machine virtuelle VMware, le message d'erreur suivant s'affiche :
Vous n'êtes pas autorisé à accéder à ce fichier. Pour plus d'informations, reportez-vous au journal de débogage de la restauration. Si nécessaire, contactez le support d'Arcserve.
Vous pouvez voir les entrées de journal suivantes dans les journaux de débogage de la restauration :
[VDDKLOG] CnxAuthdConnect: Returning false because SSL verification requested and target authd does not support SSL
[VDDKLOG] CnxConnectAuthd: Returning false because CnxAuthdConnect failed
[VDDKLOG] Cnx_Connect: Returning false because CnxConnectAuthd failed
[VDDKLOG] Cnx_Connect: Error message: SSL required
Solution
Cette erreur est due au fait que l'authentification SSL est désactivée sur l'hôte VMware ESX. Pour corriger cette erreur, utilisez l'une des méthodes suivantes :
config.defaults.security.host.ruissl
/etc/vmware/config
L'authentification SSL est activée.
Problèmes liés à la connexion serveur
Symptôme
L'erreur suivante s'affiche parfois lorsque vous parcourez les journaux d'activité à partir de l'agent ou de la console :
Impossible de se connecter au serveur arcservedocs.com.
Solution
Vous pouvez ignorer ce message.
Problèmes liés aux machines virtuelles de secours
Symptôme
Un nœud est sauvegardé dans un référentiel de données de serveur de points de récupération, répliqué vers un autre référentiel de données de serveur de points de récupération, puis le système crée une machine Virtual Standby avec la source de réplication. Après le déploiement du plan, vous pouvez reprendre le job Virtual Standby directement s'il existe une session antérieure de ce job. En revanche, après avoir soumis le job, le job Virtual Standby ne démarre pas.
Solution
Pour résoudre ce problème, commencez par effectuer une réplication manuelle : Cliquez avec le bouton droit de la souris sur le nœud, puis cliquez sur Répliquer maintenant. Une fois la réplication terminée, reprenez le job Virtual Standby.
Symptôme
Le job Virtual Standby échoue avec l'erreur suivante :
Impossible d'obtenir la signature du disque (la signature de disque est vide).
Solution
Dans Arcserve UDP version 6.0, la bibliothèque du kit de développement de disques virtuels (VDDK) VMware est mise à niveau de la version 5.5 vers la version 6.0. Dans la version 6 du VDDK, l'initialisation de la bibliothèque VDDK nécessite un nouveau champ nommé Empreinte numérique. L'appel à partir de la conversion VSB repose sur la version 5.0 d'Arcserve UDP, dans laquelle l'empreinte numérique est manquante. Cela entraîne l'échec de l'appel du convertisseur vers le moniteur.
Pour résoudre ce problème, mettez à jour le convertisseur vers Arcserve UDP version 6.0.
Symptôme
L'Agent Arcserve UDP (Windows) est sauvegardé dans le référentiel de données du serveur de points de récupération Arcserve UDP et ce dernier est mis à niveau vers Arcserve UDP 6.0. En outre, l'Agent Arcserve UDP (Windows) est sauvegardé dans un dossier partagé et l'agent est mis à niveau vers Arcserve UDP 6.0. Le job Virtual Standby (VSB) vers Hyper-V échoue et les messages d'erreur suivants s'affichent :
Cannot find dispatch method for {http://webservice.arcflash.com}IsVmFileExist.
ou
Cannot find dispatch method for {https://webservice.arcflash.com}IsVmFileExist.
Solution
Mettez à niveau l'agent Arcserve UDP vers Arcserve UDP 6.0 sur le serveur Hyper-V.
Ce problème peut également se produire lorsque les machines virtuelles démarrées contiennent des volumes en lecture seule. Pour corriger ce problème, configurez les volumes sur le disque pour les rendre accessibles en écriture.
Echec de l'obtention de certaines informations de point de récupération.
Ce comportement se produit lorsque vous effectuez une récupération V2P à l'aide du dernier cliché et lorsqu'un job de conversion pour le noeud ne s'est pas terminé après le redéploiement de la tâche Virtual Standby sur le noeud.
Solution
Solution
Effectuez la récupération V2P à l'aide de la récupération à chaud de l'agent Arcserve UDP.
Remarque : Cette restriction s'applique uniquement aux jobs Virtual Standby exécutés sur des serveurs Hyper-V.
Symptôme
Agent Arcserve UDP (Windows) est équipé d'un disque de 2 To, or les serveurs ESX/ESX(i) d'une version inférieure à la version 5.5 peuvent uniquement prendre en charge un disque virtuel de 2 To maximum. Toutefois, pendant la conversion, les erreurs suivantes peuvent se produire :
Solution
Il s'agit d'une restriction de VMware. La taille maximum que les serveurs VMware ESX/ESX(i) d'une version inférieure à la version 5.5 prennent en charge est de 2 To-16 Go, soit 2032 Go.
Nous vous recommandons d'utiliser un serveur VMware ESX(i) 5.5 comme destination lorsque vous effectuez une conversion avec un disque de grande taille.
Pour plus d'informations, consultez l'article de connaissances 1012384 de VMware.
Symptôme
Le déploiement du plan échoue et le message d'erreur suivant s'affiche : Impossible d'appliquer les paramètres Virtual Standby au noeud xxx (Echec de la connexion de xxx au moniteur xxx. Informations d'identification de l'utilisateur non valides).
Solution
Modifiez la tâche Virtual Standby dans le plan, entrez le mot de passe approprié pour le moniteur et enregistrez le plan.
Problèmes liés au cliché instantané de volume
Solution
Remarque : Ce problème survient rarement. Pour plus d'informations, consultez l'article de connaissances 2006849 de VMware ou l'article de connaissances 2853247 de Microsoft.
Data Corruption During UDP Upgrade due to Backward Compatibility
You may notice data corruption for backward compatibility of protecting UDP v5 nodes to UDP v6 RPS, it might cause data corruption on deduplication data store.
This issue does not impact if you are using one of the following options:
This issue impacts if you have:
When do you face this data corruption:
If you are upgrading from Arcserve UDP v5 to Arcserve UDP v6, you may face this issue in the following scenarios:
Symptôme
The data corruption issue might happen in the following two scenarios.
Scenario 1: The Agent node is with Arcserve UDP v5 and the RPS node is with Arcserve UDP v6. Agent job fails to back up and generates the incomplete recovery point on the deduplication data store. Deleting the incomplete recovery point from the deduplication data store may lead to data corruption.
Scenario 2: The source RPS node is with Arcserve UDP v5 and the destination RPS node is with Arcserve UDP v6. The Replication job fails and generates the incomplete recovery point destination deduplication data store. Deleting the incomplete recovery point from the destination deduplication data store may lead to data corruption.
Reason
Due to the mismatch of interface between different versions, when Arcserve UDP v6 RPS tries to delete the incomplete sessions generated by Arcserve UDP v5, it may wrongly delete additional index files which leads to data corruption.
Solution
If you are upgrading from Arcserve UDP v5 to Arcserve UDP v6:
Note: Before applying the patch, do not run any backup/replication jobs.
Note: If you opt for this option, do not upgrade to Arcserve UDP v6. You can directly upgrade from Arcserve UDP v5 to Arcserve UDP v6 update 1.
If you have already upgraded from Arcserve UDP v5 to Arcserve UDP v6:
Note: Contact Arcserve Support to get the patch.
How to handle corrupted recovery points?
You cannot recover any recovery point that is corrupted due to the backward compatibility issue as the corresponding index file is incorrectly deleted.
To make sure that the subsequent recovery points do not depend on the corrupted recovery point, we recommend to take again full backup for the impacted node.
In addition, other jobs related to merge job that need to read from the corrupted recovery point might continue failing even though new full backup is done.
To solve the above, we recommend to rename the node folder in the backup destination folder of dedupe data store. Add Backup as prefix to the original node name.
For example:
NODE_NAME[1a98528f-db3c-45de-83d6-9d729815ab7d]
to
BackupNode_Name[1a98528f-db3c-45de-83d6-9d729815ab7d]
As a result, new folder name of the source node is created that automatically converts the recovery point as full when the specific node backs up to the data store again.
For the renamed folder, you can perform the following options:
You can select to delete the renamed node through data store UI, if all the recovery points in the renamed folder are not useful anymore. The automatic retention management of the Plan only applies to the new recovery points done after the renaming of the folder.
Si vous utilisez le navigateur Web Windows 10 Edge, vous risquez de ne pas pouvoir vous connecter aux agents Windows ou Linux à partir de la console lorsque vous cliquez sur Restaurer ou Connexion. Utilisez un autre navigateur pour vous connecter.
Symptôme
Imaginez que vous disposez de deux machines virtuelles, VM1 et VM2, portant le même GUID dans les hôtes ESXi et gérées par des serveurs vCenter différents, VC1 et VC2 respectivement. Vous importez VM1 dans la console (vous ne pouvez pas importer les deux machines virtuelles car la console ne permet pas d'avoir plusieurs nœuds portant le même GUID). Toutefois, vous importez également les machines virtuelles à partir du serveur vCenter VC2. Lorsque la détection automatique s'exécute, elle se connecte d'abord à VC1 et détecte VM1 en fonction de son GUID ; la colonne Hyperviseur est mise à jour avec les informations de VC1. Par la suite, lorsqu'elle se connecte à VC2, elle détecte VM2 en fonction de son GUID et la colonne Hyperviseur est mise à jour avec les informations de VC2.
Solution
C'est très rare que deux machines virtuelles portent le même GUID. Dans le pire des cas, si cela arrive, la sauvegarde sans agent basée sur un hôte risque de sauvegarder la mauvaise machine virtuelle car Arcserve UDP utilise le GUID pour identifier une machine virtuelle. Pour résoudre ce problème, vous pouvez modifier manuellement le GUID de l'une des deux machines virtuelles. Pour plus d'informations sur cette procédure, reportez-vous à la rubrique associée dans le Manuel des solutions.
Symptôme
Vous ne parvenez pas à vous connecter à la console Arcserve UDP. Celle-ci affiche le message suivant même après cinq minutes de connexion :
Identity Service is starting
Solution
Pour corriger cette erreur, procédez comme suit :
Symptôme
Le job de lancement rapide pour plusieurs nœuds échoue si un job de réplication est en cours d'exécution sur un des nœuds.
Solution
Vous pouvez soit attendre que le job de réplication se termine avant de soumettre le job de lancement rapide, soit soumettre le job de lancement rapide sur d'autres nœuds.
Symptôme
Le job de copie sur bande peut échouer dans les cas suivants :
Solution
Pour résoudre le premier problème, ajoutez le nœud de l'agent Arcserve UDP à l'interface utilisateur de la console Arcserve UDP avec un nom d'utilisateur non localisé.
Pour résoudre le deuxième problème, ajoutez le nœud du serveur de points de récupération à la console Arcserve UDP avec un nom d'utilisateur non localisé.
Symptôme
Le paramètre d'unité NAT est redondant dans la tâche Répliquer à partir d'un RPS géré à distance lorsque vous devez modifier le plan dans l'environnement NAT, si le plan contient les tâches suivantes :
Lorsque vous devez modifier le plan et afficher la configuration de la tâche 1, l'option Le serveur se trouve derrière une unité NAT sera redondante si l'option Le serveur se trouve derrière un routeur NAT est configurée. La tâche de réplication peut réussir, si les informations du routeur NAT sont fournies correctement.
Solution
Vous pouvez ignorer le champ Le serveur se trouve derrière une unité NAT de la tâche Répliquer à partir d'un RPS géré à distance lorsque vous modifiez le plan redondant. Utilisez le champ Le serveur se trouve derrière un routeur NAT pour garantir la réussite du job de réplication.
Symptôme
Le filtre supérieur BLI de Registre de classe de volume étant supprimé, le pilote BLI ne peut pas surveiller les volumes.
Solution
Vous pouvez continuer à effectuer une sauvegarde incrémentielle après avoir réinstallé le pilote de suivi des modifications.
Suivez ces étapes:
<chemin_installation>\Arcserve\Unified Data Protection\Engine\BIN\DRIVER
<chemin_installation>\Arcserve\Unified Data Protection\Engine\BIN\DRIVER
Symptôme
Les messages suivants peuvent s'afficher dans le journal d'événements : "Tentative d'opération non autorisée sur une clé du Registre marquée pour suppression", ou "Windows a détecté que votre fichier de Registre est toujours utilisé par d'autres applications ou services". Le fichier va être déchargé. Les applications ou services qui ont accès à votre Registre risquent de ne pas fonctionner correctement après cela.
Solution
Pour plus d'informations sur la cause et la solution, reportez-vous à l'article de connaissances de Microsoft 2287297.
Symptôme
Le montage d'une session sur un lecteur échoue.
Un tel échec du montage a lieu lorsque la destination est un dossier local et un volume FAT32. En effet, le montage d'un pilote prend uniquement en charge la création du fichier cache sur le volume NTFS.
Solution
Ajoutez une nouvelle clé de registre et définissez le chemin d'accès au fichier cache sur un autre volume.
Suivez ces étapes:
Informations complémentaires :
Le fichier cache est créé par le biais du montage d'un pilote au moment du montage d'un volume accessible en écriture. Pour le job de restauration/catalogue de restauration détaillée, un volume accessible en écriture est créé. Les sessions de sauvegarde de volumes requièrent le montage d'un volume accessible en écriture au moment du montage d'une session vers un pilote lorsqu'elles ont lieu sur un système d'exploitation Windows 8, Windows 2012, ou ultérieur.
Symptôme
La sauvegarde soumise s'affiche correctement, mais aucun moniteur de jobs n'apparaît dans l'interface utilisateur de l'Agent Arcserve UDP (Windows). Ce problème s'explique par le fait que le job de sauvegarde remplit le paramètre de nombre maximum de noeuds simultanés dans le référentiel de données et est donc mis en attente.
Solution
Ouvrez la console Arcserve UDP. Le moniteur de jobs en attente apparaît dans la vue des nœuds.
Symptôme
Lorsqu'un job de sauvegarde par vérification sans agent et utilisant un hôte est en cours d'exécution et si la compression a été activée dans le plan, le pourcentage de compression affiché dans le moniteur de jobs est plus élevé que le pourcentage réel.
Tous les autres jobs de sauvegarde n'ont pas ce problème, notamment les jobs de l'agent de sauvegarde et des jobs de sauvegarde complète/incrémentielle sans agent et utilisant un hôte.
Solution
Le pourcentage de compression enregistré dans le journal d'activité est correct. Consultez-le une fois que le job de sauvegarde par vérification sans agent et utilisant un hôte est terminé.
Symptôme
Le job de sauvegarde de la machine virtuelle VMware se termine sur la console Arcserve UDP. Le job est indiqué par l'icône verte et le journal d'activité affiche le message Le job de sauvegarde est terminé. Toutefois, un fichier de vidage de processus d'arrière-plan, comme AFBackend.exe.7912.00.dmp, est généré dans le dossier BIN situé dans le chemin d'installation de l'agent. Exemple : C:\Program Files\Arcserve\Unified Data Protection\Engine\BIN.
Solution
Ce problème survient en raison d'un problème VDDK VMware lorsque VDDK s'arrête parfois brutalement lors de la fermeture des appels API Arcserve UDP à VDDK. Vous pouvez ignorer ce problème car il se produit lors de la dernière phase du job de sauvegarde. A ce stade, le job de sauvegarde est presque terminé et le point de récupération a été encapsulé correctement.
Echec de l'intégration du package linguistique à l'image ISO de récupération à chaud
Symptôme
Ce problème est dû au pilote de filtre du logiciel antivirus tiers McAfee, mais il peut également survenir avec d'autres filtres tiers.
Solution
Désactivez votre logiciel antivirus et réessayez de créer le kit de démarrage.
Symptôme
Lorsque l'ordinateur source est un serveur Active Directory effectuant une récupération à chaud sur un ordinateur physique équipé d'un autre appareil ou sur une machine virtuelle installée sur un serveur Hyper-V, le serveur ne démarre pas et une fenêtre bleue s'affiche avec le message suivant :
STOP: c00002e2 Les services d'annuaire n'ont pas pu démarrer en raison de l'erreur suivante : un périphérique attaché au système ne fonctionne pas correctement. Statut d'erreur : 0xc0000001.
Solution
Redémarrez le système sur l'environnement PE de récupération à chaud, renommez tous les fichiers *.log dans le dossier C:\Windows\NTDS et redémarrez le système. Par exemple, remplacez le nom du fichier edb.log par edb.log.old et redémarrez le système.
Symptôme
Le mappage du disque ou du volume pendant la récupération à chaud peut être impossible à réaliser lorsque l'ordinateur cible est une machine virtuelle équipée d'un disque IDE sur un serveur Hyper-V 2008 ou 2008 R2.
Si vous restaurez des données sur une machine virtuelle dotée d'un disque IDE sur un serveur Hyper-V 2008 ou 2008 R2 à l'aide de la fonctionnalité de récupération à chaud, le mappage du disque ou du volume source vers le disque ou le volume cible est impossible, même si la taille des deux disques affichée est identique. Ce problème s'explique par le fait que la taille de disque réelle est inférieure à la taille spécifiée, lors de la création d'un disque IDE sur un serveur Hyper-V 2008 ou 2008 R2.
Solution
Créez un disque plus grand sur la machine virtuelle. Par exemple, si vous voulez restaurer des données à partir d'un disque de 25 Go, il est recommandé de créer un disque de 26 Go sur la machine virtuelle cible.
Symptôme
Ce problème a été observé sur les serveurs VMware ESX. Pour des machines virtuelles Windows 2003, le contrôleur de disque par défaut est l'adaptateur SCSI de logique de LSI et le pilote pour ce type d'adaptateur SCSI n'est pas inclus dans Windows ADK 8.1. Vous pouvez également observer cela sur certains anciens serveurs contenant d'anciens adaptateurs SCSI.
Solution
Pour résoudre ce problème, obtenez les pilotes à partir du site Web du fournisseur de matériel et chargez-les à partir de l'interface utilisateur de récupération à chaud.
[VDDKLOG] SSLCheckLockingCallback : rappel de verrouillage remplacé 7FEE3A836E0 attendu, 113C2420 reçu
Pour résoudre ce problème, définissez la clé de Registre VDDKLogLevel sur 0 à l'emplacement suivant :
\HKEY_LOCAL_MACHINE\Software\Arcserve\Unified Data Protection\Engine\
Impossible de créer la copie de cliché {xxx}_backup sur plusieurs volumes du système de stockage xxx après 100 tentatives à l'aide d'un intervalle de 10 secondes.
Pour créer la clé de Registre, procédez comme suit :
HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine
DoNotUseFlexCloneLicenseToCloneLun
Après avoir basculé vers la vue Point de récupération Arcserve UDP , le volume monté sous un chemin d'accès au fichier dans la session de sauvegarde ne peut pas être monté.
Symptôme
Si le volume est encore monté, la vue Point de récupération Arcserve UDP ouvre directement le volume monté par le système d'exploitation, pas la session de sauvegarde.
Si le volume est démonté, rien ne s'affiche dans la vue Point de récupération Arcserve UDP sous le chemin d'accès à ce fichier.
Solution
Utilisez l'option Monter le point de récupération pour monter ce type de volume.
Symptôme
VMware a récemment publié un article de connaissances qui indique que, sous ESXi 6.0 ou ESXi 6.0.x, un bogue a été introduit au niveau de la fonction de suivi des blocs modifiés (CBT), de sorte que cette dernière renvoie une liste incorrecte des secteurs modifiés. Il se peut que Arcserve UDP soit concerné par ce problème, qui entraîne une incohérence des sauvegardes de machines virtuelles (complètes et incrémentielles). Pour plus d'informations, consultez la base de connaissances VMware.
Si le problème se produit, le job de catalogage peut échouer et la vérification du point de récupération peut signaler des erreurs.
Solution
VMware a publié un patch pour ce problème. Appliquez ce patch sur les hôtes ESXi. Pour plus d'informations, consultez l'article de connaissances de VMware ou l'article de connaissances de Microsoft.
Symptôme
Ce problème survient si l'hôte Hyper-V est Windows Server 2012 R2 et que le système d'exploitation invité de la machine virtuelle est SUSE Linux Enterprise Server (SLES) 12 avec un niveau d'exécution 5 (avec l'interface graphique). Dans ce cas, le job de sauvegarde sans agent se bloque au niveau de la prise d'instantané et finit par échouer. Ensuite, le système d'exploitation invité de la machine virtuelle ne répond plus.
Solution
Il ne s'agit pas d'une défectuosité de Arcserve UDP, mais d'un problème de compatibilité entre Windows et SUSE. Le même problème se produit lors de la création d'un cliché instantané de volume à l'aide de la commande diskshadow sur l'hôte Hyper-V. Pour vérifier le problème, procédez comme suit :
Il n'existe aucune solution pour l'instant. Nous vous suggérons de travailler avec Microsoft pour résoudre la cause première. Vous pouvez également essayer de modifier le niveau d'exécution de SLES 12 de 5 à 3 (sans interface graphique), mais cela ne garantit pas la résolution du problème.
Symptôme
Pour une machine virtuelle VMware, la vérification préalable (PFC) renvoie le message d'avertissement suivant pour la vérification de la cohérence des données, même lorsque vous avez déjà entré des informations d'identification correctes.
Aucune vérification n'a été effectuée, car l'application n'a pas pu accéder à la machine virtuelle. Vérifiez que les informations d'identification utilisateur sont correctes et qu'elles sont associées à des droits d'administration.
Solution
Ce problème de vérification préalable concerne uniquement les machines virtuelles VMware. Les autres fonctionnalités telles que la sauvegarde ne sont pas affectées. La solution consiste à installer l'agent Arcserve UDP sur la machine qui héberge la console Arcserve UDP (le service d'agent ne doit pas être démarré).
Symptôme
Même lorsqu'un transport en mode SAN est possible, les jobs de sauvegarde et de restauration utilisent toujours le mode de transport Ajout à chaud, NBD ou NBDSSL.
Solution
Il s'agit d'un problème connu de VMware VDDK 6.0.1. VMware ne propose toutefois aucune solution pour le moment. Pour plus d'informations, référez-vous à la section Known Issues du document VDDK 6.0.1 Release Notes.
Symptôme
Même lorsqu'un transport en mode SAN est possible, les jobs de sauvegarde et de restauration utilisent toujours le mode de transport Ajout à chaud, NBD ou NBDSSL lorsque la taille provisionnée du disque virtuel de la machine virtuelle est de 4 To ou un multiple de 4 To.
Solution
Il s'agit problème connu de VMware qui, selon le fabricant, concerne les patchs suivants :
• Pour ESXi 5.5 - Patch version ESXi550-201504001 (2112672)
• Pour ESXi 6.0 - Patch version ESXi600-201505001 (2116125)
La solution consiste à éviter d'utiliser une taille provisionnée qui est un multiple de 4 To. Par exemple, n'utilisez pas 4 ou 8 To ; optez plutôt pour 3,9 ou 8,1 To.
Symptôme
Lorsque vous suspendez une machine virtuelle VMware à l'aide de VMware Tools, le cliché contient des données endommagées. La sauvegarde lisant les données à partir du cliché, les données sauvegardées sont également endommagées. Pour plus d'informations concernant ce problème, consultez l'article de connaissances VMware suivant :
Remarque : Ce problème se produit avec toutes les versions de VMware ESXi et sur les machines virtuelles dotées d'un système d'exploitation invité Windows 2008 R2 SP1 ou Windows 2012. Arcserve UDPne détecte pas le problème d'endommagement des données, car VMware ne retourne aucune erreur dans ce cas. Il se peut dès lors que vous ne vous rendiez compte du problème que lorsque vous tentez de restaurer les données.
Solution
Exécutez les tâches suivantes pour détecter et résoudre le problème :
Symptôme
Lors de la sauvegarde d'une machine virtuelle à l'aide de la méthode de suspension des clichés Microsoft VSS sur la machine virtuelle, la sauvegarde risque d'être incohérente, surtout en cas de sauvegarde d'une machine virtuelle sur laquelle des applications (telles qu'Exchange) sont installées.
Solution
La solution consiste à utiliser la méthode de suspension des clichés VMware Tools et à désactiver les enregistreurs VSS MSSearch Service Writer et Shadow Copy Optimization Writer dans le système d'exploitation invité de la machine virtuelle.
Impossible de connecter l'adaptateur réseau <<nom de l'adaptateur>> au commutateur virtuel.
Symptôme
Lorsque vous sauvegardez une machine virtuelle, un basculement intervient pour la machine virtuelle mise en cluster avant la prise d'un cliché. Cela entraîne une incohérence entre l'hôte Hyper-V enregistré dans la session de sauvegarde et la configuration de machine virtuelle.
Solution
Vous pouvez relier manuellement l'adaptateur réseau à un commutateur virtuel sur l'hôte Hyper-V ou utiliser l'option de restauration vers un autre emplacement pour récupérer la machine virtuelle avec laquelle vous pouvez définir la configuration de la restauration pour la machine virtuelle.
Symptôme
Bien que le job de sauvegarde d'une machine virtuelle soit déjà fini, le statut de la machine virtuelle reste Sauvegarde dans le gestionnaire Hyper-V. Par conséquent, si un autre job de sauvegarde pour cette machine virtuelle commence à ce moment-là, il échoue avec un message "Une erreur s'est produite au niveau de l'enregistreur VSS Hyper-V pendant le traitement de cette machine virtuelle.". De plus, à ce moment-là, certaines opérations comme allumer/éteindre la machine sont impossibles pour la machine virtuelle au niveau du gestionnaire Hyper-V. Si la machine virtuelle est un cluster Hyper-V, vous ne pouvez pas effectuer de migration en direct pour cette machine.
Ce problème survient dans les situations suivantes :
Solution
Lorsque la machine virtuelle est verrouillée, vous pouvez malgré tout utiliser le système d'exploitation invité. Par conséquent, ce problème n'a aucun impact sur l'utilisation ni sur la disponibilité du système d'exploitation d'invité. Toutefois, si vous avez des questions et que vous souhaitez éviter cette situation, vous pouvez procéder de l'une des façons suivantes :
Symptôme
Il s'agit d'un problème connu de VMware affectant le suivi des blocs modifiés. Avec la suspension au niveau application, le suivi des blocs modifiés amplifie les modifications.
Solution
Le problème est résolu dans VMware ESXi 5.5 ou version ultérieure et VMware ESX 5.1 Patch 02. Si VMware vCenter Server 5.5 gère des hôtes VMware ESXi 5.1, le patch doit leur être appliquer. Pour plus d'informations sur cette résolution, consultez la base de connaissances de VMware.
Si le problème persiste, définissez le Registre suivant sur le serveur proxy :
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\<UUID_instance_VM>]
"ResetCBT"=dword:00000001
Exemple :
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\502d3c43-e3c9-9919-78f9-89082ca5e1cc]
"ResetCBT"=dword:00000001
Remarque : Une fois la valeur de registre définie, le job de sauvegarde incrémentielle suivant se convertit en job de sauvegarde par vérification. La taille des autres jobs de sauvegarde incrémentielle sera ensuite correcte.
Pour plus d'informations, consultez l'article de connaissances 2055943 de VMware.
Symptôme
Les fichiers VMDK de la machine virtuelle de la source de sauvegarde occupent plus de 2 To, or les serveurs ESX/ESX(i) d'une version inférieure à la version 5.5 peuvent uniquement prendre en charge un disque virtuel de 2 To maximum. Toutefois, pendant la récupération de la machine virtuelle, les erreurs suivantes peuvent se produire :
Solution
Il s'agit d'une restriction de VMware. La taille maximum que les serveurs VMware ESX/ESX(i) d'une version inférieure à la version 5.5 prennent en charge est de 2 To-16 Go, soit 2032 Go.
Nous vous recommandons d'utiliser un serveur VMware ESX(i) 5.5 comme destination lorsque vous effectuez une conversion avec un disque de grande taille.
Pour plus d'informations, consultez l'article de connaissances 1012384 de VMware.
Symptôme
Le job de sauvegarde échoue lorsque vous l'exécutez sur une machine virtuelle dotée d'un contrôleur SCSI avec plus de 7 disques VMDK. Cela est dû au fait que VMware requiert la présence d'un nombre maximum de logements libres pour que les disques VMDK d'un contrôleur SCSI puissent créer un cliché. Le nombre maximum de logements pour un contrôleur SCSI est 15. Par exemple, si un contrôleur SCSI possède 7 disques VMDK, vous pouvez créer un cliché pour chacun d'entre eux (14 logements sont utilisés au total et l'un d'entre eux est libre). En revanche, le job de sauvegarde échoue pour les contrôleurs SCSI équipés de 8 disques VMDK, car la création du cliché est impossible étant donné que seuls 15 logements sont disponibles.
Remarque : La création manuelle d'un cliché échoue également.
Solution
Pour les machines virtuelles dotées de plus de sept disques sur un contrôleur SCSI unique, procédez comme suit :
Vous pouvez désormais créer des clichés pour chaque disque VMDK.
Ce problème est lié à une restriction VMware qui limite la prise en charge par Arcserve Backup au nombre de disques VMDK pour les sauvegardes.
Pour plus d'informations, consultez l'article de la base de connaissances VMware suivant : http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2015181
Pour résoudre ce problème, supprimez l'ancienne machine virtuelle au niveau de CA ARCserve Central Protection Manager et importez la nouvelle machine virtuelle.
Symptôme
Il s'agit d'un problème connu sous VMware, qui affecte les hôtes ESXi 5.0, 5.1 et 5.5 et les machines virtuelles utilisant des adaptateurs réseau virtuels E1000 et E1000e.
Remarque : Ce problème est résolu dans les mises à jour VMware suivantes.
Solution
Optez pour un adaptateur VMXNET3. Pour plus d'informations, consultez l'article de connaissances 2059053 de VMware.
Symptôme
Lorsqu'une machine virtuelle est importée dans la vue des nœuds, l'opération échoue si une autre machine virtuelle possédant le même UUID d'instance a déjà été ajoutée à la vue.
Symptôme
Lorsqu'un plan de sauvegarde de machine virtuelle utilisant un hôte inclut un ordinateur proxy doté d'une version précédente de Arcserve D2D (par exemple, la version r16.5), le message d'erreur "Cannot find dispatch method" (Méthode de distribution introuvable) s'affiche à l'enregistrement du plan.
Solution
Ce problème s'explique par le fait que l'API de la version actuelle de Arcserve D2D n'est pas compatible avec l'API de la version précédente. Pour contourner ce problème, vous pouvez mettre manuellement à niveau le Arcserve D2D vers la version actuelle de l'Agent Arcserve UDP (Windows).
Symptôme
Le job de sauvegarde se bloque pendant des heures et ne peut pas se poursuivre.
Solution
Arrêtez le processus afbackend.exe en fonction de son ID dans le journal d'activité, supprimez le cliché de machine virtuelle le cas échéant, puis resoumettez le job de sauvegarde.
Symptôme
Le comportement du système d'exploitation crée l'état Hors ligne par défaut.
La stratégie SAN a été introduite dans Windows Server 2008 pour protéger les disques partagés par plusieurs serveurs. La stratégie de SAN par défaut à partir de la machine virtuelle source est Mettre hors connexion les disques partagés pour tous les disques SAN, sauf le disque de démarrage. La définition de la stratégie sur Hors ligne permet aux disques SAN d'être hors ligne pendant le démarrage. Après la récupération, un nouveau disque est créé pour la machine virtuelle. Le fichier de disque de la machine virtuelle est un disque SAN identifié par le système d'exploitation comme étant hors ligne. Une fois le disque de nouveau en ligne, il le reste même après le redémarrage du système.
Solution
Pour contourner le problème, spécifiez la commande DISKPART.exe : SAN POLICY=OnlineAll setting for the source VM before backup. Etant donné que les disques peuvent être partagés par d'autres serveurs, un endommagement des données peut se produire. Il est important que vous utilisiez la stratégie SAN correcte pour protéger les données.
Ligne de commande DISKPART.EXE
Interrogation de la stratégie SAN :
DISKPART > san
Stratégie SAN : Mode hors ligne partagé
Modification de la stratégie SAN :
DISKPART > san policy=OnlineAll
DISKPART modifie la stratégie SAN pour le système d'exploitation actuel.
Symptôme
Les volumes présents sur les unités iSCSI ne sont pas répertoriés dans l'interface utilisateur de restauration après la sauvegarde d'une machine virtuelle Hyper-V.
Solution
Créez un plan de sauvegarde basé sur un agent dans Arcserve UDP ou utilisez Agent Arcserve UDP (Windows) pour sauvegarder la machine virtuelle.
Symptôme
Si vous avez des jobs de sauvegarde sans agent et utilisant un hôte sur une machine virtuelle Hyper-V, les commandes de pré/post-sauvegarde ne peuvent pas être exécutées si le système d'exploitation invité est Windows Server 2003. Le journal d'activité enregistre l'avertissement Le nom de la machine virtuelle n'est pas celui attendu. Les commandes de pré/post-sauvegarde ne pourront pas être exécutées.
Solution
Ce problème ne concerne pas les systèmes d'exploitation Windows Server 2008, Windows Vista et ultérieurs ; il est donc recommandé de les utiliser.
Symptôme
Lorsque la machine Windows 2003 R2 64 bits est utilisée en tant que serveur proxy de sauvegarde pour protéger la machine virtuelle VMware, le job de sauvegarde s'arrête parfois brutalement. Des messages d'erreur tels que celui-peuvent s'afficher dans le fichier journal de débogage du job de sauvegarde :
[2016/01/21 10:18:11:316 00 03820 03336 ] [VDDKLOG] VixDiskLib: VixDiskLib_OpenEx: Ouvrez un disque. {AFBackend.exe::AFBackupVirtual.dll(1746.0)}
[2016/01/21 10:18:11:316 00 03820 03336 ] [VDDKLOG] VixDiskLibVim: VixDiskLibVim_GetNfcTicket: Obtenez un ticket NFC pour [datastore1 (3)] VMname/VMware_1.vmdk. {AFBackend.exe::AFBackupVirtual.dll(1746.0)}
[2016/01/21 10:19:11:691 00 03820 03336 ] [VDDKLOG] VixDiskLibVim: Erreur 18000 (listener error GVmomiFaultInvalidResponse). {AFBackend.exe::AFBackupVirtual.dll(1746.0)}
[2016/01/21 10:19:11:691 00 03820 03336 ] [VDDKLOG] VixDiskLibVim: Echec de connexion. Erreur de rappel 18000 à 2439. {AFBackend.exe::AFBackupVirtual.dll(1746.0)}
[2016/01/21 10:19:11:691 00 03820 03336 ] [VDDKLOG] VixDiskLibVim: La machine virtuelle est introuvable. Erreur 18000 à 2511. {AFBackend.exe::AFBackupVirtual.dll(1746.0)}
Solution
Arcserve UDP version 6.0 intègre VMWare VDDK 6.0.1, mais VDDK 6.0.1 ne prend pas officiellement en charge Windows 2003 R2. Pour résoudre ce problème, utilisez l'une des solutions suivantes :
Procédure d'application d'une autre version de VDDK que la version intégrée (6.0.1) dans Arcserve UDP
Symptôme
Lorsque vous utilisez les informations ESX pour vous connecter à un pool de ressources et le sélectionner comme emplacement de la machine virtuelle instantanée, cette dernière se trouve sous le système hôte ESX et non dans le pool de ressources. Si vous supprimez la machine virtuelle instantanée de la console et que vous en recréez une autre portant le même nom, un suffixe (1) sera ajouté au nom de la machine virtuelle instantanée, mais pas à l'horodatage.
Solution
Cela est dû au fait que le serveur ESX est géré par un système vCenter. Utilisez les informations de connexion vCenter pour créer la machine virtuelle instantanée.
Symptôme
Lorsque je lance la machine virtuelle instantanée, puis redémarre le serveur de récupération Hyper-V, il arrive que la machine virtuelle instantanée ne démarre pas.
Solution
Pour résoudre ce problème de démarrage, redémarrez la machine virtuelle instantanée.
Symptôme
J'ai affecté un volume Windows comme dossier partagé NFS et fourni ce chemin d'accès de volume partagé en tant que chemin du fichier de machine virtuelle instantanée. Lorsque je formate le volume Windows, puis que j'essaie de créer la machine virtuelle instantanée, la création échoue. La création de la machine virtuelle instantanée échoue car l'hôte ESXi ne parvient pas à ajouter le référentiel de données NFS. VMware affiche un message d'erreur similaire au suivant :
VMware n'a pas pu créer la machine virtuelle.
Un journal d'erreur semblable au suivant s'affiche dans le fichier vmkernal.log :
Aucune unité sous-jacente pour majeur, mineur
Solution
Pour corriger ce problème, effectuez les étapes suivantes sur le serveur de récupération :
La boîte de dialogue Outils d'administration s'affiche.
La boîte de dialogue Services s'ouvre.
La machine virtuelle instantanée est créée.
Le filtre journal ne fonctionne pas lorsque le nom du noeud est VM(nom_hôte) et la vue de journal est chargée via le lien Afficher les journaux.
Symptôme
Dans la vue de journal, si une machine virtuelle protégée n'a aucun nom d'hôte, la valeur du nom de noeud est affichée sous la forme VM(nom_noeud). Dans ce cas, d'autres filtres ne peuvent également pas être appliqués.
Solution
Pour pouvoir appliquer les filtres correctement, vous pouvez manuellement remplacer le nom de noeud de la machine virtuelle (nom d'hôte) par le nom d'hôte. Par exemple, remplacez le nom de noeud VM(xxxxx01-AB) par "xxxxx01-AB".
Un échec du pilote de montage de l'installation se produit avec le code d'erreur 1460 dans le journal de débogage.
Symptôme
L'API d'installation de Windows renvoie l'erreur 1460, qui indique que le délai a expiré. La valeur du délai d'expiration par défaut est de 300 secondes pour la mise à jour du pilote d'unité.
Solution
Pour ajuster le délai d'expiration, procédez comme suit :
La restauration de la base de données Exchange échoue avec l'erreur suivante : Echec du montage
Symptôme
Ce problème survient lorsque le serveur Exchange est installé sur une machine virtuelle et qu'il exécute l'Agent Arcserve UDP (Windows) dans le cadre de la protection de cette machine virtuelle. Au cours de la sauvegarde, si vous restaurez la machine virtuelle sur un cliché préalablement enregistré et que vous essayez de récupérer la base de données Exchange à son emplacement d'origine, la restauration échoue avec un message d'erreur indiquant que la base de données ou le groupe de stockage Exchange [nom_BdD] a été restauré(e) à son emplacement original, mais n'a pas pu être monté(e).
La cause première fait toujours l'objet d'une étude, mais elle semble être liée à l'horodatage enregistré dans la base de données Exchange et dans les tout derniers fichiers journaux de transaction.
Solution
Lancez la récupération de la base de données Exchange dans un autre répertoire, ou démontez la base de données, puis supprimez tous les fichiers dans le dossier de destination et lancez la restauration.
L'impossibilité pour le serveur Microsoft SQL Server d'allouer davantage de mémoire peut ralentir l'envoi d'une réponse par la console Arcserve UDP.
Symptôme
Microsoft SQL Server doit parfois allouer davantage de mémoire pour le traitement d'une requête, en particulier lorsque la base de données Arcserve UDP inclut une grande quantité de données. Toutefois, s'il ne peut pas acquérir davantage de mémoire en raison de la non-disponibilité de mémoire supplémentaire ou parce que la taille maximum de mémoire définie a été atteinte, le traitement de la requête devient très lent, ce qui ralentit la réactivité de la console Arcserve UDP.
Solution
Supprimez des journaux dans la base de données à l'aide de l'option Journal/Supprimer et redémarrez le Service SQL.
Symptôme
Lorsque vous soumettez un job de fusion manuellement, le job ne s'exécute pas et le message suivant s'affiche dans le journal d'activité :
Impossible d'exécuter le job de fusion pour <nom_nœud>, car un autre job est en cours d'exécution.
Solution
Cette erreur peut être due au fait que d'autres jobs sont en cours d'exécution pour le nœud sur le même serveur de points de récupération, mais dans un référentiel de données différent. Pour résoudre ce problème, attendez que ces jobs se terminent, puis réessayez.
Symptôme
Le job de sauvegarde ou de réplication échoue et un message d'erreur indique que le fichier spécifié est introuvable.
Vérifiez le journal d'événements Windows. McAfee détecte le fichier de référentiel de données (par exemple, P0000000042.data) comme étant un virus de type cheval de Troie Exploit-ScriptNull et le supprime.
Solution
Configurez le paramètre d'antivirus de sorte à définir l'emplacement du référentiel de données du serveur de points de récupération dans la liste d'exclusion.
Remarque : Certains logiciels antivirus requièrent la définition de la liste d'exclusion côté serveur.
Symptôme
Ce problème survient lorsque vous définissez la limitation du réseau sur une valeur de bande passante faible ou que le débit réseau vers le serveur de points de récupération de destination est lent. Par conséquent, l'envoi des données placées dans la file d'attente peut prendre plusieurs minutes.
Solution
Patientez jusqu'à la finalisation du job de réplication.
Symptôme
Si vous tentez d'ajouter un noeud par adresse IP ou nom de noeud sur des systèmes d'exploitation Windows qui prennent en charge le contrôle de compte d'utilisateur (Windows Vista ou versions ultérieures) ou que vous essayez d'importer des machines virtuelles à partir d'un serveur Hyper-V qui prend en charge le contrôle de compte d'utilisateur et que vous utilisez un nouveau compte d'utilisateur Windows qui est un compte local du groupe d'administrateurs, mais qu'il ne s'agit pas de l'administrateur intégré, le message suivant s'affiche :
Des droits d'administrateur sont requis.
Solution
Utilisez un administrateur intégré ou un administrateur de domaines, ou désactivez la fonctionnalité de contrôle de compte d'utilisateur à distance.
Il s'agit du comportement Windows par défaut connu comme restrictions distantes de contrôle de compte d'utilisateur. Si vous voulez encore utiliser ce compte pour ajouter le noeud, désactivez Remote UAC en procédant comme suit :
L'Editeur du Registre Windows s'affiche.
Remarque : L'ouverture de l'Editeur du Registre Windows peut requérir la saisie d'informations d'identification d'administration.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Pour plus de détails concernant les comportements Windows, reportez-vous à l'article http://support.microsoft.com/kb/951016.
Symptôme
La suppression de la fonction d'hyperviseur pour un noeud n'est pas prise en charge dans cette version.
Solution
Supprimez le noeud et rajoutez-le.
Symptôme
L'interface utilisateur tout en un de Arcserve UDP n'envisage pas l'utilisation de plusieurs consoles Arcserve UDP, c'est pourquoi le déplacement de l'agent d'un serveur à un autre est considéré comme pouvant avoir lieu uniquement lorsque l'ancien serveur est retiré.
Solution
Il est très rare d'avoir à déplacer le noeud d'une console à une autre.
Les jobs de restauration, de fusion ou de catalogage peuvent échouer lorsque la destination de sauvegarde est un volume NTFS activé pour la déduplication sous Windows Server 2012 et que l'Agent Arcserve UDP (Windows) est installé sous Windows 2003. Le job échoue avec le code d'erreur Windows 50 et le message indiquant que la requête n'est pas prise en charge.
Symptôme
McAfee ou un autre logiciel tiers est défini sur EnableECP=1 dans le registre lorsqu'ils sont installés sous Windows Server 2012.
Solution
Dans le registre, remplacez la valeur EnableECP 1 par 0 sous la clé suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanManServer\Parameters
Pour plus d'informations, consultez l'article http://support.microsoft.com/kb/2817216.
Symptôme
Le deuxième job de réplication se bloque au statut de préparation et renvoie un échec après 10 minutes.
Solution
Aucune action n'est requise, car après l'échec du deuxième job de réplication, le job de rattrapage sera déclenché.
Symptôme
Le job de réplication (en entrée) échoue et le journal d'activité affiche le message Echec du verrouillage de la session sur <path>. La session est déjà verrouillée par le job de copie des fichiers. Nom de l'ordinateur : <name>, ID du processus <ID>. Il se produit lorsque la sauvegarde avec le job de Catalogue de systèmes de fichiers est activée et que vous configurez le job de copie des fichiers à partir du référentiel de données cible de réplication.
Solution
Le job de copie de fichiers verrouille la session de sorte que le job de réplication ne peut pas s'exécuter. Pour résoudre ce problème, utilisez l'une des options suivantes :
Symptôme
A l'issue d'un job de restauration, les propriétés d'élément suivantes peuvent ne pas être correctement restaurées :
Solution
Utilisez l'option d'exportation au format PST pour restaurer les éléments manquants.
Symptôme
Ce problème survient dans les cas suivants :
Solution
Pour vous aider à résoudre le problème, essayez l'une des solutions suivantes :
Symptôme
Lorsque vous utilisez la mise à jour 4 ou des versions antérieures de l'agent, les erreurs suivantes se produisent :
La base de données ou le groupe de stockage Exchange a été restauré(e) à son emplacement original, mais n'a pas pu être monté(e).
Solution
Mettez à niveau les agents vers la version 6.0 de l'agent Arcserve UDP.
Symptôme
Lorsque la destination de restauration est un dossier de partage distant comme \\FileServer\ShareFolder\RestDest et que la destination de sauvegarde est un dossier de partage distant avec le même chemin d'accès (\\FileServer\ShareFolder\RestDest), une erreur se produit.
Si le compte d'utilisateur utilisé pour la connexion au dossier de partage racine ne figure pas dans la liste d'autorisation, le job de restauration échouera quel que soit le compte utilisé pour le dossier de destination de la restauration.
Solution
Ajoutez le compte d'utilisateur affecté à la destination de sauvegarde pour créer la connexion dans la liste d'autorisation du dossier de partage racine et veillez à ce que le compte d'utilisateur dispose des autorisations appropriées pour la restauration du fichier.
Ajoutez le compte d'utilisateur dans le groupe Opérateurs de sauvegarde et vérifiez qu'il dispose des autorisations nécessaires pour ignorer des restrictions de sécurité.
Symptôme
Si le chiffrement est activé pour le point de récupération, il n'est pas nécessaire d'entrer le mot de passe pour les points de récupération sauvegardés à partir du serveur actuel. Toutefois, si vous mettez à niveau le système d'exploitation Windows (par exemple, de Windows 2008 à Windows R2 2008), les mots de passe ne sont pas automatiquement saisis dans l'interface utilisateur de l'Agent Arcserve UDP (Windows) et vous devez les ressaisir.
Solution
Enregistrez le mot de passe de chiffrement du point de récupération ou le mot de passe de session et conservez-le en lieu sûr en vue de sa consultation lorsque nécessaire.
Symptôme
Lors de la restauration d'une machine virtuelle VMware, le message d'erreur suivant s'affiche :
Vous n'êtes pas autorisé à accéder à ce fichier. Pour plus d'informations, reportez-vous au journal de débogage de la restauration. Si nécessaire, contactez le support d'Arcserve.
Vous pouvez voir les entrées de journal suivantes dans les journaux de débogage de la restauration :
[VDDKLOG] CnxAuthdConnect: Returning false because SSL verification requested and target authd does not support SSL
[VDDKLOG] CnxConnectAuthd: Returning false because CnxAuthdConnect failed
[VDDKLOG] Cnx_Connect: Returning false because CnxConnectAuthd failed
[VDDKLOG] Cnx_Connect: Error message: SSL required
Solution
Cette erreur est due au fait que l'authentification SSL est désactivée sur l'hôte VMware ESX. Pour corriger cette erreur, utilisez l'une des méthodes suivantes :
config.defaults.security.host.ruissl
/etc/vmware/config
L'authentification SSL est activée.
Une erreur de connexion au serveur s'affiche lorsque vous parcourez les journaux.
Symptôme
L'erreur suivante s'affiche parfois lorsque vous parcourez les journaux d'activité à partir de l'agent ou de la console :
Impossible de se connecter au serveur arcservedocs.com.
Solution
Vous pouvez ignorer ce message.
Symptôme
Un nœud est sauvegardé dans un référentiel de données de serveur de points de récupération, répliqué vers un autre référentiel de données de serveur de points de récupération, puis le système crée une machine Virtual Standby avec la source de réplication. Après le déploiement du plan, vous pouvez reprendre le job Virtual Standby directement s'il existe une session antérieure de ce job. En revanche, après avoir soumis le job, le job Virtual Standby ne démarre pas.
Solution
Pour résoudre ce problème, commencez par effectuer une réplication manuelle : Cliquez avec le bouton droit de la souris sur le nœud, puis cliquez sur Répliquer maintenant. Une fois la réplication terminée, reprenez le job Virtual Standby.
Symptôme
Le job Virtual Standby échoue avec l'erreur suivante :
Impossible d'obtenir la signature du disque (la signature de disque est vide).
Solution
Dans Arcserve UDP version 6.0, la bibliothèque du kit de développement de disques virtuels (VDDK) VMware est mise à niveau de la version 5.5 vers la version 6.0. Dans la version 6 du VDDK, l'initialisation de la bibliothèque VDDK nécessite un nouveau champ nommé Empreinte numérique. L'appel à partir de la conversion VSB repose sur la version 5.0 d'Arcserve UDP, dans laquelle l'empreinte numérique est manquante. Cela entraîne l'échec de l'appel du convertisseur vers le moniteur.
Pour résoudre ce problème, mettez à jour le convertisseur vers Arcserve UDP version 6.0.
Symptôme
L'Agent Arcserve UDP (Windows) est sauvegardé dans le référentiel de données du serveur de points de récupération Arcserve UDP et ce dernier est mis à niveau vers Arcserve UDP 6.0. En outre, l'Agent Arcserve UDP (Windows) est sauvegardé dans un dossier partagé et l'agent est mis à niveau vers Arcserve UDP 6.0. Le job Virtual Standby (VSB) vers Hyper-V échoue et les messages d'erreur suivants s'affichent :
Cannot find dispatch method for {http://webservice.arcflash.com}IsVmFileExist.
ou
Cannot find dispatch method for {https://webservice.arcflash.com}IsVmFileExist.
Solution
Mettez à niveau l'agent Arcserve UDP vers Arcserve UDP 6.0 sur le serveur Hyper-V.
Ce problème peut également se produire lorsque les machines virtuelles démarrées contiennent des volumes en lecture seule. Pour corriger ce problème, configurez les volumes sur le disque pour les rendre accessibles en écriture.
Echec de l'obtention de certaines informations de point de récupération.
Ce comportement se produit lorsque vous effectuez une récupération V2P à l'aide du dernier cliché et lorsqu'un job de conversion pour le noeud ne s'est pas terminé après le redéploiement de la tâche Virtual Standby sur le noeud.
Solution
Solution
Effectuez la récupération V2P à l'aide de la récupération à chaud de l'agent Arcserve UDP.
Remarque : Cette restriction s'applique uniquement aux jobs Virtual Standby exécutés sur des serveurs Hyper-V.
Symptôme
Agent Arcserve UDP (Windows) est équipé d'un disque de 2 To, or les serveurs ESX/ESX(i) d'une version inférieure à la version 5.5 peuvent uniquement prendre en charge un disque virtuel de 2 To maximum. Toutefois, pendant la conversion, les erreurs suivantes peuvent se produire :
Solution
Il s'agit d'une restriction de VMware. La taille maximum que les serveurs VMware ESX/ESX(i) d'une version inférieure à la version 5.5 prennent en charge est de 2 To-16 Go, soit 2032 Go.
Nous vous recommandons d'utiliser un serveur VMware ESX(i) 5.5 comme destination lorsque vous effectuez une conversion avec un disque de grande taille.
Pour plus d'informations, consultez l'article de connaissances 1012384 de VMware.
Symptôme
Le déploiement du plan échoue et le message d'erreur suivant s'affiche : Impossible d'appliquer les paramètres Virtual Standby au noeud xxx (Echec de la connexion de xxx au moniteur xxx. Informations d'identification de l'utilisateur non valides).
Solution
Modifiez la tâche Virtual Standby dans le plan, entrez le mot de passe approprié pour le moniteur et enregistrez le plan.
La génération de catalogue échoue pour une sauvegarde sans agent des machines virtuelles VMware
Symptôme
La présence d'un problème au niveau du cliché instantané de volume lié à VMware ou à Microsoft sur le système d'exploitation d'invité de la machine virtuelle peut entraîner un échec de la génération du catalogue pour la sauvegarde sans agent des machines virtuelles VMware avec le message suivant :
Impossible de mapper un bloc d'index vers le bloc de volume approprié. échec du mappage d'un bloc d'index vers le bloc de volumes correspondant.
Solution
Remarque : Ce problème survient rarement. Pour plus d'informations, consultez l'article de connaissances 2006849 de VMware ou l'article de connaissances 2853247 de Microsoft.
Les jobs de copie/d'archivage de fichiers ne sont pas lancés.
Symptôme
Les jobs de copie/d'archivage de fichiers ne sont pas lancés.
Solution
Dans quelques rares cas, le fichier utilisé pour indiquer un point de récupération doit être conservé pour le job de copie/d'archivage des fichiers et ne peut pas être supprimé une fois le job de copie/d'archivage des fichiers terminé. Ces fichiers portent l'extension *.alck dans le dossier de destination de sauvegarde d'un nœud spécifique et la taille du fichier est zéro. Pour corriger ce problème, recherchez ces fichiers et supprimez-les manuellement.
Symptôme
Le téléchargement des composants Arcserve Backup ou Arcserve High Availability à partir du programme d'installation unique (à l'aide du fichier exécutable ASDownloader.exe) échoue lorsque le volume de destination est le système de fichiers FAT32 parce que le package dépasse la limite de taille de fichier de 4 Go prise en charge par le système de fichiers FAT32.
Solution
Pour corriger ce problème, vous pouvez effectuer le téléchargement sur un volume NTFS.
A l'issue de la mise à niveau vers Arcserve UDP v6 sur l'appliance Arcserve UDP, l'option Réinitialiser les valeurs d'origine s'affiche dans l'onglet Paramètres de la console Arcserve UDP. Si vous cliquez sur Réinitialiser les valeurs d'origine pour réinitialiser les valeurs d'origine, puis sur Réinitialiser dans la boîte de dialogue Confirmer la réinitialisation des valeurs d'origine, le message d'erreur suivant s'affiche :
La réinitialisation des valeurs d'origine de l'appliance échoue. Réinitialisez manuellement les valeurs d'origine de l'appliance à l'aide de la commande suivante : "powershell.exe .arcserve_factoryreset.ps1 –perserve_data –auto_reboot " dans cmd sous C:\Program Files\Arcserve\Unified Data Protection\Management\Appliance.
Remarque : Le message d'erreur est incorrect. Si vous mettez à niveau l'appliance vers la version v6 d'UDP, la réinitialisation des valeurs d'origine n'est pas prise en charge, car il n'existe aucune partition de récupération Arcserve UDP sur l'ordinateur de l'appliance.
Le point de récupération de la machine virtuelle instantanée Linux n'est pas pris en charge sur l'appliance si vous utilisez le serveur de sauvegarde Linux sur l'appliance.
Symptôme
Le job de création d'une machine virtuelle instantanée Linux échoue et le message d'erreur suivant s'affiche :
Echec de l'obtention de l'adresse IP de la machine virtuelle $nom_machine_virtuelle Vérifiez que la machine virtuelle et le serveur de sauvegarde se trouvent sur le même réseau.
Solution
Cet échec est lié à la machine virtuelle de secours créée lors du job de création d'une machine virtuelle instantané. Celle-ci tente, en effet, de se connecter au serveur de sauvegarde Linux via Appliance_hostname:8014, alors que vous avez utilisé la valeur Appliance_hostname:8018 pour ajouter le serveur de sauvegarde Linux à la console. Le job de machine virtuelle instantanée échoue, étant donné que sur l'ordinateur de l'appliance, le port 8014 est contrôlé par le service de l'agent Windows UDP.
Une solution est disponible pour résoudre le job de machine virtuelle instantanée Linux avec l'adresse IP statique.
Suivez ces étapes:
Vous pouvez utiliser la commande suivante pour vérifier si le port est occupé : netstat-aon|findstr "port"
Remarque : Si vous mettez à niveau Arcserve UDP v6, le port 8018 sur l'ordinateur de l'appliance UDP est configuré pour rediriger vers le port 8014 du serveur de sauvegarde Linux. Utilisez la commande suivante pour libérer le port 8018 sur l'ordinateur de l'appliance UDP :
netsh interface portproxy delete v4tov4 listenport=8018
Remarque : Si le fichier n'existe pas, créez-le. Pour redémarrer le serveur de sauvegarde Linux, exécutez la commande suivante :
/opt/Arcserve/d2dserver/bin/d2dserver restart
#iptables -A INPUT -p tcp --dport 8018 -j ACCEPT
#iptables -A INPUT -p tcp --dport 8035 -j ACCEPT
#/etc/init.d/iptables save
netsh interface portproxy add v4tov4 listenport=8018 connectaddress=192.168.10.2 connectport=8018 protocol=tcp
netsh interface portproxy add v4tov4 listenport=8035 connectaddress=192.168.10.2 connectport=8035 protocol=tcp
C:\Program Files\Arcserve\Unified Data Protection\Engine\BIN\Appliance
netsh interface portproxy add v4tov4 listenport=8018 connectaddress=$VMIp connectport=8018 protocol=tcp
netsh interface portproxy add v4tov4 listenport=8035 connectaddress=$VMIp connectport=8035 protocol=tcp
Important : La solution ne s'applique pas aux options suivantes :
Copyright © 2015 Arcserve. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.