Fonctions | Documentation | Base de connaissances | Communautés

Data Recovery | 10 Juin 2010 | Build 260251
Dernière mise à jour du document : 10 Juin 2010
Recherchez fréquemment les ajouts et mises à jour de ces notes.

Ce document est composé des sections suivantes :

Fonctionnalités et avantages

Découvrez les avantages et les fonctionnalités de ce produit à l'aide du lien suivant Présentation de VMware Data Recovery - VMware. Pour plus d'informations sur les problèmes connus et les problèmes résolus, consultez :

Mise à niveau vers Data Recovery 1.2

Les installations antérieures de Data Recovery peuvent comporter des points de restauration qui doivent être conservés. Pour assurer la conservation de ces points de restauration, il convient d'utiliser les procédures suivantes décrites dans cette section.

Commencez le processus de mise à niveau en installant le plug-in Data Recovery le plus récent pour le client vSphere.

Pour installer le plug-in Data Recovery le plus récent

  1. Fermez le client vSphere.
  2. A l'aide de l'option Ajout/Suppression de programmes du Panneau de configuration, désinstallez toutes versions antérieures du plug-in VMware Data Recovery.
  3. Démarrez le fichier d'installation Windows (.msi) le plus récent du plug-in Data Recovery pour installer celui-ci.

Vous devez ensuite déployer le nouveau dispositif Data Recovery sans supprimer les points de restauration existants. Si le volume de destination du magasin de déduplication est un disque virtuel, ne supprimez pas le dispositif. Le fait de supprimer ce dispositif a pour effet de supprimer les disques qui y sont connectés. Ceci entraînerait la suppression des données de sauvegarde stockées dans le magasin de déduplication. Pour éviter ce problème, exécutez la procédure suivante :

Pour mettre à niveau des dispositifs Data Recovery avec des disques virtuels ou des RDM

  1. IMPORTANT : Avant d'effectuer la mise à niveau vers VMware Data Recovery 1.2, n'arrêtez les dispositifs que si toutes les opérations dans l'environnement 1.1 en cours sont terminées. Si une opération de contrôle d'intégrité ou de récupération est en cours, attendez la fin de l'opération. N'ANNULEZ PAS ces opérations.
  2. Lorsque aucune opération n'est en cours, démontez le disque de destination et arrêtez le dispositif Data Recovery
  3. Si vous voulez sauvegarder le dispositif Data Recovery d'origine, renommez-le. Vous pourriez, par exemple, renommer VMware Data Recovery - OLD un dispositif intitulé VMware Data Recovery.
  4. Déployez le nouveau dispositif.
  5. Utilisez le navigateur de la banque de données pour déplacer le disque contenant le magasin de déduplication vers le même emplacement que le nouveau dispositif.
  6. Modifiez les paramètres du nouveau dispositif :
    1. Sélectionnez Ajouter > Disque dur.
    2. Sélectionnez Utiliser un disque virtuel existant
    3. Accédez à la banque de données et sélectionnez comme destination le disque virtuel connecté à l'ancien dispositif.
    4. Sélectionnez l'adresse SCSI.
    5. Sélectionnez Terminer.
  7. Mettez le nouveau dispositif sous tension.
  8. Modifiez les paramètres de l'ancien dispositif :
    1. Sélectionnez le disque dur utilisé pour stocker le magasin de déduplication.
    2. Sélectionnez Supprimer, laissez l'option par défaut pour supprimer des données de la machine virtuelle. NE PAS sélectionner Supprimer de machine virtuelle et supprimer les fichiers sur le disque.
    3. Cliquer sur OK.
  9. Configurez la mise en réseau sur le nouveau dispositif.
  10. Utilisez le plug-in Data Recovery vSphere pour vous connecter au dispositif de sauvegarde.
  11. Terminez l'assistant de Démarrage. Remarque : vous devez installer le disque souhaité, mais ne le formatez pas. Le formatage du disque effacera toutes les données du magasin de déduplication. Il se peut que le disque à utiliser n'affiche pas le nom prévu, mais le nom correct s'affichera lorsque l'assistant sera terminé.
  12. Vous êtes invités à restaurer la configuration à partir du magasin de déduplication. Sélectionnez Oui si vous voulez restaurer les tâches et sauvegarder les événements et l'historique.
  13. Le client se déconnecte du dispositif une fois la configuration restaurée, puis rétablit la connexion. Cette opération peut prendre quelques minutes.
  14. Lorsque le client se reconnecte, déterminez si une opération de récupération sur le contrôle d'intégrité a démarré. Si tel est le cas, ARRETEZ-LA.
  15. Cliquez immédiatement sur Configurer > Destinations et exécutez un contrôle d'intégrité sur toutes les destinations montées.
  16. Vérifiez la configuration de la tâche de sauvegarde.
  17. Retirez l'ancien dispositif VMware Data Recovery de l'inventaire.

