Récupérer à partir d'un système de fichiers corrompu lorsque fsck n'aide pas

Quelque chose s'est mal passé avec mon système de fichiers, Ubuntu l'a mis en lecture seule et maintenant sous Ubuntu Live Disc, fsck ne peut pas le réparer.

J'utilise 13.04 et il ne démarre pas - au démarrage, il montre simplement l'invite de sauvetage de grub.

C'est une configuration simple, juste un disque dur sur / dev / sda1 mais il ne sera même pas monté.

Le programme d'installation peut voir la partition, que c'est ext4 et que c'est la partition de démarrage.

Cependant, il semble que je ne puisse pas sauver le système de fichiers en faisant une installation Ubuntu avec le disque live Ubuntu car cela ne donne aucune indication s'il est sur le point d'écraser tout le lot, donc je ne veux pas le risquer.

J'ai une sauvegarde en utilisant backuppc mais stupidement j'ai perdu mes disques de secours. Je préfère éviter une installation complète suivie d'une restauration que je n'ai aucune expérience de l'exécution.

Le nœud du problème est que fsck dit qu'il corrige tout mais ne le fait pas, donc la prochaine fois que je l'exécute, j'obtiens exactement les mêmes messages d'erreur et correctifs.

Voici la sortie:

ubuntu@ubuntu:~$ sudo fsck.ext4 -vy /dev/sda1
e2fsck 1.42.8 (20-Jun-2013)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
Block bitmap for group 0 is not in group.  (block 2553887680)
Relocate? yes

Inode table for group 0 is not in group.  (block 2440124416)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate? yes

One or more block group descriptor checksums are invalid.  Fix? yes

Group descriptor 0 checksum is 0x761e, should be 0xcf25.  FIXED.
Block bitmap for group 4352 is not in group.  (block 2553887680)
Relocate? yes

Inode table for group 4352 is not in group.  (block 3731970048)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate? yes

Group descriptor 4352 checksum is 0x5eda, should be 0x3da3.  FIXED.
Inode bitmap for group 4353 is not in group.  (block 2785042439)
Relocate? yes

Group descriptor 4353 checksum is 0xd8b1, should be 0xedfb.  FIXED.
Inode bitmap for group 4354 is not in group.  (block 838860807)
Relocate? yes

Group descriptor 4354 checksum is 0x1718, should be 0x0438.  FIXED.
Inode bitmap for group 4355 is not in group.  (block 771751943)
Relocate? yes

Group descriptor 4355 checksum is 0x0bc8, should be 0x4170.  FIXED.
fsck.ext4: e2fsck_read_bitmaps: illegal bitmap block(s) for /dev/sda1

/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sda1: ********** WARNING: Filesystem still has errors **********

ubuntu@ubuntu:~$

C'est exactement la même chose que c'était 10 fois plus tôt et je suis sûr que les dix prochaines fois je l'essayerai - exactement les mêmes sommes de contrôle et identifiants de bloc. Toute aide reçue avec plaisir!

Merci.

EDIT: en gros, je suppose que la question est: ce système de fichiers est-il réparable sur place maintenant ou est-ce que les informations de fsck signifient que mon disque est mort? Et s'il n'est pas mort, que puis-je faire au-delà de ce que j'ai fait avec fsck?

EDIT: utilisé tune2fs pour identifier les superblocs et exécuté e2fsck -b 01234 / dev / sda1 comme alternative à fsck ... aucun effet.

EDIT: essayer testdisk qui me dit que la partition est mauvaise. ... OK testdisk ne semble pas offrir grand-chose.

filesystem ext4 fsck

— Adam
source

essayez help.ubuntu.com/community/FilesystemTroubleshooting

— Avinash Raj

n'ai-je pas essentiellement couvert les éléments de ce lien avec fsck.ext4 -vy / dev / sda1? La seule différence est le drapeau '-p' et avec cela il me dit de le faire manuellement - c'est-à-dire ce que j'ai coupé et collé ci-dessus.

— Adam

