none
CLUSTEURS INCORRECTS RRS feed

  • Question

  • Bonjour à tous,
    Nous rencontrons un problème sur notre serveur interne depuis plusieurs mois et nous n'arrivons pas à trouver de solution.
    Dans une VM nommée "SERVEUR", nous n'arrivons pas à copier certains fichiers et donc plus de sauvegardes complètes non plus.

    L'hyperviseur à 45 Go de libre. Non n'arrivons pas à effectuer réparer l'erreur pour aune cause d'un soi-disant manque d'espace disque libre. Pour infos, nous avions le même message au début des problème quant nous n'avions que 1 ou 2 Go de libre.
    Voici le rapport complet du checkdisk exécuté depuis l'hyperviseur:

    Vérification du système de fichiers sur C:
    Le type du système de fichiers est NTFS.

    Une vérification de disque a été planifiée.
    Windows va maintenant vérifier le disque.

    Étape 1 : Examen de la structure du système de fichiers de base...
    Nettoyage en cours des balises d’instance pour le fichier 0x2921a.
    Nettoyage en cours des balises d’instance pour le fichier 0x29369.
    442624 enregistrements de fichier traités. La vérification des fichiers est terminée.
    8867 enregistrements de grand fichier traités. 0 enregistrements de fichier incorrect traités.
    Étape 2 : Examen de la liaison des noms de fichiers...
    529722 entrées d’index traitées. La vérification des index est terminée.
    0 fichiers non indexés analysés. 0 fichiers non indéxés récupérés.
    Étape 3 : Examen des descripteurs de sécurité...
    Nettoyage en cours de 41 entrées d’index inutilisées à partir de l’index $SII
    du fichier 0x9.
    Nettoyage en cours de 41 entrées d’index inutilisées à partir de l’index $SDH
    du fichier 0x9.
    Nettoyage en cours de 41 descripteurs de sécurité non utilisés.
    La vérification des descripteurs de sécurité est terminée.
    43550 fichiers de données traités. CHKDSK vérifie le journal USN...
    Vérification du journal USN terminée.

    Étape 4 : Recherche de clusters incorrects dans les données des fichiers utilisateur...
    Échec de lecture avec l’état 0xc0000010 au décalage 0x1e792c8000 pour 0x10000 octets.
    Erreur lecture disquec0000010
    Espace disque insuffisant pour remplacer les clusters endommagés
    détectés dans le fichier 40729 nommé \HYPER-V\SRV_SI\SERVEUR.VHDX.
    442608 fichiers traités. La vérification des données du fichier est terminée.


    Étape 5 : Recherche de clusters libres incorrects...
    11985395 clusters libres traités. La vérification de l’espace libre est terminée.
    CHKDSK a découvert de l’espace libre marqué alloué dans la bitmap du volume.

    Windows a effectué des corrections sur le système de fichiers.
    Aucune autre action n’est requise.

    285310975 Ko d’espace disque au total.
    236570088 Ko dans 286121 fichiers.
    279320 Ko dans 43551 index.
    0 Ko dans des secteurs défectueux.
    519987 Ko utilisés par le système.
    65536 Ko occupés par le fichier journal.
    47941580 Ko disponibles sur le disque.

    4096 octets dans chaque unité d’allocation.
    71327743 unités d’allocation au total sur le disque.
    11985395 unités d’allocation disponibles sur le disque.

    Informations internes :
    00 c1 06 00 d4 07 05 00 c3 31 0a 00 00 00 00 00 .........1......
    a6 00 00 00 6d 00 00 00 00 00 00 00 00 00 00 00 ....m...........

    Windows a terminé la vérification de votre disque.
    Veuillez patienter pendant le redémarrage de votre ordinateur.

    Dans le doute, nous avons essayé de faire un checkdisk depuis la VM mais pas mieux.

    On pense à remplacer le serveur mais on arrive pas non plus à copier la VM vers un autre support local, réseau ou Cloud.

    Je fais donc appel à votre matière grise ​​
    D'avance merci pour votre aide.
    mardi 8 décembre 2020 14:53