Notez que des points de restauration endommagés peuvent entraîner l'échec de la mise à niveau. Si le message "Impossible de restaurer la configuration du dispositif Data Recovery" s'affiche, rajoutez la destination au dispositif Data Recovery d'origine, puis effectuez un contrôle d'intégrité pour nettoyer les points de restauration endommagés. Une fois le contrôle d'intégrité terminé avec succès, effectuez à nouveau la procédure de mise à niveau.

Si les volumes de destination du magasin de déduplication sont un partage CIFS ou un RDM, exécutez la procédure suivante :

Pour mettre à niveau des dispositifs Data Recovery avec des partages CIFS

  1. IMPORTANT : Avant d'effectuer la mise à niveau vers VMware Data Recovery 1.2, n'arrêtez les dispositifs que si toutes les opérations dans l'environnement 1.1 en cours sont terminées. Si une opération de contrôle d'intégrité ou de récupération est en cours, attendez la fin de l'opération. N'ANNULEZ PAS ces opérations.
  2. Lorsque aucune opération n'est en cours, démontez le disque de destination et arrêtez le dispositif Data Recovery
  3. Si vous voulez sauvegarder le dispositif Data Recovery d'origine, renommez-le. Vous pourriez, par exemple, renommer VMware Data Recovery - OLD un dispositif intitulé VMware Data Recovery.
  4. Supprimez l'ancien dispositif Data Recovery.
  5. Déployez le nouveau dispositif.
  6. Mettez le nouveau dispositif sous tension.
  7. Configurez la mise en réseau sur le nouveau dispositif.
  8. Utilisez le plug-in Data Recovery vSphere pour vous connecter au dispositif de sauvegarde.
  9. Terminez l'assistant de Démarrage. Dans la page Destination de sauvegarde, cliquez sur le lien d' ajout d'un partage réseau et entrez les informations du partage CIFS.
  10. Vous êtes invités à restaurer la configuration à partir du magasin de déduplication. Sélectionnez Oui si vous voulez restaurer les tâches et sauvegarder les événements et l'historique.
  11. Le client se déconnecte du dispositif une fois la configuration restaurée, puis rétablit la connexion. Cette opération peut prendre quelques minutes.
  12. Lorsque le client se reconnecte, déterminez si une opération de récupération sur le contrôle d'intégrité a démarré. Si tel est le cas, ARRETEZ-LA.
  13. Cliquez immédiatement sur Configurer > Destinations et exécutez un contrôle d'intégrité sur toutes les destinations montées.
  14. Vérifiez la configuration de la tâche de sauvegarde.
  15. Retirez l'ancien dispositif VMware Data Recovery de l'inventaire.

Notez que des points de restauration endommagés peuvent entraîner l'échec de la mise à niveau. Si le message "Impossible de restaurer la configuration du dispositif Data Recovery" s'affiche, rajoutez la destination au dispositif Data Recovery d'origine, puis effectuez un contrôle d'intégrité pour nettoyer les points de restauration endommagés. Une fois le contrôle d'intégrité terminé avec succès, effectuez à nouveau la procédure de mise à niveau.

Améliorations

Les améliorations suivantes sont été apportées à cette version de Data Recovery.

  • La restauration au niveau fichier (FLR, File Level Restore) est désormais disponible pour utilisation avec Linux.
  • Chaque instance de vCenter Server prend en charge jusqu'à dix dispositifs de sauvegarde Data Recovery.
  • Le plug-in vSphere Client prend en charge une commutation rapide entre les dispositifs de sauvegarde Data Recovery.
  • Améliorations diverses apportées à l'interface utilisateur du plug-in vSphere Client, notamment :
    • La possibilité de nommer les tâches de sauvegarde durant leur création.
    • Des informations supplémentaires portant sur le statut actuel des disques de destination, notamment l'état du disque et le gain de place réalisé grâce aux optimisations du magasin de déduplication.
    • Des informations sur la banque de données à partir de laquelle les disques virtuels sont sauvegardés.

Problèmes résolus