Réponses:

Enfin trouvé ce lien où le type de système de fichiers ext4 obtient un dénigrement, mais après avoir donné tous les conseils que j'avais déjà essayés, il dit enfin:

sudo mkfs.ext4 -S /dev/sda1
Cela remplacera tous vos superblocs par des données correctes, en supposant que la taille du bloc est devinée correctement (la valeur par défaut est correcte pour la plupart des systèmes.) Si vous devez l'utiliser, veuillez d'abord lire la page de manuel sur -S. Ne me blâmez pas!

mais seulement si vous vous sentez chanceux.

Il a corrigé la partition pour que je puisse la relire. Cependant, j'ai dû exécuter fsckpour corriger les erreurs qui étaient toujours là, et qui ont vidé le contenu de / etc et beaucoup d'autres choses dans / lost + found, donc je vais devoir faire une réinstallation et une restauration à partir de sauvegarde pour le redémarrer.

— Adam
source

Merci, intéressant. J'ai eu le problème avec une partition racine ext2 à laquelle j'ai renoncé. J'ai testé la commande et cela a "fonctionné" (j'ai spécifié la taille du bloc), mais la partition a quand même été impossible à démarrer après que fsck ait dû réparer de nombreux secteurs. Maintenant, je me demande ce qui serait arrivé avec unix.stackexchange.com/a/193778/59808 .

— Nemo

Premièrement: si vous avez des données importantes sur ce disque, ce serait le bon moment (en fait un mauvais moment) pour faire une sauvegarde. Voir Récupération de données: imagerie d'un périphérique, d'un système de fichiers ou d'un lecteur endommagé . Peut-être que votre disque dur est en train de mourir.

Deuxièmement: Regardez ceci: Comment puis-je réparer le montage de mon lecteur de données après un crash?

Troisièmement: Vérifiez votre disque dur à l'aide de Smartmontools et éventuellement de badblocks: sudo badblocks -vsn /dev/sda(Cela peut prendre un certain temps, ne le faites pas si vous avez un ssd)

— intérieur et
source

Merci pour l'édition! C'est drôle de regarder une réponse champignon comme ça. La réponse à laquelle vous faites référence concerne les nombres magiques, et ce n'est pas ce que je vois - en fait, c'est l'une des nombreuses réponses sur askubuntu que j'ai déjà examinées. J'essaierai également la voie de récupération de données alors que je n'ai pas d'autres solutions. Ran le test court smartmontools et il n'a trouvé aucune erreur.

— Adam

Désolé pour la modification. Parce que les systèmes de fichiers modernes comme ext4 sont difficiles à casser, je pense toujours d'abord à un défaut matériel. Lorsque smart dit que le disque est ok, ce n'est pas vraiment nécessaire. Pourquoi votre FS est-il corrompu? Si je où vous et fsck ne pouvez pas réparer le fs je ferais une installation propre. Serait probablement plus facile que d'essayer de corriger le fs manuellement.

— innerand

OK pas de soucis, merci juste d'avoir répondu! Je n'étais pas sarcastique. Je vous suis complètement sur ce que vous dites. Je dois juste remettre mon système en marche dès que possible. Au pire, il faudra 3 jours pour obtenir un nouveau disque dur, alors j'aimerais trouver une solution «sans nouveau matériel» pour cela.

— Adam

selon le lien dans la réponse que j'ai donnée ci-dessous, apparemment ext4 n'est pas si difficile à briser. mais peu importe.

— Adam

Hôte virtuel avec 9 fenêtres et 1 Ubuntu. L'hôte est descendu en emportant les 10 avec. Quand il était de retour, tout Windows avait démarré. La machine Linux affichait "INCONSISTANCE INATTENDUE" et fsck manuel requis. Je n'ai jamais vu autant de correctifs iNode [depuis Solaris dans les années 90]. Ce n'était pas du matériel, c'était simplement une panne de courant. Je n'ai jamais pensé voir le jour où NTFS aurait pwned EXT4.

— Brain2000