Lecteur NTFS endommagé après une suppression non sécurisée de Windows 7

Tout d’abord, quelques informations sur le disque - il s’agit d’un disque dur portable USB 2.0 (PQI H560), une partition couvrant l’ensemble des 640 Go, NTFS. Utilisé presque exclusivement sous Linux (arch et ubuntu), mais initialement formaté sous Windows 7.

Le disque dur contient de nombreux liens physiques, car il s’agissait d’un système de sauvegarde de type timemachine.

Et maintenant, le problème lui-même:

Aujourd'hui, j'ai commis l'erreur de sortir mon disque dur portable de mon système Linux et de le brancher sur une machine Windows 7. Tout a bien fonctionné, j'ai pris un film du lecteur et il est resté en veille pendant environ une heure. Après cela, j'ai sorti le lecteur (j'ai oublié de démonter: /) et je l'ai remis dans mon Linux.

Malheureusement, j'ai eu l'erreur suivante:

[49162.611858] mount.ntfs[15397]: segfault at 7fff19cb1fe8 ip 00007f9fca88de4e sp 00007fff19cb1fa0 error 6 in libntfs-3g.so.79.0.0[7f9fca87f000+42000]

Ok, le support de Linux NTFS n’est pas très bon, alors je suis retourné sous Windows pour faire un scandisk ou quelque chose du genre. Ouai, bien sur:

You need to format the disk in drive F: before you can use it.

Do you want to format it?

Non, je ne.

Cliquez avec le bouton droit de la souris -> Outils -> Vérifier maintenant (c'est chkdsk, non?):

The disk check could not be performed because Windows can't access the disk.

Retour à la familière Linux, fdisk -ltrouve le système de fichiers NTFS, mais j'ai un peu peur de faire un fsckou ntfsfix.

Comme je l'ai dit, la prise en charge de Linux NTFS est bonne et fait défaut. Peut-être essayerons-nous de copier une ddpartition sur un autre lecteur et d’ essayer sur ce disque, mais pour l’instant je n’ai pas le matériel pour cela.

Avez-vous une idée de la raison pour laquelle ça s'est cassé si mal? Je pensais que NTFS était assez durable.

Des astuces sur les utilitaires de récupération de données seraient formidables. Idéal s'il y a quelque chose de non destructif (pouvoir obtenir les données tout en préservant chaque bit du disque dans son état actuel - juste pour être sûr qu'il ne casse rien)

Le retrait dangereux du lecteur a été votre perte.

Vous devrez soit exécuter la récupération de données pour extraire les fichiers, formater le lecteur et tout restaurer, ou le risquer avec l'un des outils Linux.

En outre, Windows 7. Il n'y a rien de mal à Windows 7. Vous avez effectué une suppression non sécurisée, ce n'est donc pas la faute de Windows.

Eh bien ... Avant de lancer tout outil, je vous recommande de créer une image ... et si vous ne possédez pas le matériel nécessaire pour une image directe vers le haut, essayez de la transférer dans lzma et de la compresser autant que vous le pouvez:

dd if=/dev/sdb bs=512k |lzma -7 -c - >ntfs.img.lzma

Vous pouvez remplacer sdb par n'importe quoi ... si cela semble condescendant, c'était involontaire. À en juger par votre courrier, vous connaissez l’essentiel de dd. Si vous êtes impatient comme moi, vous devriez le diriger vers pv et obtenir une barre de progression:

dd if=/dev/sdb bs=512k |pv |lzma -7 -c - >ntfs.img.lzma

Je mets seulement le niveau de compression de lzma à 7 car 9 peut prendre une éternité sur un processeur plus lent. Une fois que cela est fait, je recommande testdisk et son application soeur Photorec. Testdisk est capable de réparer le système de fichiers dans une certaine mesure ... Je ne l'ai pas beaucoup utilisé moi-même, mais je connais des gens qui en raffolent. Photorec est un dernier effort pour récupérer tous les fichiers individuels. Il recherche les points de début et de fin des données logiques de type de fichier connus. Cependant, même si cela prend beaucoup de temps, vous devriez d’abord essayer ntfsfix. Si cela détruit complètement quelque chose, alors tirez simplement de votre image:

unlzma -c ntfs.img.lzma |pv |dd of=/dev/sdb bs=512k

Et, juste quelques réflexions rapides sur ce qui a mal tourné, je leur ai dit de ne pas en blâmer aucun des deux systèmes d’exploitation, ils ont tous deux joué le même rôle pour l’endommager. Il était sale à cause de l'extraction Windows sale et en essayant le montage compatible ntfs-3g en écriture, il était encore plus endommagé au point que Windows ne l'aime plus. Cela va sembler un peu étrange, mais regardez dans une configuration de noyau, et le support en écriture ntfs est toujours qualifié d'expérimental et de À vos risques et périls. Autant que je déteste Windows, je ne peux pas le blâmer cette fois-ci. Quelque chose de bizarre avec ntfs: umount malpropre de windows est réparable depuis windows, umount malpropre de linux est réparable depuis linux. Franchir la ligne avec une partition ntfs malpropre le tuera généralement ... simplement, une de ces choses.

La solution à ce problème était Restorer Ultimate. Mis à part quelques gros fichiers (2 Go +), des journaux et des problèmes liés à certains liens physiques (traités comme des doublons), cela a résolu le problème.

En outre, plus je cherchais dans le journal, plus il semblait que MFT n'était pas le problème, pas la racine de MFT au moins. Certains éléments dupliqués, mais pas égaux, semblent indiquer que le lecteur a échoué en copie fantôme, et peut-être y avait-il des boucles ou une structure vraiment défectueuse dans la partie la plus profonde de MFT. En regardant à travers les journaux, il semble que toutes les implémentations os ont échoué de manière fatale, je veux dire par segfaulting. Un journal intéressant de MacOS X:

Interval Since Last Panic Report:  472 sec
Panics Since Last Report:          2
Anonymous UUID:                    D89B5624-FF95-48B5-8F55-0987EA2D2466

Sun Jun 26 18:02:46 2011
panic(cpu 0 caller 0x6e085e4a): "ntfs_map_runlist_nolock(): Called for $MFT/$DATA!\n"@/SourceCache/ntfs/ntfs-65.5/kext/ntfs_attr.c:245
Backtrace (CPU 0), Frame : Return Address (4 potential args on stack)
 ...
  Kernel Extensions in backtrace (with dependencies):
     com.apple.filesystems.ntfs(3.4)@0x6e05a000->0x6e0b9fff

BSD process name corresponding to current thread: mount_ntfs

Et puis c'est mort.

Donc, il semble que j'ai eu un problème très rare causé par la paresse. Pour référence future: la meilleure solution consiste à faire ce que vous devriez, à savoir démonter le lecteur. Peut-être aussi désactiver le cliché instantané sur un lecteur externe.

Quoi qu'il en soit, le restaurateur a corrigé le problème, et à propos de son échec, il semble que Windows ait en quelque sorte contribué à laisser une partition dans un état où un système de journalisation ne devrait pas être installé. ne réparez pas les choses sans demander, d'habitude il n'est pas en mesure de faire appel à l'attention de l'utilisateur dans syslog pour cela.