Les problèmes suivants ont été résolus depuis la dernière version de Data Recovery. La liste des problèmes résolus ci-dessous ne concerne que cette version de Data Recovery.

  • Une activité DRS ou vMotion importante sur les machines virtuelles protégées entraîne une utilisation anormalement élevée du CPU.

    Lorsque le dispositif de sauvegarde protégeait des machines virtuelles qui étaient sensiblement affectées par vMotion ou DRS, un nombre inutilement élevé d'objets Data Recovery apparaissait en mémoire, entraînant une utilisation importante du CPU. Ceci était dû au fait que Data Recovery interprétait le résultat des opérations vMotion ou DRS comme une augmentation du nombre d'objets, et non comme un déplacement d'objets. Ce problème a été maintenant résolu.

  • Si vCenter Server devient indisponible, Data Recovery perd définitivement la connexion

    Si un vCenter Server était redémarré ou perdait la connexion réseau pendant que Data Recovery effectuait des sauvegardes, Data Recovery ne parvenait pas à rétablir la connexion avec le vCenter Server tant que les tâches de sauvegarde en cours n'étaient pas terminées. Ceci entraînait l'échec de toutes nouvelles opérations de sauvegarde et le plug-in vSphere Client ne pouvait pas se connecter au moteur pendant ce temps. Data Recovery essaie désormais de se reconnecter au vCenter Server à intervalles réguliers. Ceci se produit alors que des sauvegardes sont en cours d'exécution, minimisant ainsi les risques d'échec.

  • Les sauvegardes Data Recovery peuvent sembler ne pas avancer au début de la tâche

    Lors de la sauvegarde incrémentielle d'une machine virtuelle, Data Recovery ne parvenait pas à progresser et le dispositif de sauvegarde indiquait une utilisation maximale du CPU (100 %). Cette condition persistait jusqu'au redémarrage du dispositif. Même après avoir redémarré le dispositif de sauvegarde, la sauvegarde incrémentielle ne progressait pas. Ceci était dû à la manière dont le dispositif de sauvegarde utilisait les informations concernant la dernière sauvegarde pour créer une nouvelle sauvegarde.

  • Le dispositif de sauvegarde ne fonctionne plus lors de la sauvegarde de certaines configurations de disques

    Les machines virtuelles peuvent comporter des disques qui ne sont pas des multiples d'un nombre unique de mégaoctets Il est possible, par exemple, de créer un disque de 100,5 Mo. Normalement, les disques créés à l'aide de vSphere Client sont toujours un multiple d'un Mo. Certaines machines virtuelles comportant des disques dont la taille n'était pas un multiple de 1 Mo provoquaient le plantage du dispositif de sauvegarde. Ces tailles de disque sont désormais bien gérées.

  • Data Recovery ne suit pas correctement des disques individuels pour la sauvegarde

    Data Recovery prend en charge la sauvegarde d'un sous-ensemble de disques d'une machine virtuelle. Compte tenu de la façon dont des disques individuels sont suivis pour la sauvegarde, des problèmes se produisaient si un snapshot modifiait le nom du disque. Dans ce cas, Data Recovery n'associait pas le disque avec celui sélectionné dans la tâche de sauvegarde ; il indiquait le disque comme étant sélectionné et ne le sauvegardait pas. Ce problème ne se produit plus.

  • Data Recovery ne parvient pas à vérifier la compatibilité d'ajout d'un disque à chaud et à faire le ménage après des défaillances

    Data Recovery tente d'ajouter à chaud les disques de la machine virtuelle en cours de sauvegarde au dispositif de sauvegarde. Il pouvait arriver que la taille du bloc de la banque de données hébergeant les disques clients était supérieure à celle du dispositif. Dans ce cas et si la taille du disque de la machine virtuelle était supérieure à celle prise en charge par le dispositif, l'ajout à chaud échouait. Ce problème pouvait se produire après l'ajout à chaud réussi de certains disques. Dans ce cas, Data Recovery ne supprimait pas à chaud les disques de la machine virtuelle ajoutés correctement. Data recovery vérifie désormais la taille des blocs de la banque de données et la taille des disques pour s'assurer que les opérations d'ajout à chaud se termineront correctement avant de tenter l'ajout à chaud.

  • Data Recovery ne prend pas en charge des mots de passe CIFS plus longs

    Data Recovery 1.1 ne prenait pas en charge les mots de passe CIFS de plus de 16 caractères. Avec cette version, VDR prend en charge les mots de passe CIFS pouvant comporter jusqu'à 64 caractères.

  • Le dispositif de sauvegarde plante si les disques sont pleins

    Dans certains cas, Data Recovery plantait si les disques de destination atteignaient leur capacité maximum pendant la sauvegarde. Ceci ne se produit plus.

  • La dernière exécution indique un horodatage incorrect pour les tâches terminées

    L'onglet Sauvegarde affiche des informations sur les sauvegarde, y compris la dernière fois que chaque tâche de sauvegarde a été terminée. La date et l'heure affichées de la dernière exécution des tâches étaient incorrectes. Ceci a été corrigé.

  • Le plug-in vSphere Client de Data Recovery ne parvenait pas à se connecter au serveur vCenter Server

    Les tentatives de connexion du plug-in vSphere Client au dispositif de sauvegarde échouaient si l'inventaire de vSphere Server contenait un nombre élevé de machines virtuelles. Ceci se produisait généralement si l'inventaire comportait plus de 1000 machines virtuelles. Ce problème a été corrigé.

  • L'ajout de disques virtuels génère des problèmes avec les snapshots et les sauvegardes suivantes

    Si une machine virtuelle possédait un snapshot existant et que l'on ajoutait un nouveau disque virtuel à la machine virtuelle, la sauvegarde suivante réussissait, mais le snapshot était perdu. Ce snapshot entraînait l'échec des sauvegardes suivantes. Ce problème a été résolu.

  • Les sauvegardes ne se terminaient pas comme prévu

    Dans certaines situations, les sauvegardes ne se terminaient pas comme prévu, et aucune sauvegarde ne se produisait par la suite. Ce problème a été résolu.

  • L'assistant de restauration ne prend pas en compte les sélections de banques de données valides

    A l'aide de l'assistant de restauration, il était possible de spécifier des emplacements de banques de données vers lesquels restaurer des machines virtuelles dont la banque de données n'était pas valide. Lorsque, par exemple, :

    • Une banque de données était renommée ou supprimée, les anciennes informations étaient conservées, de sorte qu'un nom périmé ou une banque inexistante pouvait être sélectionnée.
    • Une machine virtuelle devait être restaurée vers un cluster, les banques de données qui n'étaient pas en stockage partagé pouvaient être sélectionnées.

    Les assistants ont été modifiés de sorte que seules des sélections valides sont proposées.

  • La restauration au niveau fichier (FLR, File Level Restore) ne sait pas traiter certains caractères des mots de passe en mode Admin

    FLR en mode admin échouait si le mot de passe contenait le caractère '/'. Ceci se produisait parce que FLR utilisait le caractère '/' comme séparateur. De ce fait les mots de passe comportant le caractère '/' entraînaient l'envoi de mots de passe incomplets au serveur vCenter Server pour authentification. FLR traite désormais correctement le caractère '/' dans les mots de passe.

  • FLR ne parvient pas à installer des disques virtuels du fait d'un séparateur de connexion

    Dans certains cas, le montage d'un disque virtuel à travers le client FLR échouait du fait de la présence d'un séparateur de connexion. Ceci a été corrigé.

  • Le FLR de Windows ne parvient pas à monter plusieurs disques portant le même nom

    Il est possible de sauvegarder une machine virtuelle comportant plusieurs disques ayant le même nom. Dans ce cas, chaque disque est associé à un vmdk situé dans une banque de données différente. Lorsqu'on essayait de monter ces disques par le client FLR Windows, un seul des disques virtuels était monté. Ce problème a été résolu et tous les disques seront désormais montés.