Toutes les réponses

  • Bonjour SIBQ

    Il semblerait qu'il y ait quelques secteurs disques défaillant sur ton serveur et cela touche un ou plusieurs fichiers et, pas de bol, parmi ces fichiers, il y en a un qui correspond à un fichier de VM avec les pb qui vont avec je présume.

    Le checkdisk de la VM n'apporterait rien de plus, ce ne sont pas les fichiers dans le fichier qui ont un pb, mais le fichier de la VM lui même à cause du disque sous-jacent.

    Je présume que le fichier de la VM que tu as essayé de copier avec un résultat négatif, tu as bien tenté une copie avec la VM arrêtée (fichier fermé donc, sinon le fichier devrait avoir un lock exclusif de l'hyperviseur dessus) ? Sinon, mauvaise pioche réessaye VM arrêtée. Si c'est ce que tu as fais, il est possible que les secteurs disques soient tellement endommagés que tu ne peux même plus accéder au fichier pour le copier/coller ailleurs.

    Pour qu'un checkdisk puisse effectivement corriger certains pbs, il doit être lancé au démarrage de l'OS afin que le minimum de fichiers soient déjà accédés et en lock exclusif. Je disais donc :

    • Arrêtes Ta ou tes VMs
    • Modifies les paramètres de ton hyperviseur afin que la ou les VMs ne démarre pas automatiquement au boot de l'hyperviseur (ou passe tout simplement le service Hyper-V sur stop et pas en d"marrage auto)
    • Lances un checkdisk pour qu'il fasse son check et répare au boot (comme tu l'as probablement fait)
    • Reboot ton host.
    • Le checkdisk va s'exécuter et il ne devrait pas y avoir de blocs secteur disk qui correspondent à un fichier verrouillé qu'il ne puisse pas réparer.

    Attention, pour qu'un checkdisk puisse réparer les erreurs sur un disque, il doit y avoir suffisamment de place pour faire. En fait, s'il ne peut réparer les erreurs sur les blocs secteurs, il copie les données (si elles sont encore accessibles en lecture, sinon c'est perdu) sur d'autres blocs secteurs et déclare dans la table d'allocation du disque ces secteurs comme "Ne pas utiliser" (ca serait ballot que le système aillent écrire de nouveau sur ces blocs par la suite, n'est-ce pas ?). Et pour copier (déplacer), il faut de la place ... et en nombre suffisant dépendant du nombre (et donc de la taille) total de secteurs disques défaillants. Au final, la taille disponible sur le disque s'en trouvera réduite (peu visible si peu de blocs secteurs HS, visible si nombreux).

    Il faut utiliser quelques outils tiers pour avoir un diagnostic plus précis sur le nombre de blocs secteurs défaillants. Après avoir réparé, si le hardware tient encore la route, un changement des disques seul est envisageable plutôt que balancer tout le serveur à la benne. Et si tu ne changes que le ou les disques, le DAF (directeur financier) ou ton chef direct  te donnera probablement une tape dans le dos en te disant "bon boulot mon garçon", mais n'attends pas trop de prime ;-)

    Si les disques sont derrière une carte RAID, ça facilite l'opération. On fait cela disque après disque (lhyperviseur ne voit que des Logical Disks) tranquillement en laissant la carte RAID faire son boulot pendant la reconstruction du RAID et à chaud en plus.

    Si pas de carte RAID, je dirais : sauvegarde ailleurs de otut ce qui est important (registre de l'hyperviseur), fichiers de VM, reconstruction from scratch (sur de nouveau disques bien sur), et réintégraiton des éléments sauvegardés.

    Mais bon tu n'en est pas encore là, normalement la piste indiquée devrait résoudre ton pb avec le checkdisk ... enfin j'espère pour toi (moi je ne serais alors QUE dans l'erreur).

    Cordialement

    Olivier

    mardi 8 décembre 2020 21:00
  • Bonjour,

    Le HOST dois avoir assez d'espace pour faire fonctionner le tout (chkdsk etc...)

    Donc augmenter la taille du volume ou se trouve l’hyperviseur.

    Par la même occasion, augmenter la taille de l'espace de stockage si nécessaire.

    C'est très courant comme problème le sous dimensionnement d'infra hyperv.

    Voila quelques pistes (classiques) pour optimiser l'espace sur le HOST hyperv :


    PAGE FILE HOST
    -Sur le HOST HYPERv il est recommandé de ne jamais laisser de PAGEFILE sur un support avec des VHD ou VHDX
    -Sur le HOST HYPERv il est recommandé de ne pas désactiver totalement la PAGEFILE.
    -Sur le HOST HYPERv il est recommandé de prendre en compte la taille du fichier PAGFILE sur le C lors de l’étude de dimensionnement.
    (apparemment pour "seulement" le role HYPERv avec 128Go de RAM, il faut compter 20 Go de taille PAGEFILE sur le C)

    -Déplacer le PAGEFILE sur un autre volume.  

    *.BIN files
    This file contains the memory of a virtual machine or snapshot that is in a saved state.
    Ce fichier se trouve dans le répertoire qui contient les :
    VIRTUAL HARD DISKS (VHDX)
    VIRTUAL MACHINES (*.BIN)

    Quand la VM s'allume ce fichier fait la même taille que la RAM dédié a la VM donc utiliser mois de RAM pour la VM (temporairement).

    *.AVHD & *.AVHDX

    These are the differencing disk files used for virtual machine snapshots is the differencing file that is created when you make a snap shot. When you delete the snap shot and power down the VM the files will merge after a minute or so. Depending on the size of the AVHD / AVHDX it may take a few minutes to merge together. (Lors des backups WBADMIN par exemple etc.)

    Quand la VM s'allume ce fichier fait la même taille que la RAM dédié à la VM donc utiliser mois de RAM pour la VM (temporairement).


    En complément :

    -Sur le HOST vous pouvez chercher de l'espace avec TREESIZE

    -Vider les VSS

    -Eteindre les VM sur le HOST et les déplacer (exporter)

    Une fois la place libéré lancer CHKDSK /f /r


    "Marquer comme réponse" les réponses qui ont résolu votre problème



    dimanche 13 décembre 2020 08:38
  • Bonjour SIBQ

    Si vous avez trouvé une solution à votre problème, merci de la partager avec la communauté TechNet ou "Marquer comme réponse" les réponses qui ont résolu votre problème.

    Je vous remercie par avance pour votre retour.

    Cordialement, 
    Nedeltcho

    Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    jeudi 31 décembre 2020 09:57