Bonjour,
Les miracles ça arrive !
Une énorme partition en ext3 de mon disque dur était devenue subitement
inaccessible. Même e2fsck n'y comprenait rien.
J'ai réussi à tout récupérer mais je n'ai pas très bien compris ce qui
s'est vraiment passé.
...
Bon bref, le disque semblait bel et bien mort.
Un bienveillant contributeur à ce forum m'a indiqué une procédure pour
tenter de récupérer les données : recopier à grand coup de 'dd' sur un
autre disque dur, jeter un oeil sur les données avec 'debugfs' et
ensuite réparer les données sur le nouveau disque à l'aide de 'e2fsck'.
...
1) Comment fonctionne ce truc magique qu'est 'debugfs' ? comment a-t-il
pu lire et recopier les données alors que le montage était devenu
impossible et que même e2fsck ne comprenait rien à ma partition ?
2) Pourquoi ai-je réussi à copier les données avec 'debugfs' alors
qu'en recopiant comme un bourrin avec 'dd' j'ai des données endommagées
?
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck', l'ancien
disque dur semble nickel. Que s'est-il passé ? était-ce un problème de
surchauffe de disque (il était un peu coincé entre un lecteur de
disquette et un lecteur DVD) ? ou bien ce genre de plaisanterie peut
arriver aléatoirement ?
6) Est-ce que l'on peut activer des options pour améliorer la
robustesse du système de fichier sur le disque ? je vois pleins
d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas toujours
le sens...
Bonjour,
Les miracles ça arrive !
Une énorme partition en ext3 de mon disque dur était devenue subitement
inaccessible. Même e2fsck n'y comprenait rien.
J'ai réussi à tout récupérer mais je n'ai pas très bien compris ce qui
s'est vraiment passé.
...
Bon bref, le disque semblait bel et bien mort.
Un bienveillant contributeur à ce forum m'a indiqué une procédure pour
tenter de récupérer les données : recopier à grand coup de 'dd' sur un
autre disque dur, jeter un oeil sur les données avec 'debugfs' et
ensuite réparer les données sur le nouveau disque à l'aide de 'e2fsck'.
...
1) Comment fonctionne ce truc magique qu'est 'debugfs' ? comment a-t-il
pu lire et recopier les données alors que le montage était devenu
impossible et que même e2fsck ne comprenait rien à ma partition ?
2) Pourquoi ai-je réussi à copier les données avec 'debugfs' alors
qu'en recopiant comme un bourrin avec 'dd' j'ai des données endommagées
?
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck', l'ancien
disque dur semble nickel. Que s'est-il passé ? était-ce un problème de
surchauffe de disque (il était un peu coincé entre un lecteur de
disquette et un lecteur DVD) ? ou bien ce genre de plaisanterie peut
arriver aléatoirement ?
6) Est-ce que l'on peut activer des options pour améliorer la
robustesse du système de fichier sur le disque ? je vois pleins
d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas toujours
le sens...
Bonjour,
Les miracles ça arrive !
Une énorme partition en ext3 de mon disque dur était devenue subitement
inaccessible. Même e2fsck n'y comprenait rien.
J'ai réussi à tout récupérer mais je n'ai pas très bien compris ce qui
s'est vraiment passé.
...
Bon bref, le disque semblait bel et bien mort.
Un bienveillant contributeur à ce forum m'a indiqué une procédure pour
tenter de récupérer les données : recopier à grand coup de 'dd' sur un
autre disque dur, jeter un oeil sur les données avec 'debugfs' et
ensuite réparer les données sur le nouveau disque à l'aide de 'e2fsck'.
...
1) Comment fonctionne ce truc magique qu'est 'debugfs' ? comment a-t-il
pu lire et recopier les données alors que le montage était devenu
impossible et que même e2fsck ne comprenait rien à ma partition ?
2) Pourquoi ai-je réussi à copier les données avec 'debugfs' alors
qu'en recopiant comme un bourrin avec 'dd' j'ai des données endommagées
?
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck', l'ancien
disque dur semble nickel. Que s'est-il passé ? était-ce un problème de
surchauffe de disque (il était un peu coincé entre un lecteur de
disquette et un lecteur DVD) ? ou bien ce genre de plaisanterie peut
arriver aléatoirement ?
6) Est-ce que l'on peut activer des options pour améliorer la
robustesse du système de fichier sur le disque ? je vois pleins
d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas toujours
le sens...
2) Pourquoi ai-je réussi à copier les données avec 'debugfs' alors
qu'en recopiant comme un bourrin avec 'dd' j'ai des données
endommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck',
l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce un
problème de surchauffe de disque (il était un peu coincé entre un
lecteur de disquette et un lecteur DVD) ? ou bien ce genre de
plaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je m'apperçoive
que c'était le controleur IDE qui était en train de lacher...
Les disques se sont révélés être tous récupérables sur un autre
PC...
6) Est-ce que l'on peut activer des options pour améliorer la
robustesse du système de fichier sur le disque ? je vois pleins
d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas
toujours le sens...
Il y a déjà une très forte redondance des données, en interne
dans le disque, pour éviter ce genre de problèmes. De plus,
les badblocks sont en principe remappés à la volée au fur et à
mesure de leur apparition. En général, quand un disque moderne
présente des signes de faiblesses, c'est que le controleur interne
a déjà utilisé toutes les astuces pour éviter les pertes de données.
Le seul moyen pour augmenter encore la redondance des données
et donc augmenter la fiabilité, c'est de faire du RAID, je pense...
2) Pourquoi ai-je réussi à copier les données avec 'debugfs' alors
qu'en recopiant comme un bourrin avec 'dd' j'ai des données
endommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck',
l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce un
problème de surchauffe de disque (il était un peu coincé entre un
lecteur de disquette et un lecteur DVD) ? ou bien ce genre de
plaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je m'apperçoive
que c'était le controleur IDE qui était en train de lacher...
Les disques se sont révélés être tous récupérables sur un autre
PC...
6) Est-ce que l'on peut activer des options pour améliorer la
robustesse du système de fichier sur le disque ? je vois pleins
d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas
toujours le sens...
Il y a déjà une très forte redondance des données, en interne
dans le disque, pour éviter ce genre de problèmes. De plus,
les badblocks sont en principe remappés à la volée au fur et à
mesure de leur apparition. En général, quand un disque moderne
présente des signes de faiblesses, c'est que le controleur interne
a déjà utilisé toutes les astuces pour éviter les pertes de données.
Le seul moyen pour augmenter encore la redondance des données
et donc augmenter la fiabilité, c'est de faire du RAID, je pense...
2) Pourquoi ai-je réussi à copier les données avec 'debugfs' alors
qu'en recopiant comme un bourrin avec 'dd' j'ai des données
endommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck',
l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce un
problème de surchauffe de disque (il était un peu coincé entre un
lecteur de disquette et un lecteur DVD) ? ou bien ce genre de
plaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je m'apperçoive
que c'était le controleur IDE qui était en train de lacher...
Les disques se sont révélés être tous récupérables sur un autre
PC...
6) Est-ce que l'on peut activer des options pour améliorer la
robustesse du système de fichier sur le disque ? je vois pleins
d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas
toujours le sens...
Il y a déjà une très forte redondance des données, en interne
dans le disque, pour éviter ce genre de problèmes. De plus,
les badblocks sont en principe remappés à la volée au fur et à
mesure de leur apparition. En général, quand un disque moderne
présente des signes de faiblesses, c'est que le controleur interne
a déjà utilisé toutes les astuces pour éviter les pertes de données.
Le seul moyen pour augmenter encore la redondance des données
et donc augmenter la fiabilité, c'est de faire du RAID, je pense...
On Thu, 12 Feb 2004 09:35:58 +0100, no_spam2) Pourquoi ai-je réussi à copier les données avec 'debugfs' alors
qu'en recopiant comme un bourrin avec 'dd' j'ai des données
endommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
Justement ou bien les données sont endommagées et dans ce cas 'dd' et
'debugfs' ne peuvent pas recopier les données sur un autre disque
correctement, ou bien elles sont saines ?!?
Qu'est-ce que debugfs avait de si particulier pour réussir (haut la
main) à recopier des données que 'dd' n'arrive pas à lire ?
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck',
l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce un
problème de surchauffe de disque (il était un peu coincé entre un
lecteur de disquette et un lecteur DVD) ? ou bien ce genre de
plaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je m'apperçoive
que c'était le controleur IDE qui était en train de lacher...
Les disques se sont révélés être tous récupérables sur un autre
PC...
Euh... Est ce que c'est la récupération avec 'dd if=/dev/zero
of=/dev/<...>' qui engendre de toute façon une durée de vie assez faible
ou bien est-ce parce que j'ai commencé à avoir des badblocks ?
En gros est-ce que je peux garder mon disque (en faisant des sauvegardes
cette fois !) ? Ou bien existe-t-il des outils permettant de vérifier
l'état réel du disque pour me dire si je peux le garder ou non ?
6) Est-ce que l'on peut activer des options pour améliorer la
robustesse du système de fichier sur le disque ? je vois pleins
d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas
toujours le sens...
Il y a déjà une très forte redondance des données, en interne
dans le disque, pour éviter ce genre de problèmes. De plus,
les badblocks sont en principe remappés à la volée au fur et à
mesure de leur apparition. En général, quand un disque moderne
présente des signes de faiblesses, c'est que le controleur interne
a déjà utilisé toutes les astuces pour éviter les pertes de données.
Le seul moyen pour augmenter encore la redondance des données
et donc augmenter la fiabilité, c'est de faire du RAID, je pense...
Je viens de trouver l'option 'SMART monitoring' dans mon BIOS pour
apparemment améliorer la fiabilité des résultats... je ne sais pas du
tout ce que cela vaut...
On Thu, 12 Feb 2004 09:35:58 +0100, no_spam
2) Pourquoi ai-je réussi à copier les données avec 'debugfs' alors
qu'en recopiant comme un bourrin avec 'dd' j'ai des données
endommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
Justement ou bien les données sont endommagées et dans ce cas 'dd' et
'debugfs' ne peuvent pas recopier les données sur un autre disque
correctement, ou bien elles sont saines ?!?
Qu'est-ce que debugfs avait de si particulier pour réussir (haut la
main) à recopier des données que 'dd' n'arrive pas à lire ?
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck',
l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce un
problème de surchauffe de disque (il était un peu coincé entre un
lecteur de disquette et un lecteur DVD) ? ou bien ce genre de
plaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je m'apperçoive
que c'était le controleur IDE qui était en train de lacher...
Les disques se sont révélés être tous récupérables sur un autre
PC...
Euh... Est ce que c'est la récupération avec 'dd if=/dev/zero
of=/dev/<...>' qui engendre de toute façon une durée de vie assez faible
ou bien est-ce parce que j'ai commencé à avoir des badblocks ?
En gros est-ce que je peux garder mon disque (en faisant des sauvegardes
cette fois !) ? Ou bien existe-t-il des outils permettant de vérifier
l'état réel du disque pour me dire si je peux le garder ou non ?
6) Est-ce que l'on peut activer des options pour améliorer la
robustesse du système de fichier sur le disque ? je vois pleins
d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas
toujours le sens...
Il y a déjà une très forte redondance des données, en interne
dans le disque, pour éviter ce genre de problèmes. De plus,
les badblocks sont en principe remappés à la volée au fur et à
mesure de leur apparition. En général, quand un disque moderne
présente des signes de faiblesses, c'est que le controleur interne
a déjà utilisé toutes les astuces pour éviter les pertes de données.
Le seul moyen pour augmenter encore la redondance des données
et donc augmenter la fiabilité, c'est de faire du RAID, je pense...
Je viens de trouver l'option 'SMART monitoring' dans mon BIOS pour
apparemment améliorer la fiabilité des résultats... je ne sais pas du
tout ce que cela vaut...
On Thu, 12 Feb 2004 09:35:58 +0100, no_spam2) Pourquoi ai-je réussi à copier les données avec 'debugfs' alors
qu'en recopiant comme un bourrin avec 'dd' j'ai des données
endommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
Justement ou bien les données sont endommagées et dans ce cas 'dd' et
'debugfs' ne peuvent pas recopier les données sur un autre disque
correctement, ou bien elles sont saines ?!?
Qu'est-ce que debugfs avait de si particulier pour réussir (haut la
main) à recopier des données que 'dd' n'arrive pas à lire ?
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck',
l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce un
problème de surchauffe de disque (il était un peu coincé entre un
lecteur de disquette et un lecteur DVD) ? ou bien ce genre de
plaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je m'apperçoive
que c'était le controleur IDE qui était en train de lacher...
Les disques se sont révélés être tous récupérables sur un autre
PC...
Euh... Est ce que c'est la récupération avec 'dd if=/dev/zero
of=/dev/<...>' qui engendre de toute façon une durée de vie assez faible
ou bien est-ce parce que j'ai commencé à avoir des badblocks ?
En gros est-ce que je peux garder mon disque (en faisant des sauvegardes
cette fois !) ? Ou bien existe-t-il des outils permettant de vérifier
l'état réel du disque pour me dire si je peux le garder ou non ?
6) Est-ce que l'on peut activer des options pour améliorer la
robustesse du système de fichier sur le disque ? je vois pleins
d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas
toujours le sens...
Il y a déjà une très forte redondance des données, en interne
dans le disque, pour éviter ce genre de problèmes. De plus,
les badblocks sont en principe remappés à la volée au fur et à
mesure de leur apparition. En général, quand un disque moderne
présente des signes de faiblesses, c'est que le controleur interne
a déjà utilisé toutes les astuces pour éviter les pertes de données.
Le seul moyen pour augmenter encore la redondance des données
et donc augmenter la fiabilité, c'est de faire du RAID, je pense...
Je viens de trouver l'option 'SMART monitoring' dans mon BIOS pour
apparemment améliorer la fiabilité des résultats... je ne sais pas du
tout ce que cela vaut...
2) Pourquoi ai-je réussi à copier les données avec 'debugfs'
alors> > qu'en recopiant comme un bourrin avec 'dd' j'ai des donnéesendommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
Justement ou bien les données sont endommagées et dans ce cas 'dd'
et'debugfs' ne peuvent pas recopier les données sur un autre disque
correctement, ou bien elles sont saines ?!?
Qu'est-ce que debugfs avait de si particulier pour réussir (haut la
main) à recopier des données que 'dd' n'arrive pas à lire ?
Il est tout à fait possible que le disque renvoie des erreurs lors
des accès, mais qu'en insistant, on arrive à lire les données.
C'est sans doute ce qui est arrivé lors de la copie avec dd.
Le disque d'arrivée étant sain, tu n'as donc aucun problème pour
relire la copie.
Il ne faut pas oublier que le problème est un problème physique,
pas de contenu. Donc, une fois que tu as réussi à recopier les
données sur un autre support, il n'y a aucune raison que tu ne
puisse pas les récupérer.
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck',
l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce
un> > problème de surchauffe de disque (il était un peu coincé entre
un> > lecteur de disquette et un lecteur DVD) ? ou bien ce genre deplaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je m'apperçoive
que c'était le controleur IDE qui était en train de lacher...
Les disques se sont révélés être tous récupérables sur un autre
PC...
Euh... Est ce que c'est la récupération avec 'dd if=/dev/zero
of=/dev/<...>' qui engendre de toute façon une durée de vie assez
faible ou bien est-ce parce que j'ai commencé à avoir des badblocks
?
C'est le fait d'avoir des bad-blocs qui prouve que ton disque n'est
pas loin de la retraite...
En gros est-ce que je peux garder mon disque (en faisant des
sauvegardes cette fois !) ? Ou bien existe-t-il des outils
permettant de vérifier l'état réel du disque pour me dire si je peux
le garder ou non ?
S'il existe des outils, ce sont des outils spécifiques au constructeur
du disque. Il n'y a que chez eux que tu trouveras la réponse.6) Est-ce que l'on peut activer des options pour améliorer la
robustesse du système de fichier sur le disque ? je vois pleins
d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas
toujours le sens...
Il y a déjà une très forte redondance des données, en interne
dans le disque, pour éviter ce genre de problèmes. De plus,
les badblocks sont en principe remappés à la volée au fur et à
mesure de leur apparition. En général, quand un disque moderne
présente des signes de faiblesses, c'est que le controleur interne
a déjà utilisé toutes les astuces pour éviter les pertes de
données.> Le seul moyen pour augmenter encore la redondance des
données> et donc augmenter la fiabilité, c'est de faire du RAID, je
pense...>
Je viens de trouver l'option 'SMART monitoring' dans mon BIOS pour
apparemment améliorer la fiabilité des résultats... je ne sais pas
du tout ce que cela vaut...
Je ne pense pas que le SMART améliore quoi que ce soit.
Si j'ai bien compris, il peut te permettre de connaitre l'état
du disque et de détecter les défaillances, mais pas d'empêcher
ou de détecter à l'avance ses défaillances, ni de protéger les
données contre ces défaillances.
2) Pourquoi ai-je réussi à copier les données avec 'debugfs'
alors> > qu'en recopiant comme un bourrin avec 'dd' j'ai des données
endommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
Justement ou bien les données sont endommagées et dans ce cas 'dd'
et'debugfs' ne peuvent pas recopier les données sur un autre disque
correctement, ou bien elles sont saines ?!?
Qu'est-ce que debugfs avait de si particulier pour réussir (haut la
main) à recopier des données que 'dd' n'arrive pas à lire ?
Il est tout à fait possible que le disque renvoie des erreurs lors
des accès, mais qu'en insistant, on arrive à lire les données.
C'est sans doute ce qui est arrivé lors de la copie avec dd.
Le disque d'arrivée étant sain, tu n'as donc aucun problème pour
relire la copie.
Il ne faut pas oublier que le problème est un problème physique,
pas de contenu. Donc, une fois que tu as réussi à recopier les
données sur un autre support, il n'y a aucune raison que tu ne
puisse pas les récupérer.
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck',
l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce
un> > problème de surchauffe de disque (il était un peu coincé entre
un> > lecteur de disquette et un lecteur DVD) ? ou bien ce genre de
plaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je m'apperçoive
que c'était le controleur IDE qui était en train de lacher...
Les disques se sont révélés être tous récupérables sur un autre
PC...
Euh... Est ce que c'est la récupération avec 'dd if=/dev/zero
of=/dev/<...>' qui engendre de toute façon une durée de vie assez
faible ou bien est-ce parce que j'ai commencé à avoir des badblocks
?
C'est le fait d'avoir des bad-blocs qui prouve que ton disque n'est
pas loin de la retraite...
En gros est-ce que je peux garder mon disque (en faisant des
sauvegardes cette fois !) ? Ou bien existe-t-il des outils
permettant de vérifier l'état réel du disque pour me dire si je peux
le garder ou non ?
S'il existe des outils, ce sont des outils spécifiques au constructeur
du disque. Il n'y a que chez eux que tu trouveras la réponse.
6) Est-ce que l'on peut activer des options pour améliorer la
robustesse du système de fichier sur le disque ? je vois pleins
d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas
toujours le sens...
Il y a déjà une très forte redondance des données, en interne
dans le disque, pour éviter ce genre de problèmes. De plus,
les badblocks sont en principe remappés à la volée au fur et à
mesure de leur apparition. En général, quand un disque moderne
présente des signes de faiblesses, c'est que le controleur interne
a déjà utilisé toutes les astuces pour éviter les pertes de
données.> Le seul moyen pour augmenter encore la redondance des
données> et donc augmenter la fiabilité, c'est de faire du RAID, je
pense...>
Je viens de trouver l'option 'SMART monitoring' dans mon BIOS pour
apparemment améliorer la fiabilité des résultats... je ne sais pas
du tout ce que cela vaut...
Je ne pense pas que le SMART améliore quoi que ce soit.
Si j'ai bien compris, il peut te permettre de connaitre l'état
du disque et de détecter les défaillances, mais pas d'empêcher
ou de détecter à l'avance ses défaillances, ni de protéger les
données contre ces défaillances.
2) Pourquoi ai-je réussi à copier les données avec 'debugfs'
alors> > qu'en recopiant comme un bourrin avec 'dd' j'ai des donnéesendommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
Justement ou bien les données sont endommagées et dans ce cas 'dd'
et'debugfs' ne peuvent pas recopier les données sur un autre disque
correctement, ou bien elles sont saines ?!?
Qu'est-ce que debugfs avait de si particulier pour réussir (haut la
main) à recopier des données que 'dd' n'arrive pas à lire ?
Il est tout à fait possible que le disque renvoie des erreurs lors
des accès, mais qu'en insistant, on arrive à lire les données.
C'est sans doute ce qui est arrivé lors de la copie avec dd.
Le disque d'arrivée étant sain, tu n'as donc aucun problème pour
relire la copie.
Il ne faut pas oublier que le problème est un problème physique,
pas de contenu. Donc, une fois que tu as réussi à recopier les
données sur un autre support, il n'y a aucune raison que tu ne
puisse pas les récupérer.
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck',
l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce
un> > problème de surchauffe de disque (il était un peu coincé entre
un> > lecteur de disquette et un lecteur DVD) ? ou bien ce genre deplaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je m'apperçoive
que c'était le controleur IDE qui était en train de lacher...
Les disques se sont révélés être tous récupérables sur un autre
PC...
Euh... Est ce que c'est la récupération avec 'dd if=/dev/zero
of=/dev/<...>' qui engendre de toute façon une durée de vie assez
faible ou bien est-ce parce que j'ai commencé à avoir des badblocks
?
C'est le fait d'avoir des bad-blocs qui prouve que ton disque n'est
pas loin de la retraite...
En gros est-ce que je peux garder mon disque (en faisant des
sauvegardes cette fois !) ? Ou bien existe-t-il des outils
permettant de vérifier l'état réel du disque pour me dire si je peux
le garder ou non ?
S'il existe des outils, ce sont des outils spécifiques au constructeur
du disque. Il n'y a que chez eux que tu trouveras la réponse.6) Est-ce que l'on peut activer des options pour améliorer la
robustesse du système de fichier sur le disque ? je vois pleins
d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas
toujours le sens...
Il y a déjà une très forte redondance des données, en interne
dans le disque, pour éviter ce genre de problèmes. De plus,
les badblocks sont en principe remappés à la volée au fur et à
mesure de leur apparition. En général, quand un disque moderne
présente des signes de faiblesses, c'est que le controleur interne
a déjà utilisé toutes les astuces pour éviter les pertes de
données.> Le seul moyen pour augmenter encore la redondance des
données> et donc augmenter la fiabilité, c'est de faire du RAID, je
pense...>
Je viens de trouver l'option 'SMART monitoring' dans mon BIOS pour
apparemment améliorer la fiabilité des résultats... je ne sais pas
du tout ce que cela vaut...
Je ne pense pas que le SMART améliore quoi que ce soit.
Si j'ai bien compris, il peut te permettre de connaitre l'état
du disque et de détecter les défaillances, mais pas d'empêcher
ou de détecter à l'avance ses défaillances, ni de protéger les
données contre ces défaillances.
On Sat, 14 Feb 2004 14:26:25 +0100, no_spam2) Pourquoi ai-je réussi à copier les données avec 'debugfs'
alors> > qu'en recopiant comme un bourrin avec 'dd' j'ai des donnéesendommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
Justement ou bien les données sont endommagées et dans ce cas 'dd'
et'debugfs' ne peuvent pas recopier les données sur un autre disque
correctement, ou bien elles sont saines ?!?
Qu'est-ce que debugfs avait de si particulier pour réussir (haut la
main) à recopier des données que 'dd' n'arrive pas à lire ?
Il est tout à fait possible que le disque renvoie des erreurs lors
des accès, mais qu'en insistant, on arrive à lire les données.
C'est sans doute ce qui est arrivé lors de la copie avec dd.
Le disque d'arrivée étant sain, tu n'as donc aucun problème pour
relire la copie.
Il ne faut pas oublier que le problème est un problème physique,
pas de contenu. Donc, une fois que tu as réussi à recopier les
données sur un autre support, il n'y a aucune raison que tu ne
puisse pas les récupérer.
J'ai l'impression que l'on ne se comprend pas...
Bien entendu le disque d'arrivée est sain, la question portait sur le
fait que 'dd' et 'debugfs' avait apparemment un mode d'accès
aux données différent car 'dd' recopiait des données corrompues sur le
disque d'arrivée et 'debugfs' recopiait des données correctes.
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck',
l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce
un> > problème de surchauffe de disque (il était un peu coincé entre
un> > lecteur de disquette et un lecteur DVD) ? ou bien ce genre deplaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je m'apperçoive
que c'était le controleur IDE qui était en train de lacher...
Les disques se sont révélés être tous récupérables sur un autre
PC...
Euh... Est ce que c'est la récupération avec 'dd if=/dev/zero
of=/dev/<...>' qui engendre de toute façon une durée de vie assez
faible ou bien est-ce parce que j'ai commencé à avoir des badblocks
?
C'est le fait d'avoir des bad-blocs qui prouve que ton disque n'est
pas loin de la retraite...
Mais je croyais que justement l'apparation de ces badblocks était prévu
par le constructeur (d'où le remappage d'ailleurs...) ?
Ou bien dès le début de l'apparition du premier badblocks on est en
phase terminale ou bien c'est un comportement prévu et dans ce cas pas
de panique (et pas besoin de jeter le disque... !).
Je viens de trouver l'option 'SMART monitoring' dans mon BIOS pour
apparemment améliorer la fiabilité des résultats... je ne sais pas
du tout ce que cela vaut...
Je ne pense pas que le SMART améliore quoi que ce soit.
Si j'ai bien compris, il peut te permettre de connaitre l'état
du disque et de détecter les défaillances, mais pas d'empêcher
ou de détecter à l'avance ses défaillances, ni de protéger les
données contre ces défaillances.
C'est toujours ça de pris sur l'ennemi !
Si j'avais pu détecter le premier signe de défaillance avant que toute
la partition parte en vrille, j'aurai pu mettre au chaud un bon paquet
de données...
On Sat, 14 Feb 2004 14:26:25 +0100, no_spam
2) Pourquoi ai-je réussi à copier les données avec 'debugfs'
alors> > qu'en recopiant comme un bourrin avec 'dd' j'ai des données
endommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
Justement ou bien les données sont endommagées et dans ce cas 'dd'
et'debugfs' ne peuvent pas recopier les données sur un autre disque
correctement, ou bien elles sont saines ?!?
Qu'est-ce que debugfs avait de si particulier pour réussir (haut la
main) à recopier des données que 'dd' n'arrive pas à lire ?
Il est tout à fait possible que le disque renvoie des erreurs lors
des accès, mais qu'en insistant, on arrive à lire les données.
C'est sans doute ce qui est arrivé lors de la copie avec dd.
Le disque d'arrivée étant sain, tu n'as donc aucun problème pour
relire la copie.
Il ne faut pas oublier que le problème est un problème physique,
pas de contenu. Donc, une fois que tu as réussi à recopier les
données sur un autre support, il n'y a aucune raison que tu ne
puisse pas les récupérer.
J'ai l'impression que l'on ne se comprend pas...
Bien entendu le disque d'arrivée est sain, la question portait sur le
fait que 'dd' et 'debugfs' avait apparemment un mode d'accès
aux données différent car 'dd' recopiait des données corrompues sur le
disque d'arrivée et 'debugfs' recopiait des données correctes.
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck',
l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce
un> > problème de surchauffe de disque (il était un peu coincé entre
un> > lecteur de disquette et un lecteur DVD) ? ou bien ce genre de
plaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je m'apperçoive
que c'était le controleur IDE qui était en train de lacher...
Les disques se sont révélés être tous récupérables sur un autre
PC...
Euh... Est ce que c'est la récupération avec 'dd if=/dev/zero
of=/dev/<...>' qui engendre de toute façon une durée de vie assez
faible ou bien est-ce parce que j'ai commencé à avoir des badblocks
?
C'est le fait d'avoir des bad-blocs qui prouve que ton disque n'est
pas loin de la retraite...
Mais je croyais que justement l'apparation de ces badblocks était prévu
par le constructeur (d'où le remappage d'ailleurs...) ?
Ou bien dès le début de l'apparition du premier badblocks on est en
phase terminale ou bien c'est un comportement prévu et dans ce cas pas
de panique (et pas besoin de jeter le disque... !).
Je viens de trouver l'option 'SMART monitoring' dans mon BIOS pour
apparemment améliorer la fiabilité des résultats... je ne sais pas
du tout ce que cela vaut...
Je ne pense pas que le SMART améliore quoi que ce soit.
Si j'ai bien compris, il peut te permettre de connaitre l'état
du disque et de détecter les défaillances, mais pas d'empêcher
ou de détecter à l'avance ses défaillances, ni de protéger les
données contre ces défaillances.
C'est toujours ça de pris sur l'ennemi !
Si j'avais pu détecter le premier signe de défaillance avant que toute
la partition parte en vrille, j'aurai pu mettre au chaud un bon paquet
de données...
On Sat, 14 Feb 2004 14:26:25 +0100, no_spam2) Pourquoi ai-je réussi à copier les données avec 'debugfs'
alors> > qu'en recopiant comme un bourrin avec 'dd' j'ai des donnéesendommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
Justement ou bien les données sont endommagées et dans ce cas 'dd'
et'debugfs' ne peuvent pas recopier les données sur un autre disque
correctement, ou bien elles sont saines ?!?
Qu'est-ce que debugfs avait de si particulier pour réussir (haut la
main) à recopier des données que 'dd' n'arrive pas à lire ?
Il est tout à fait possible que le disque renvoie des erreurs lors
des accès, mais qu'en insistant, on arrive à lire les données.
C'est sans doute ce qui est arrivé lors de la copie avec dd.
Le disque d'arrivée étant sain, tu n'as donc aucun problème pour
relire la copie.
Il ne faut pas oublier que le problème est un problème physique,
pas de contenu. Donc, une fois que tu as réussi à recopier les
données sur un autre support, il n'y a aucune raison que tu ne
puisse pas les récupérer.
J'ai l'impression que l'on ne se comprend pas...
Bien entendu le disque d'arrivée est sain, la question portait sur le
fait que 'dd' et 'debugfs' avait apparemment un mode d'accès
aux données différent car 'dd' recopiait des données corrompues sur le
disque d'arrivée et 'debugfs' recopiait des données correctes.
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck',
l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce
un> > problème de surchauffe de disque (il était un peu coincé entre
un> > lecteur de disquette et un lecteur DVD) ? ou bien ce genre deplaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je m'apperçoive
que c'était le controleur IDE qui était en train de lacher...
Les disques se sont révélés être tous récupérables sur un autre
PC...
Euh... Est ce que c'est la récupération avec 'dd if=/dev/zero
of=/dev/<...>' qui engendre de toute façon une durée de vie assez
faible ou bien est-ce parce que j'ai commencé à avoir des badblocks
?
C'est le fait d'avoir des bad-blocs qui prouve que ton disque n'est
pas loin de la retraite...
Mais je croyais que justement l'apparation de ces badblocks était prévu
par le constructeur (d'où le remappage d'ailleurs...) ?
Ou bien dès le début de l'apparition du premier badblocks on est en
phase terminale ou bien c'est un comportement prévu et dans ce cas pas
de panique (et pas besoin de jeter le disque... !).
Je viens de trouver l'option 'SMART monitoring' dans mon BIOS pour
apparemment améliorer la fiabilité des résultats... je ne sais pas
du tout ce que cela vaut...
Je ne pense pas que le SMART améliore quoi que ce soit.
Si j'ai bien compris, il peut te permettre de connaitre l'état
du disque et de détecter les défaillances, mais pas d'empêcher
ou de détecter à l'avance ses défaillances, ni de protéger les
données contre ces défaillances.
C'est toujours ça de pris sur l'ennemi !
Si j'avais pu détecter le premier signe de défaillance avant que toute
la partition parte en vrille, j'aurai pu mettre au chaud un bon paquet
de données...
2) Pourquoi ai-je réussi à copier les données avec 'debugfs'
alors> > qu'en recopiant comme un bourrin avec 'dd' j'ai des
données> >> > endommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
Justement ou bien les données sont endommagées et dans ce cas
'dd'> > et'debugfs' ne peuvent pas recopier les données sur un autre
disque> > correctement, ou bien elles sont saines ?!?Qu'est-ce que debugfs avait de si particulier pour réussir (haut
la> > main) à recopier des données que 'dd' n'arrive pas à lire ?
Il est tout à fait possible que le disque renvoie des erreurs lors
des accès, mais qu'en insistant, on arrive à lire les données.
C'est sans doute ce qui est arrivé lors de la copie avec dd.
Le disque d'arrivée étant sain, tu n'as donc aucun problème pour
relire la copie.
Il ne faut pas oublier que le problème est un problème physique,
pas de contenu. Donc, une fois que tu as réussi à recopier les
données sur un autre support, il n'y a aucune raison que tu ne
puisse pas les récupérer.
J'ai l'impression que l'on ne se comprend pas...
En effet...Bien entendu le disque d'arrivée est sain, la question portait sur
le fait que 'dd' et 'debugfs' avait apparemment un mode d'accès
aux données différent car 'dd' recopiait des données corrompues sur
le disque d'arrivée et 'debugfs' recopiait des données correctes.
debugfs ne recopie pas de données, il travaille en place. Ce que j'ai
compris, c'est que tu as lancé debugfs après la copie par dd,
sur la copie... Si c'est le cas, c'est normal qu'il n'y ait aucune
erreur. Si tu l'a lancé sur la partition d'origine, la seule
différence peut venir du fait que debugfs écrit des blocs, ce qui peut
avoir pour effet de les remapper ailleurs et donc de faire disparaitre
(au moins momentanément) les badblocs, ce qu'une simple lecture
ne fera jamais.
5) Après reformatage et test avec avec 'badblocks' et
'e2fsck',> >> > l'ancien disque dur semble nickel. Que s'est-il passé
? était-ce> >un> > problème de surchauffe de disque (il était un peu
coincé entre> >un> > lecteur de disquette et un lecteur DVD) ? ou
bien ce genre de> >> > plaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je
m'apperçoive> >> que c'était le controleur IDE qui était en train de
lacher...> >> Les disques se sont révélés être tous récupérables sur
un autre> >> PC...
Euh... Est ce que c'est la récupération avec 'dd if=/dev/zero
of=/dev/<...>' qui engendre de toute façon une durée de vie assez
faible ou bien est-ce parce que j'ai commencé à avoir des
badblocks> > ?
C'est le fait d'avoir des bad-blocs qui prouve que ton disque n'est
pas loin de la retraite...
Mais je croyais que justement l'apparation de ces badblocks était
prévu par le constructeur (d'où le remappage d'ailleurs...) ?
Ou bien dès le début de l'apparition du premier badblocks on est en
phase terminale ou bien c'est un comportement prévu et dans ce cas
pas de panique (et pas besoin de jeter le disque... !).
En principe, le premier badblock visible par l'utilisateur arrive
quand le controleur interne du disque a épuisé toutes les possibilités
de remapage. Ce qui veut dire qu'une bonne partie du disque est
déjà morte... D'un autre coté, comme certains disques sont
récupérables avec dd, ça prouve que les controleurs ne sont pas si
intelligents que ça. Mais il faut se méfier: sur les disques IBM
(maintenant Hitachi), les secteurs sont compressés. Donc, un dd
if=/dev/zero occupera un espace physique sur le disque assez petit. Et
on peut alors, par chance, ne pas tomber sur les badblocs, qui
réapparaitront au fur et à mesure de l'écriture de données plus
significatives sur le disque.
La bonne méthode serait peut-être d'utiliser /dev/urandom au lieu
de /dev/zero, mais je n'ai jamais essayé.
<...>
Je viens de trouver l'option 'SMART monitoring' dans mon BIOS
pour> > apparemment améliorer la fiabilité des résultats... je ne
sais pas> > du tout ce que cela vaut...
Je ne pense pas que le SMART améliore quoi que ce soit.
Si j'ai bien compris, il peut te permettre de connaitre l'état
du disque et de détecter les défaillances, mais pas d'empêcher
ou de détecter à l'avance ses défaillances, ni de protéger les
données contre ces défaillances.
C'est toujours ça de pris sur l'ennemi !
Si j'avais pu détecter le premier signe de défaillance avant que
toute la partition parte en vrille, j'aurai pu mettre au chaud un
bon paquet de données...
Je ne sais pas quelles infos il remonte exactement, mais ça peut
peut-être aider à éviter le pire...
2) Pourquoi ai-je réussi à copier les données avec 'debugfs'
alors> > qu'en recopiant comme un bourrin avec 'dd' j'ai des
données> >> > endommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
Justement ou bien les données sont endommagées et dans ce cas
'dd'> > et'debugfs' ne peuvent pas recopier les données sur un autre
disque> > correctement, ou bien elles sont saines ?!?
Qu'est-ce que debugfs avait de si particulier pour réussir (haut
la> > main) à recopier des données que 'dd' n'arrive pas à lire ?
Il est tout à fait possible que le disque renvoie des erreurs lors
des accès, mais qu'en insistant, on arrive à lire les données.
C'est sans doute ce qui est arrivé lors de la copie avec dd.
Le disque d'arrivée étant sain, tu n'as donc aucun problème pour
relire la copie.
Il ne faut pas oublier que le problème est un problème physique,
pas de contenu. Donc, une fois que tu as réussi à recopier les
données sur un autre support, il n'y a aucune raison que tu ne
puisse pas les récupérer.
J'ai l'impression que l'on ne se comprend pas...
En effet...
Bien entendu le disque d'arrivée est sain, la question portait sur
le fait que 'dd' et 'debugfs' avait apparemment un mode d'accès
aux données différent car 'dd' recopiait des données corrompues sur
le disque d'arrivée et 'debugfs' recopiait des données correctes.
debugfs ne recopie pas de données, il travaille en place. Ce que j'ai
compris, c'est que tu as lancé debugfs après la copie par dd,
sur la copie... Si c'est le cas, c'est normal qu'il n'y ait aucune
erreur. Si tu l'a lancé sur la partition d'origine, la seule
différence peut venir du fait que debugfs écrit des blocs, ce qui peut
avoir pour effet de les remapper ailleurs et donc de faire disparaitre
(au moins momentanément) les badblocs, ce qu'une simple lecture
ne fera jamais.
5) Après reformatage et test avec avec 'badblocks' et
'e2fsck',> >> > l'ancien disque dur semble nickel. Que s'est-il passé
? était-ce> >un> > problème de surchauffe de disque (il était un peu
coincé entre> >un> > lecteur de disquette et un lecteur DVD) ? ou
bien ce genre de> >> > plaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je
m'apperçoive> >> que c'était le controleur IDE qui était en train de
lacher...> >> Les disques se sont révélés être tous récupérables sur
un autre> >> PC...
Euh... Est ce que c'est la récupération avec 'dd if=/dev/zero
of=/dev/<...>' qui engendre de toute façon une durée de vie assez
faible ou bien est-ce parce que j'ai commencé à avoir des
badblocks> > ?
C'est le fait d'avoir des bad-blocs qui prouve que ton disque n'est
pas loin de la retraite...
Mais je croyais que justement l'apparation de ces badblocks était
prévu par le constructeur (d'où le remappage d'ailleurs...) ?
Ou bien dès le début de l'apparition du premier badblocks on est en
phase terminale ou bien c'est un comportement prévu et dans ce cas
pas de panique (et pas besoin de jeter le disque... !).
En principe, le premier badblock visible par l'utilisateur arrive
quand le controleur interne du disque a épuisé toutes les possibilités
de remapage. Ce qui veut dire qu'une bonne partie du disque est
déjà morte... D'un autre coté, comme certains disques sont
récupérables avec dd, ça prouve que les controleurs ne sont pas si
intelligents que ça. Mais il faut se méfier: sur les disques IBM
(maintenant Hitachi), les secteurs sont compressés. Donc, un dd
if=/dev/zero occupera un espace physique sur le disque assez petit. Et
on peut alors, par chance, ne pas tomber sur les badblocs, qui
réapparaitront au fur et à mesure de l'écriture de données plus
significatives sur le disque.
La bonne méthode serait peut-être d'utiliser /dev/urandom au lieu
de /dev/zero, mais je n'ai jamais essayé.
<...>
Je viens de trouver l'option 'SMART monitoring' dans mon BIOS
pour> > apparemment améliorer la fiabilité des résultats... je ne
sais pas> > du tout ce que cela vaut...
Je ne pense pas que le SMART améliore quoi que ce soit.
Si j'ai bien compris, il peut te permettre de connaitre l'état
du disque et de détecter les défaillances, mais pas d'empêcher
ou de détecter à l'avance ses défaillances, ni de protéger les
données contre ces défaillances.
C'est toujours ça de pris sur l'ennemi !
Si j'avais pu détecter le premier signe de défaillance avant que
toute la partition parte en vrille, j'aurai pu mettre au chaud un
bon paquet de données...
Je ne sais pas quelles infos il remonte exactement, mais ça peut
peut-être aider à éviter le pire...
2) Pourquoi ai-je réussi à copier les données avec 'debugfs'
alors> > qu'en recopiant comme un bourrin avec 'dd' j'ai des
données> >> > endommagées?
Les données endommagées l'étaient déjà sur le disque de départ.
dd ne fait que recopier en bloc. debugfs aurait produit un
résultat sans doute simillaire sur le disque d'origine, les
erreurs disques et les risques (si pas de sauvegarde) en plus...
Justement ou bien les données sont endommagées et dans ce cas
'dd'> > et'debugfs' ne peuvent pas recopier les données sur un autre
disque> > correctement, ou bien elles sont saines ?!?Qu'est-ce que debugfs avait de si particulier pour réussir (haut
la> > main) à recopier des données que 'dd' n'arrive pas à lire ?
Il est tout à fait possible que le disque renvoie des erreurs lors
des accès, mais qu'en insistant, on arrive à lire les données.
C'est sans doute ce qui est arrivé lors de la copie avec dd.
Le disque d'arrivée étant sain, tu n'as donc aucun problème pour
relire la copie.
Il ne faut pas oublier que le problème est un problème physique,
pas de contenu. Donc, une fois que tu as réussi à recopier les
données sur un autre support, il n'y a aucune raison que tu ne
puisse pas les récupérer.
J'ai l'impression que l'on ne se comprend pas...
En effet...Bien entendu le disque d'arrivée est sain, la question portait sur
le fait que 'dd' et 'debugfs' avait apparemment un mode d'accès
aux données différent car 'dd' recopiait des données corrompues sur
le disque d'arrivée et 'debugfs' recopiait des données correctes.
debugfs ne recopie pas de données, il travaille en place. Ce que j'ai
compris, c'est que tu as lancé debugfs après la copie par dd,
sur la copie... Si c'est le cas, c'est normal qu'il n'y ait aucune
erreur. Si tu l'a lancé sur la partition d'origine, la seule
différence peut venir du fait que debugfs écrit des blocs, ce qui peut
avoir pour effet de les remapper ailleurs et donc de faire disparaitre
(au moins momentanément) les badblocs, ce qu'une simple lecture
ne fera jamais.
5) Après reformatage et test avec avec 'badblocks' et
'e2fsck',> >> > l'ancien disque dur semble nickel. Que s'est-il passé
? était-ce> >un> > problème de surchauffe de disque (il était un peu
coincé entre> >un> > lecteur de disquette et un lecteur DVD) ? ou
bien ce genre de> >> > plaisanterie peut arriver aléatoirement ?
C'est un coup de chance. Les badblocks ont été remappés par
le controleur interne du disque, sans doute. Il arrive qu'on
récupère des disques avec dd if=/dev/zero of=/dev/<...>
mais ça ne fait que repousser le problème: les disques ainsi
récupérés ont généralement une durée de vie assez faible.
J'ai un seul exemple qui contredit celà: j'ai eu au boulot un PC
qui flinguait les disques en série, jusqu'à ce que je
m'apperçoive> >> que c'était le controleur IDE qui était en train de
lacher...> >> Les disques se sont révélés être tous récupérables sur
un autre> >> PC...
Euh... Est ce que c'est la récupération avec 'dd if=/dev/zero
of=/dev/<...>' qui engendre de toute façon une durée de vie assez
faible ou bien est-ce parce que j'ai commencé à avoir des
badblocks> > ?
C'est le fait d'avoir des bad-blocs qui prouve que ton disque n'est
pas loin de la retraite...
Mais je croyais que justement l'apparation de ces badblocks était
prévu par le constructeur (d'où le remappage d'ailleurs...) ?
Ou bien dès le début de l'apparition du premier badblocks on est en
phase terminale ou bien c'est un comportement prévu et dans ce cas
pas de panique (et pas besoin de jeter le disque... !).
En principe, le premier badblock visible par l'utilisateur arrive
quand le controleur interne du disque a épuisé toutes les possibilités
de remapage. Ce qui veut dire qu'une bonne partie du disque est
déjà morte... D'un autre coté, comme certains disques sont
récupérables avec dd, ça prouve que les controleurs ne sont pas si
intelligents que ça. Mais il faut se méfier: sur les disques IBM
(maintenant Hitachi), les secteurs sont compressés. Donc, un dd
if=/dev/zero occupera un espace physique sur le disque assez petit. Et
on peut alors, par chance, ne pas tomber sur les badblocs, qui
réapparaitront au fur et à mesure de l'écriture de données plus
significatives sur le disque.
La bonne méthode serait peut-être d'utiliser /dev/urandom au lieu
de /dev/zero, mais je n'ai jamais essayé.
<...>
Je viens de trouver l'option 'SMART monitoring' dans mon BIOS
pour> > apparemment améliorer la fiabilité des résultats... je ne
sais pas> > du tout ce que cela vaut...
Je ne pense pas que le SMART améliore quoi que ce soit.
Si j'ai bien compris, il peut te permettre de connaitre l'état
du disque et de détecter les défaillances, mais pas d'empêcher
ou de détecter à l'avance ses défaillances, ni de protéger les
données contre ces défaillances.
C'est toujours ça de pris sur l'ennemi !
Si j'avais pu détecter le premier signe de défaillance avant que
toute la partition parte en vrille, j'aurai pu mettre au chaud un
bon paquet de données...
Je ne sais pas quelles infos il remonte exactement, mais ça peut
peut-être aider à éviter le pire...
Oui effectivement il y avait un malentendu, je lance 'debugfs' sur la
partition d'origine (j'ai bien essayé de lancer 'debugfs' sur les
données recopiées par 'dd' mais elles sont corrompues) ET je recopie via
'rdump' les données du disque endommagé sur le disque sain.
Je serai assez étonné de voir que 'debugfs' fait autre chose que lire
sur le disque endommagé, je ne lui ai rien demandé ! où allons-nous si
les utilitaires de déboguage commencent à écrire sans qu'on leur demande
quoi que ce soit !
En principe, le premier badblock visible par l'utilisateur arrive
quand le controleur interne du disque a épuisé toutes les possibilités
de remapage. Ce qui veut dire qu'une bonne partie du disque est
déjà morte... D'un autre coté, comme certains disques sont
récupérables avec dd, ça prouve que les controleurs ne sont pas si
intelligents que ça. Mais il faut se méfier: sur les disques IBM
(maintenant Hitachi), les secteurs sont compressés. Donc, un dd
if=/dev/zero occupera un espace physique sur le disque assez petit. Et
on peut alors, par chance, ne pas tomber sur les badblocs, qui
réapparaitront au fur et à mesure de l'écriture de données plus
significatives sur le disque.
La bonne méthode serait peut-être d'utiliser /dev/urandom au lieu
de /dev/zero, mais je n'ai jamais essayé.
Ah je commence à comprendre. Tu veux en fait remplir toute la partition
pour voir s'il n'y a pas de badblocks cachés ?
Pourtant je croyais que c'était justement le rôle de l'utilitaire
'badblocks' ? (je l'ai essayé dans les 3 modes : lecture,
lecture-écriture non destructive et écriture destructive)
Si je ne trouve plus de badblocks et que mon disque est remplis, cela
veut bien dire que le contrôleur a réussi à remplacer les badblocks
défectueux ?
Au fait mon disque est un IBM...
On est jamais trop prudent, enfin bon rien ne vaut une bonne sauvegarde
de temps en temps ! ;-)
Oui effectivement il y avait un malentendu, je lance 'debugfs' sur la
partition d'origine (j'ai bien essayé de lancer 'debugfs' sur les
données recopiées par 'dd' mais elles sont corrompues) ET je recopie via
'rdump' les données du disque endommagé sur le disque sain.
Je serai assez étonné de voir que 'debugfs' fait autre chose que lire
sur le disque endommagé, je ne lui ai rien demandé ! où allons-nous si
les utilitaires de déboguage commencent à écrire sans qu'on leur demande
quoi que ce soit !
En principe, le premier badblock visible par l'utilisateur arrive
quand le controleur interne du disque a épuisé toutes les possibilités
de remapage. Ce qui veut dire qu'une bonne partie du disque est
déjà morte... D'un autre coté, comme certains disques sont
récupérables avec dd, ça prouve que les controleurs ne sont pas si
intelligents que ça. Mais il faut se méfier: sur les disques IBM
(maintenant Hitachi), les secteurs sont compressés. Donc, un dd
if=/dev/zero occupera un espace physique sur le disque assez petit. Et
on peut alors, par chance, ne pas tomber sur les badblocs, qui
réapparaitront au fur et à mesure de l'écriture de données plus
significatives sur le disque.
La bonne méthode serait peut-être d'utiliser /dev/urandom au lieu
de /dev/zero, mais je n'ai jamais essayé.
Ah je commence à comprendre. Tu veux en fait remplir toute la partition
pour voir s'il n'y a pas de badblocks cachés ?
Pourtant je croyais que c'était justement le rôle de l'utilitaire
'badblocks' ? (je l'ai essayé dans les 3 modes : lecture,
lecture-écriture non destructive et écriture destructive)
Si je ne trouve plus de badblocks et que mon disque est remplis, cela
veut bien dire que le contrôleur a réussi à remplacer les badblocks
défectueux ?
Au fait mon disque est un IBM...
On est jamais trop prudent, enfin bon rien ne vaut une bonne sauvegarde
de temps en temps ! ;-)
Oui effectivement il y avait un malentendu, je lance 'debugfs' sur la
partition d'origine (j'ai bien essayé de lancer 'debugfs' sur les
données recopiées par 'dd' mais elles sont corrompues) ET je recopie via
'rdump' les données du disque endommagé sur le disque sain.
Je serai assez étonné de voir que 'debugfs' fait autre chose que lire
sur le disque endommagé, je ne lui ai rien demandé ! où allons-nous si
les utilitaires de déboguage commencent à écrire sans qu'on leur demande
quoi que ce soit !
En principe, le premier badblock visible par l'utilisateur arrive
quand le controleur interne du disque a épuisé toutes les possibilités
de remapage. Ce qui veut dire qu'une bonne partie du disque est
déjà morte... D'un autre coté, comme certains disques sont
récupérables avec dd, ça prouve que les controleurs ne sont pas si
intelligents que ça. Mais il faut se méfier: sur les disques IBM
(maintenant Hitachi), les secteurs sont compressés. Donc, un dd
if=/dev/zero occupera un espace physique sur le disque assez petit. Et
on peut alors, par chance, ne pas tomber sur les badblocs, qui
réapparaitront au fur et à mesure de l'écriture de données plus
significatives sur le disque.
La bonne méthode serait peut-être d'utiliser /dev/urandom au lieu
de /dev/zero, mais je n'ai jamais essayé.
Ah je commence à comprendre. Tu veux en fait remplir toute la partition
pour voir s'il n'y a pas de badblocks cachés ?
Pourtant je croyais que c'était justement le rôle de l'utilitaire
'badblocks' ? (je l'ai essayé dans les 3 modes : lecture,
lecture-écriture non destructive et écriture destructive)
Si je ne trouve plus de badblocks et que mon disque est remplis, cela
veut bien dire que le contrôleur a réussi à remplacer les badblocks
défectueux ?
Au fait mon disque est un IBM...
On est jamais trop prudent, enfin bon rien ne vaut une bonne sauvegarde
de temps en temps ! ;-)