Problèmes connus

Les problèmes connus suivants ont été découverts grâce à des tests rigoureux. La liste des problèmes ci-dessous ne concerne que cette version de Data Recovery.

  • Le dispositif de sauvegarde OVF File Publisher ne présente aucun certificat

    Le fichier OVF contenant le dispositif de sauvegarde ne possède pas d'informations sur l'éditeur du dispositif ou sur le certificat de l'éditeur. Cette absence d'éditeur est visible sur les détails du modèle OVF qui apparaît lors du déploiement du dispositif de sauvegarde.

  • La taille du disque de provisionnement léger du dispositif de sauvegarde n'est pas spécifiée

    Les versions récentes de l'assistant de déploiement OVF affichent des informations supplémentaires qui ne l'étaient pas dans les versions antérieures. Dans la page Format du disque de l'assistant Déployer modèle OVF, il existe une option permettant de stocker le dispositif dans un format de provisionnement léger. La taille du disque de provisionnement léger du dispositif de sauvegarde OVF n'est pas définie pour ce modèle de dispositif de sauvegarde, mais ce format peut quand même être utilisé sans affecter la fonctionnalité du dispositif.

  • Les serveurs ESX sur lesquels VMware HA est activé peuvent lister deux fois les banques de données

    Lors de la restauration de machines virtuelles sur des serveurs ESX, sur lesquels VMware HA est activé, l'emplacement de restauration dans l'assistant de restauration peut afficher deux fois le même nom de banque de données. Les serveurs ESX peuvent être configurés pour utiliser le stockage partagé et le stockage local. Il est possible que plusieurs serveurs utilisent le même stockage partagé, et il est possible que les noms de stockage local soient identiques entre serveurs. Par exemple, plusieurs serveurs pourraient pointer sur "SharedStorage1" et plusieurs serveurs pourraient avoir chacun un stockage local appelé "DataStore1". Ceci est particulièrement problématique si des utilisateurs sélectionnent des emplacements pour des fichiers disques et des fichiers de configuration sur des serveurs distincts, entraînant ainsi une configuration non valide. Le risque d'erreur configuration n'est pas évident au départ si l'on se base sur les noms de destinations de stockage, mais une erreur permet d'identifier un tel problème. Si une telle erreur se produit, sélectionnez différentes combinaisons de destinations de stockage jusqu'à ce que vous trouviez un couple cohérent.

  • Les tâches de sauvegarde importées sauvegardent tous les disques

    Il est possible de créer des tâches qui sauvegardent un sous-ensemble de tous les disques dans une machine virtuelle source. Si une telle tâche de sauvegarde est importée dans Data Recovery 1.2, son comportement change de sorte que tous les disques sont sauvegardés. Pour résoudre ce problème, modifiez les tâches de sauvegarde et restaurez leurs paramètres d'origine.

  • Il arrive que l'onglet Restaurer n'affiche pas les dernières mises à jour des points de restauration

    Après l'exécution des tâches de restauration, les points de restauration résultant ne sont parfois pas mis à jour dans l'onglet Restaurer. Pour résoudre ce problème, déconnectez puis reconnectez le plug-in vSphere Client de Data Recovery en cliquant sur Déconnecter puis sur Connecter. Les points de restauration sont maintenant visibles dans l'onglet Restaurer.

  • Les tâches de sauvegarde exécutées en mode silencieux ne démarrent pas si vCenter Server est indisponible

    Si vCenter Server n'est pas disponible au démarrage du dispositif de sauvegarde, les tâches de sauvegarde risquent de ne pas démarrer comme prévu et aucun avertissement n'apparaît. Les sauvegardes démarrées manuellement en cliquant sur Sauvegarder maintenant sont exécutées normalement. Pour résoudre ce problème, redémarrez le dispositif de sauvegarde.

  • Les Commentaires du magasin de déduplication ne s'affichent pas au départ

    Les informations dans le champ Commentaires du magasin de déduplication ne sont pas toujours affichées. Pour vérifier les informations de commentaires, cliquez sur le champ, ce qui a pour effet de mettre à jour le contenu du champ.

  • Limitations de Data Recovery lors de la restauration de machines virtuelles avec les RDM en mode Compatibilité physique

    Un RDM en mode Compatibilité physique ne peut pas être protégé par Data Recovery, mais d'autres composants de la machine virtuelle peuvent être sauvegardés et restaurés. Ces composants sont notamment la configuration, les VMDK et RDM en mode Compatibilité virtuelle. Une opération de restauration qui écrase ces composants pris en charge sur la machine virtuelle source se terminera normalement. Par contre, une opération de restauration qui crée une nouvelle machine virtuelle ou remplace une machine virtuelle supprimée échouera si la machine virtuelle qui était sauvegardée contenait un RDM en mode Compatibilité physique. Ceci est vrai même si le RDM en mode Compatibilité physique ne faisait pas partie de la tâche de sauvegarde.

  • La documentation indique de manière erronée la prise en charge de SUSE

    Le Guide d'Administration de VMware Data Recovery indique que FLR prend en charge SUSE Linux Enterprise Server 11.2. SUSE n'est pas pris en charge par cette version.

  • FLR ne peut pas monter les volumes LVM qui ne font pas partie d'un groupe de volumes

    FLR ne peut pas monter des volumes LVM (Logical Volume Manager) dans des points de restauration si ces volumes LVM ne font pas partie d'un groupe de volumes. Pour que FLR puisse monter des volumes LVM sur un point de restauration, ceux-ci doivent avoir été ajoutés à un groupe de volumes existant ou utilisés pour créer un nouveau groupe de volumes avant la création de la sauvegarde.

  • Les échecs de montage de volumes LVM par FLR peuvent se traduire par le fait que l'interface utilisateur Redhat affiche de manière erronée que les disques système ne sont pas initialisés

    Si FLR ne parvient pas à monter un disque LVM, l'interface utilisateur du gestionnaire LVM de Redhat peut afficher de manière erronée que les disques système ne sont pas initialisés. Ne tentez pas de résoudre ce problème en initialisant ces volumes. L'initialisation de ces volumes supprime toutes les données. Les volumes sont parfaitement fonctionnels et peuvent être utilisés normalement dans la machine virtuelle. Pour résoudre ce problème dans l'outil Redhat, redémarrez la machine virtuelle ou tapez la commande vgmknodes <nomgroupevolume>.

  • SELinux empêche l'exécution de vdrFileRestore

    SELinux empêche le chargement par vdrFileRestore de la bibliothèque requise libvmacore.so.1.0. Pour résoudre ce problème, utilisez l'une des trois solutions suivantes :

    • Exécutez la commande chcon -t textrel_shlib_t /usr/lib/vmware/vmacore/libvmacore.so.1.0
    • Modifiez la politique de SELinux en "permissive"
    • Désactivez SELinux
  • Linux FLR peut avoir besoin de périphériques en boucle supplémentaires

    Linux FLR utilise un périphérique en boucle pour chaque fichier vmdk dans un point de restauration et pour chaque volume LVM physique détecté. La plupart des systèmes sont configurés pour avoir 8 périphériques en boucle. FLR n'est pas en mesure d'accéder à des points de restauration supplémentaires en l'absence de périphériques en boucle libres pour recevoir des fichiers vmdk et des volumes LVM physiques supplémentaires. Augmentez le nombre de périphériques en boucle disponibles pour réduire le risque d'une telle restriction. La procédure spécifique permettant de modifier le nombre de périphériques en boucle disponibles varie selon les systèmes d'exploitation. Par exemple, sur certains systèmes Redhat, ajoutez la ligne suivante au fichier modprobe.conf :

    options loop max_loop=64

    Après avoir redémarré le système, 64 périphériques en boucle sont disponibles.

  • FLR (File Level Restore) indique que certaines données de registre ont peut-être été perdues

    Data Recovery peut créer des points de restauration pour des machines virtuelles mal configurées. File Level Restore peut monter ces points de restauration, mais ceci peut entraîner l'affichage de messages d'erreur de registre. L'erreur peut se présenter de la façon suivante : Registry hive (fichier) : C:\DOCUME~1\ADMINI~1\LOCALS~1|Temps\Administrator\vixmntapi3 était endommagé et a été récupéré. Quelques données peuvent avoir été perdues. Vous pouvez ignorer ces erreurs.

  • Des verrouillages caduques du magasin de déduplication empêchent l'accès de FLR

    Si FLR ne parvient pas à monter un point de restauration et que la sortie est en mode prolixe (-v ou --verbose) affiche une erreur 1315 dans le journal, ce défaut peut être dû à un verrouillage caduque sur la déduplication. Le manque d'informations sur le problème qui empêche le montage peut prêter à confusion. L'erreur 1315 peut être attribuée à d'autres causes, mais elle indique généralement un verrouillage du magasin de déduplication.

    Dans des conditions normales, attendez que les processus de Data Recovery se terminent, après quoi le verrouillage du magasin de déduplication sera automatiquement supprimé. Si le verrouillage est caduque et n'est pas supprimé normalement, ce problème peut être résolu en supprimant le verrouillage manuellement. Pour supprimer le verrouillage, supprimez le fichier verrouillage suivant du magasin de déduplication :

     

    /<dedupe root>/VMwareDataRecovery/BackupStore/store.lck
                    
  • Les disques source peuvent apparaître désélectionnés pour la sauvegarde

    Les sources sélectionnées pour la sauvegarde peuvent sembler désélectionnées. Cette situation se produit lorsque des disques sont dissociés de la machine virtuelle d'une manière cosmétique et temporaire. Elle n'affecte pas la sauvegarde. Toutes les sources déjà sélectionnées continuent d'être sauvegardées correctement. Après une sauvegarde, les sources apparaissent de nouveau sélectionnées. Pour résoudre ce problème cosmétique, développez le noeud de la machine virtuelle dans l'arborescence de l'inventaire ou dans l'arborescence de sélection des sources dans l'assistant de sauvegarde. Le disque de la machine virtuelle réapparaît au bout d'une minute et les sources apparaissent de nouveau sélectionnées.

  • La sauvegarde d'une machine virtuelle en utilisant plusieurs dispositifs de sauvegarde génère des erreurs

    Data Recovery permet de gérer plusieurs dispositifs de sauvegarde avec une seule instance vCenter Server. Dans ce cas, un seul dispositif de sauvegarde doit être configuré pour sauvegarder une machine virtuelle. Les administrateurs doivent vérifier qu'aucune machine virtuelle n'est sauvegardée par plusieurs dispositifs de sauvegarde. Si plusieurs dispositifs de sauvegarde sont configurés pour sauvegarder une seule machine virtuelle, un comportement indésirable peut apparaître (création de snapshot et erreurs de suppression, par exemple).

