Réponse courte : $MFTMirr est un petit fichier contenant un duplicata des premiers enregistrements MFT — au minimum les enregistrements 0–3 ($MFT, $MFTMirr, $LogFile, $Volume), typiquement les 16 premiers. NTFS s'en sert pour amorcer la récupération quand la $MFT principale est illisible. Si la MFT principale et son miroir sont tous deux illisibles, vous voyez « Windows ne peut pas récupérer la master file table » sortir de chkdsk.
Pourquoi un miroir existe
Les premiers enregistrements de la Master File Table sont critiques : l'enregistrement 0 décrit $MFT elle-même, l'enregistrement 2 est $LogFile, l'enregistrement 3 est $Volume. Si les octets au début de $MFT sont endommagés, NTFS ne peut trouver aucun autre fichier du volume — y compris le journal de transactions qu'il utiliserait normalement pour récupérer.
Le miroir résout cette circularité. $MFTMirr est un fichier séparé à un emplacement physique différent, contenant un duplicata de ces premiers enregistrements. Quand le pilote monte un volume, il lit l'enregistrement 0 depuis $MFT ; en cas d'échec, il se rabat sur l'enregistrement 0 de $MFTMirr et utilise le duplicata pour relocaliser le reste.
Où il vit
$MFTMirr est l'enregistrement MFT 1. Son attribut $DATA est non résident, avec des cluster runs qui pointent traditionnellement vers le milieu du volume — assez loin de $MFT pour qu'une panne localisée (un cluster défectueux, une écriture interrompue sur une région) ne puisse les abattre tous les deux.
Les versions modernes de NTFS le placent au LCN nombreDeClusters / 2. Sur un volume de 500 Go, cela place le miroir autour de la marque des 250 Go.
Vous pouvez le localiser depuis un système vivant :
fsutil file queryextents C:\$MFTMirr
Ce qu'il contient
$MFTMirr stocke des copies octet pour octet des premiers enregistrements MFT. La garantie historique portait sur les quatre premiers enregistrements (0–3) ; les versions actuelles de Windows mettent en miroir les seize premiers — l'ensemble complet de métadonnées NTFS décrit dans la référence de la master file table.
Chaque copie est un enregistrement MFT normal, tableau fixup inclus. Un parseur pointé sur $MFTMirr le parcourt exactement comme il parcourt $MFT.
Comment NTFS s'en sert au montage
Sur un montage sain, le pilote ne touche pas $MFTMirr. Sur un montage endommagé :
- Lire l'enregistrement 0 de
$MFT. - Si la lecture retourne une erreur I/O ou si la vérification du fixup échoue, lire à la place l'enregistrement 0 de
$MFTMirr. - Si la copie de l'enregistrement 0 du miroir est valide, utiliser ses data runs pour localiser
$MFTsur le disque. - Continuer normalement.
Le miroir n'a pas à remplacer $MFT — il doit juste fournir assez d'informations pour la trouver. Une fois que le pilote a localisé $MFT depuis le pointeur du miroir, il poursuit avec la table vivante.
Comment chkdsk s'en sert
chkdsk est plus agressif. Quand il détecte une corruption dans les premiers enregistrements de $MFT, il croise chaque enregistrement avec le miroir. Si les deux copies sont valides et diffèrent, chkdsk traite le miroir comme faisant autorité pour les premiers enregistrements critiques (l'hypothèse étant que les enregistrements vivants ont été mis à jour plus récemment et corrompus pendant le processus).
Si $MFT est illisible et que le miroir est illisible, chkdsk signale Windows ne peut pas récupérer la master file table. CHKDSK abandonné. À ce stade, la récupération nécessite des outils hors ligne — typiquement le carving par signatures FILE à travers le volume brut — plutôt que la réparation interne de NTFS.
Pourquoi $MFTMirr n'est pas une sauvegarde complète
Il ne met en miroir que les fichiers de métadonnées. Les enregistrements 16 et au-delà — chaque fichier et dossier utilisateur — n'existent que dans $MFT. Si $MFT est endommagée au-delà de l'enregistrement 16, le miroir ne vous aide pas. Le miroir suffit à monter le volume ; récupérer des fichiers arbitraires après dégât nécessite les mêmes techniques que sans lui.
Intérêt forensique
$MFTMirr est rarement l'artefact principal d'un cas, mais il a deux usages :
- Vérification croisée. Les enregistrements 0–15 du miroir devraient correspondre bit pour bit aux enregistrements vivants. Une divergence suggère que l'un des côtés a été modifié hors bande (bogue de pilote, manipulation délibérée, récupération partielle).
- Instantané pré-corruption. Si les enregistrements
$MFTvivants ont été modifiés mais que le miroir n'a pas encore été flushé, le miroir contient l'état antérieur. Cette fenêtre est courte — NTFS les garde synchronisés — mais dans un cas de panne soudaine, ce peut être la seule copie propre restante.
Questions fréquentes
$MFTMirr est-il identique à une sauvegarde complète de la MFT ?
Non. Il ne contient que les premiers enregistrements (les fichiers de métadonnées système). Les fichiers utilisateur ne sont pas mis en miroir.
Puis-je analyser $MFTMirr avec les mêmes outils que $MFT ?
Oui. Il est structurellement identique — même format d'enregistrement, même tableau fixup, mêmes attributs. Déposez-le sur le parseur navigateur ou passez-le à MFTECmd.
Puis-je supprimer ou déplacer $MFTMirr ?
Non. Comme $MFT, il est verrouillé pendant l'exécution de Windows. Désactiver le miroir entièrement n'est pas une opération supportée ; chkdsk refuserait le volume.
Que se passe-t-il si mon disque n'a pas de $MFTMirr ?
Il en a un. Chaque volume NTFS en possède un, créé au formatage. Si $MFTMirr est manquant ou illisible, le volume est gravement endommagé et chkdsk échouera.