Pourquoi un disque virtuel à allocation dynamique occupe-t-il sa taille totale après la restauration d’une sauvegarde ?
Un disque virtuel dynamique devient entièrement alloué lorsque la restauration écrit les régions remplies de zéros sous forme de blocs réels ou recrée l’image dans un format épais.
Les images VHD, VHDX, raw et QCOW2 dynamiques peuvent signaler une grande capacité logique tout en n’occupant de l’espace de stockage que pour les régions allouées. Une sauvegarde peut préserver parfaitement le contenu des fichiers tout en perdant la cartographie des espaces creux, des clusters non alloués, l’état discard ou les métadonnées de provisionnement fin. Le système invité restauré peut démarrer normalement même si le fichier hôte occupe désormais toute sa taille virtuelle. Diagnostiquez le format et l’allocation avant de compacter ou de convertir l’unique copie restaurée.
Comparer la taille logique à la taille réellement allouée
Notez le format de l’image, sa taille virtuelle, la taille apparente du fichier, les blocs hôtes alloués, le système de fichiers de destination et indiquez si l’image restaurée est marquée comme dynamique ou préallouée.
Microsoft explique que les fichiers dynamiques renvoient des zéros pour les régions non allouées tout en conservant une taille nominale plus importante. La taille virtuelle et la consommation physique doivent donc être mesurées séparément.
Utilisez un outil tenant compte de l’allocation plutôt que de vous fier uniquement à un explorateur de fichiers. Si la taille virtuelle et la taille allouée sont désormais identiques, la restauration a probablement matérialisé les espaces creux ou sélectionné un format fixe.
Déterminer si la sauvegarde a préservé les espaces creux
Examinez les options de copie de fichiers, de copie par blocs, d’archivage, de compression et de gestion des fichiers dynamiques du travail de sauvegarde. Déterminez s’il a stocké les étendues allouées ou lu l’intégralité du disque logique comme un flux continu d’octets.
GNU Coreutils précise que les outils de copie doivent recréer les espaces creux à destination. Sinon, les longues séquences de zéros peuvent être écrites sous forme de blocs ordinaires alloués.
Une restauration dont le contenu est valide ne prouve pas que les métadonnées d’allocation ont été préservées. Comparez une petite image contenant des espaces creux connus en utilisant le même chemin de sauvegarde et de restauration.
Vérifier si la conversion de l’image a désactivé la gestion des espaces creux
Examinez chaque étape de conversion entre l’objet de sauvegarde et l’image restaurée. Notez le format d’entrée, le format de sortie, l’option de préallocation, le seuil de détection des espaces creux et l’utilisation éventuelle d’un déchargement de copie.
QEMU indique que la conversion avec qemu-img peut détecter les secteurs nuls et les supprimer, tandis qu’un seuil d’espaces creux nul ou un chemin de déchargement de copie non pris en charge peut produire une destination entièrement allouée.
Ne reconvertissez jamais une image lorsque sa machine virtuelle est en cours d’exécution. Travaillez sur une copie vérifiée et comparez le contenu des disques virtuels avant de remplacer l’image restaurée.
Vérifier que le système de fichiers de destination prend en charge les fichiers dynamiques
Vérifiez la prise en charge des fichiers dynamiques sur le système de fichiers du NAS de destination et sur chaque volume intermédiaire de préparation. Une restauration écrite d’abord sur un système de fichiers incompatible peut perdre ses espaces creux avant d’atteindre le stockage final.
L’allocation fine dépend des propriétés de provisionnement de l’objet de stockage ainsi que de sa taille logique. Une destination peut prendre en charge les fichiers volumineux tout en restaurant l’image sous forme d’objet entièrement alloué lorsque l’application de sauvegarde ne recrée pas les espaces creux.
Si le système de fichiers de préparation ou de destination ne peut pas préserver les espaces creux, le fichier peut devenir entièrement alloué avant d’atteindre le magasin de données final de la machine virtuelle. Testez d’abord la prise en charge des espaces creux avec une image jetable.
Distinguer un format de restauration épais de l’espace libre du système invité
Déterminez si le disque restauré est un disque raw préalloué, raw dynamique, VHD fixe, VHDX dynamique ou QCOW2. L’espace libre du système invité ne devient pas automatiquement un espace creux côté hôte.
Red Hat fait la distinction entre les disques virtuels préalloués et dynamiques : les disques préalloués réservent immédiatement la totalité de leur taille, tandis que les disques dynamiques allouent l’espace au fur et à mesure de l’écriture des données.
Si la cible de restauration était volontairement épaisse, l’allocation complète est attendue et ne constitue pas un signe de dommage. Décidez si le compromis entre performances et capacité justifie de la reconvertir dans un format fin.
Récupérer l’espace rempli de zéros avec une méthode hors ligne prise en charge
Arrêtez la machine virtuelle, confirmez l’existence d’une sauvegarde séparée et déterminez si les blocs supprimés du système invité ont été remplis de zéros ou libérés par discard. L’espace libre du système de fichiers invité peut encore contenir d’anciennes données non nulles.
Le flux de travail virt-sparsify de Red Hat convertit l’espace libre reconnu en régions dynamiques côté hôte et déconseille toute opération sur des images disque actives.
Effectuez la compaction uniquement sur une image dupliquée, vérifiez ensuite le système de fichiers invité et conservez l’image restaurée originale jusqu’à la réussite des tests au niveau des applications.
Vérifier le comportement de la préallocation et de la libération des espaces
Vérifiez si l’application de restauration a préalloué la destination pour des raisons de fiabilité ou de performances, et si la destination permet ensuite de libérer des plages.
L’interface fallocate de Linux distingue l’allocation de blocs réels de la libération d’espaces, ce qui montre pourquoi l’écriture de zéros et la désallocation d’espace sont deux opérations différentes.
Ne libérez pas directement des espaces dans un format de disque virtuel inconnu. Utilisez l’hyperviseur ou l’utilitaire d’image qui comprend ses métadonnées et la disposition de ses clusters.
Valider le disque restauré avant de le remplacer
Démarrez la copie compactée de manière isolée, vérifiez les systèmes de fichiers, les applications, les instantanés et l’espace libre invité, puis comparez les hachages de fichiers représentatifs ainsi que la structure signalée par le disque virtuel.
La liste de contrôle de récupération d’un serveur personnel de ZimaSpace fournit l’exigence complémentaire consistant à démontrer la récupération du stockage et des applications avant de supprimer la copie précédente.
Le problème est résolu lorsque le disque restauré conserve son format fin prévu, que l’espace hôte alloué reflète les données réelles du système invité et que la machine virtuelle réussit les vérifications de démarrage, de charge de travail, de sauvegarde et de restauration. Conservez l’image entièrement allouée si la conversion génère des erreurs ou si la plateforme exige un provisionnement épais.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