Récupération de démontages Busy Linux FLR

Il est possible que Linux FLR s'arrête de manière imprévue, ou ne parvienne pas à terminer toutes les tâches incluses dans un arrêt. Si cela se produit, une trace de FLR peut subsister sur la machine virtuelle Linux sur laquelle il exécutait. Il n'a pas été démontré que ce type de situation pouvait entraîner des problèmes au niveau du système ; elle peut cependant laisser quelques périphériques en boucle, dossiers, fichiers et processus sur le système qui auraient été supprimés par un arrêt planifié de Linux FLR. Bien que ces ressources résiduelles aient généralement peu, voire aucune conséquence, sur le fonctionnement de la machine virtuelle Linux affectée, vous pouvez choisir de les supprimer.

La raison la plus fréquente de l'échec de la fermeture normale de Linux FLR réside dans le fait que l'un des "montages" est en cours d'utilisation. Par exemple, l'échec de démontage normal d'un montage peut générer le message suivant :

        Restore point has been mounted...     /EG VC Server/EG Datacenter/host/example-esx.eng.example.com/Resources/Red Hat 5.4 Two LVM Groups"         root mount point -> "/root/2010-02-19-22.12.10"

Please input "unmount" to terminate application and remove mount point unmount USER PID ACCESS COMMAND /root/2010-02-19-22.12.10/Mount1: root 4137 ..c.. bash
Busy mounts detected, unmount aborted. Please unbusy mounts per list above.
Note, future unmounts can be forced by using "force" as input but will cause unclean unmounts which may require you to manually clean up.
Restore point has been mounted... "/EG VC Server/EG Datacenter/host/example-esx.eng.example.com/Resources/Red Hat 5.4 Two LVM Groups" root mount point -> "/root/2010-02-19-22.12.10"
Please input "unmount" to terminate application and remove mount point

Dans ce cas, il est possible de fermer proprement Linux FLR en commençant par mettre fin à l'utilisation du montage, puis en exécutant une commande unmount. Sinon, le démontage peut être terminé en utilisant une commande forcée. L'utilisation d'une commande forcée génère un enregistrement du type suivant :

    Please input "unmount" to terminate application and remove mount point     force     Removed "/root/2010-02-19-22.12.10/Mount2"     Removed "/root/2010-02-19-22.12.10/Mount3"     Removed "/root/2010-02-19-22.12.10/Mount1"     Removed "/root/2010-02-19-22.12.10"     umount: /tmp/vmware-root/8027465182774010399_1: device is busy     umount: /tmp/vmware-root/8027465182774010399_1: device is busy     umount: /tmp/vmware-root/8027465182774010399_1: device is busy     umount: /tmp/vmware-root/8027465182774010399_1: device is busy     terminate called after throwing an instance of 'std::exception'         what():  St9exception     Aborted     
              

Certains processus de fermeture de Linux FLR ont été terminés normalement, mais pas tous. FLR a bien supprimé le point de montage racine, qui se trouvait dans /root/, ainsi que les enfants de ce point de montage. Linux FLR n'a pas réussi à supprimer /tmp/vmware-root/8027465182774010399_1 , comme indiqué dans le journal. Ce point de montage continue à assurer le service des montages.

Par exemple, il est encore possible de lister et de copier des fichiers depuis ce chemin comme l'illustre l'exemple suivant :

    [root@office ~]# ll /tmp/vmware-root/8027465182774010399_1     -rw-r--r-- 1 root root   68663 Aug 18  2009 config-2.6.18-164.el5     drwxr-xr-x 2 root root    1024 Dec 17 06:00 grub     -rw------- 1 root root 3307695 Dec 17 06:10 initrd-2.6.18-164.el5.img     drwx------ 2 root root   12288 Dec 17 05:43 lost+found     -rw-r--r-- 1 root root  107405 Aug 18  2009 symvers-2.6.18-164.el5.gz     -rw-r--r-- 1 root root  954947 Aug 18  2009 System.map-2.6.18-164.el5     -rw-r--r-- 1 root root 1855956 Aug 18  2009 vmlinuz-2.6.18-164.el5     
              

Etant donné que ce point de montage fonctionne encore, les ressources suivantes doivent être disponibles et actives :

  • Montage par fusion des partitions
  • Périphérique en boucle servant le montage local du fichier plat vmdk fusible
  • Copie du traitement des E/S du moteur FLR de et vers le montage
  • Refaire les journaux

Pour appréhender ces ressources restantes, plusieurs étapes doivent être terminées, notamment :

  • Démontage de la partition montée par fusion
  • Suppression du montage caduque
  • Fin de tous les processus vdrFileRestore en cours d'exécution (commande Kill)
  • Suppression de tous les journaux de reprise révolus restants

Nettoyage après un démontage de busy Linux FLR

  1. Trouver les points de montage restants Vous pouvez, par exemple, le faire à l'aide de la commande llet recevoir une réponse du genre :
        [root@office ~]# ll /root/2010-02-19-22.12.10/     drwxr-xr-x 3 root root 1024 Feb 2 13:17 Mount2     drwxr-xr-x 25 root root 4096 Feb 19 22:06 Mount3
                    
  2. Suppression des points de montage trouvés Lors de la suppression de points de montage, vous ne devez pas vous trouver dans un des répertoires montés avec une fenêtre de terminal, sinon les commandes échoueront. Cette commande se présenterait sous une forme de ce type :
  3.     [root@office ~]# umount /root/2010-02-19-22.12.10/Mount2     [root@office ~]# umount /root/2010-02-19-22.12.10/Mount3     
                    
  4. Suppression du montage racine FLR et de ses enfants. Cette commande se présenterait sous une forme de ce type :
        [root@office ~]# rm -rf /root/2010-02-19-22.12.10/
                    
  5. Désactivation des groupes Linux FLR LVM.

    Remarque : si aucun groupe de volumes FLR n'est affiché, vous pouvez sauter toutes les étapes associées à LVM. N'oubliez pas que les groupes FLR LVM sont identifiés par leur nom unique. Ne désactivez que les groupes de volumes FLR. Ne désactivez pas les groupes de volumes système. Notez que les groupes FLR sont ceux dont les noms contiennent "FLR".

    • Émettez la commande lvm vgdisplay. Exemple d'utilisation de cette commande :
    •      [root@office ~]# lvm vgdisplay      --- Volume group ---      VG Name EG_TEST       --- Volume group ---      VG Name EG_TEST-flr-4030-rG64au       --- Volume group ---      VG Name VolGroup00       --- Volume group ---      VG Name VolGroup00-flr-4030-7Ms42G         
                        
    • Émettez la commande vgchange. Exemple d'utilisation de cette commande :
    •        [root@office ~]# vgchange -a n VolGroup00-flr-4030-7Ms42G EG_TEST-flr-4030-rG64au      0 logical volume(s) in volume group "VolGroup00-flr-4030-7Ms42G" now active      0 logical volume(s) in volume group "EG_TEST-flr-4030-rG64au" now active         
                        
    • Identifiez tous les périphériques en boucle, y compris ceux utilisés par les groupes de volumes Linux FLR LVM à l'aide de la commande lvm pvscan . Exemple d'utilisation de cette commande :
    •      [root@office ~]# lvm pvscan      PV /dev/sdc1 VG EG_TEST lvm2 [1020.00 MB / 520.00 MB free]      PV /dev/loop3 VG EG_TEST-flr-4030-rG64au lvm2 [1020.00 MB / 520.00 MB free]      PV /dev/sda2 VG VolGroup00 lvm2 [7.88 GB / 0 free]      PV /dev/sdb1 VG VolGroup00 lvm2 [992.00 MB / 992.00 MB free]      PV /dev/loop1 VG VolGroup00-flr-4030-7Ms42G lvm2 [7.88 GB / 0 free]      PV /dev/loop2 VG VolGroup00-flr-4030-7Ms42G lvm2 [992.00 MB / 992.00 MB free]      Total: 6 [19.68 GB] / in use: 6 [19.68 GB] / in no VG: 0 [0 ] 
                        
  6. Supprimez les périphériques en boucle qu'utilise Linux FLR à l'aide de la commande losetup . Dans l'exemple précédent, /dev/loop1 , /dev/loop2 et /dev/loop3 sont utilisés par les groupes de volumes FLR LVM. Par conséquent, pour supprimer les périphériques en boucle dans l'exemple précédent, la commande serait la suivante :
        [root@office ~]# losetup -d /dev/loop1     [root@office ~]# losetup -d /dev/loop2     [root@office ~]# losetup -d /dev/loop3
                    
  7. Suppression de tous les montages par fusion. Cette commande prendrait la forme suivante :
        [root@office ~]# fusermount -u -z /tmp/vmware-<user name|root>/<fuse mount object>      [root@office ~]# rm -rf /tmp/vmware-<user name|root>/<fuse mount object> 
                    
  8. Remarque vmware-<user name|root>est un espace réservé pour l'emplacement où le fusible a monté le volume. Notez aussi que <fuse mount object>est un espace réservé pour chaque élément trouvé dans ce répertoire.

  9. Suppression de tous les journaux caduques. Cette commande prendrait la forme suivante :
        [root@office ~]# rm -rf /tmp/flr*
                    
  10. Fin des processus FLR à l'aide d'une commande telle que :
        [root@office ~]# killall *drFileRestore