Recupération d'un disque suite à de nombreux secteurs défectueux
1 réponse
Sébastien GALLET
Salut la liste,
Un retour d'experience sur un problème classique.
J'ai reçu quelques mails (2 ou 3) de smartd ressemblant a ceci :
This email was generated by the smartd daemon running on:
host name: *****
DNS domain: ***
NIS domain: (none)
The following warning/error was logged by the smartd daemon:
Device: /dev/hdg, ATA error count increased from 0 to 1
For details see host's SYSLOG (default: /var/log/messages).
You can also use the smartctl utility for further investigation.
No additional email messages about this problem will be sent.
N'ayant pas trop de temps libre, je laissais "couler".
Mais vendredi les choses ont commencé à se gater : la partition xfs
s'est demontée et impossible de la remonter.
Comme tout admin qui doit sauvegarder 250Go sur des cartouches de 15Go,
j'avais des sauvegardes en retard.
Bref, je vais essayer de recuperer les données de mon disque (qui
démarre encore) et de restaurer ensuite les fichiers qui manquent.
J'installe un nouveau disque en master et passe celui qui a des pbs en
slave.
Je crée une partition identique (lvm dans mon cas) sur le deuxième et
utilise le programme dd_rescue http://www.garloff.de/kurt/linux/ddrescue/.
Bien evidemment, toutes les manipulations suivantes se font sur des
partitions non montées.
Au bout d'un certain nombre d'erreurs (aléatoire), les modes 32bits et
DMA de mes disques "sautent". Le taux de transfert passe alors à 1300kB/s.
Il faut alors stopper dd_rescue (Ctrl+c), réactiver le dma/32bits et
relancer dd_rescue en utilisant l'option -s.
# dd_rescue -s 98351795.0k /dev/hdh1 /dev/hdg1
La valeur à utiliser pour -s est celle donnée dans le résumé de dd_rescue.
J'ai essayé de lancer hdparm pendant que dd_rescue fonctionne. Très
souvent (mais pas tout le temps), cela rendait le process dd_rescue
intuable (lost interrupt 7 dans les logs)
Plusieurs heures plus tard ... la copie est terminée. En tout, quelques
6000 secteurs n'ont pas pu etre lue (3mo environ)
Arret de la machine, désinstallation du disque endommagé et redémarrage.
Un petit vgscan m'indique que mon volume groupe est opérant.
# xfs_check /dev/datavg1/datalv1
Le superblock de xfs est endommagé, il faut utiliser xfs_repair pour le
réparer.
# xfs_repair /dev/datavg1/datalv1
La premiere fois que j'ai lancé cette commande, elle m'a pratiquement
vidé le système de fichier. Je n'ai pu recuperer qu'un dixième de mon
disque.
J'ai donc refait tout le cycle de copie (dd_rescue) et relancé
xfs_repair mais cette fois en l'arretant par un Ctrl+c (phase 2 ou 3 je
ne sais plus). Je sais c'est pas propre mais ca marche ;).
Mon superblock étant réparer, je monte la partition en ro.
J'ai essayé de remonter la partition en mode rw mais celle-ci plantait.
# mount -t xfs /dev/datavg1/datalv1 /mnt/data
Et la au miracle, toutes mes données sont visibles.
Bien evidemment, certains fichiers ne sont pas accesibles.
# tar --ignore-failed-read -cvzf /dev/nosst0 /mnt/data >
/var/log/data.ok 2>/var/log/data.bad
L'option --ignore-failed-read indique à tar de continuer en cas
d'erreurs de lecture des fichiers (990 dans mons cas).
La liste des fichiers qu'il n'a pas pu sauvegarder est dans
/var/log/data.bad
Plus qu'a reconstruire un système de fichier propre et de restaurer les
sauvegardes. A la louche, j'ai recuperer plus de 95% des données du
disques et une liste des fichiers qui posent problème.
Voila, si ça peut servir à quelqu'un.
Morale : si smartd des alarmes t'envoyer, tes données tu dois vite
sauvegarder.
Morale bis : si smartd tu n'as pas installé, ...
Sébastien
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
feanor
Sébastien GALLET wrote:
Salut la liste,
Un retour d'experience sur un problème classique.
J'ai reçu quelques mails (2 ou 3) de smartd ressemblant a ceci :
This email was generated by the smartd daemon running on: host name: ***** DNS domain: *** NIS domain: (none) The following warning/error was logged by the smartd daemon: Device: /dev/hdg, ATA error count increased from 0 to 1 For details see host's SYSLOG (default: /var/log/messages). You can also use the smartctl utility for further investigation. No additional email messages about this problem will be sent.
N'ayant pas trop de temps libre, je laissais "couler".
Mais vendredi les choses ont commencé à se gater : la partition xfs s'est demontée et impossible de la remonter.
Comme tout admin qui doit sauvegarder 250Go sur des cartouches de 15Go, j'avais des sauvegardes en retard.
Bref, je vais essayer de recuperer les données de mon disque (qui démarre encore) et de restaurer ensuite les fichiers qui manquent.
J'installe un nouveau disque en master et passe celui qui a des pbs en slave.
Je crée une partition identique (lvm dans mon cas) sur le deuxième et utilise le programme dd_rescue http://www.garloff.de/kurt/linux/ddrescue/. Bien evidemment, toutes les manipulations suivantes se font sur des partitions non montées.
Au bout d'un certain nombre d'erreurs (aléatoire), les modes 32bits et DMA de mes disques "sautent". Le taux de transfert passe alors à 1300kB/s. Il faut alors stopper dd_rescue (Ctrl+c), réactiver le dma/32bits et relancer dd_rescue en utilisant l'option -s. # dd_rescue -s 98351795.0k /dev/hdh1 /dev/hdg1
La valeur à utiliser pour -s est celle donnée dans le résumé de dd_rescue. J'ai essayé de lancer hdparm pendant que dd_rescue fonctionne. Très souvent (mais pas tout le temps), cela rendait le process dd_rescue intuable (lost interrupt 7 dans les logs)
Plusieurs heures plus tard ... la copie est terminée. En tout, quelques 6000 secteurs n'ont pas pu etre lue (3mo environ)
Arret de la machine, désinstallation du disque endommagé et redémarrage. Un petit vgscan m'indique que mon volume groupe est opérant.
# xfs_check /dev/datavg1/datalv1
Le superblock de xfs est endommagé, il faut utiliser xfs_repair pour le réparer.
# xfs_repair /dev/datavg1/datalv1
La premiere fois que j'ai lancé cette commande, elle m'a pratiquement vidé le système de fichier. Je n'ai pu recuperer qu'un dixième de mon disque. J'ai donc refait tout le cycle de copie (dd_rescue) et relancé xfs_repair mais cette fois en l'arretant par un Ctrl+c (phase 2 ou 3 je ne sais plus). Je sais c'est pas propre mais ca marche ;).
Mon superblock étant réparer, je monte la partition en ro. J'ai essayé de remonter la partition en mode rw mais celle-ci plantait.
# mount -t xfs /dev/datavg1/datalv1 /mnt/data
Et la au miracle, toutes mes données sont visibles. Bien evidemment, certains fichiers ne sont pas accesibles.
# tar --ignore-failed-read -cvzf /dev/nosst0 /mnt/data > /var/log/data.ok 2>/var/log/data.bad
L'option --ignore-failed-read indique à tar de continuer en cas d'erreurs de lecture des fichiers (990 dans mons cas). La liste des fichiers qu'il n'a pas pu sauvegarder est dans /var/log/data.bad
Plus qu'a reconstruire un système de fichier propre et de restaurer les sauvegardes. A la louche, j'ai recuperer plus de 95% des données du disques et une liste des fichiers qui posent problème.
Voila, si ça peut servir à quelqu'un.
Morale : si smartd des alarmes t'envoyer, tes données tu dois vite sauvegarder.
Morale bis : si smartd tu n'as pas installé, ...
Sébastien
... tu risque de te faire ****er Moi j'ai perdu 100 Go de données comme ça, avec le même problème sauf que c'étais ReiserFS. Enfin au bout d'un moment, le disque a du être touché physiquement vu que maintenant il chante quand on le démarre (genre wouiiiiiiiiiiiiiii clack BIiiiiiiiiiiip etc...)... :( Moi je dis : t'as eu de la chance !
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Sébastien GALLET wrote:
Salut la liste,
Un retour d'experience sur un problème classique.
J'ai reçu quelques mails (2 ou 3) de smartd ressemblant a ceci :
This email was generated by the smartd daemon running on:
host name: *****
DNS domain: ***
NIS domain: (none)
The following warning/error was logged by the smartd daemon:
Device: /dev/hdg, ATA error count increased from 0 to 1
For details see host's SYSLOG (default: /var/log/messages).
You can also use the smartctl utility for further investigation.
No additional email messages about this problem will be sent.
N'ayant pas trop de temps libre, je laissais "couler".
Mais vendredi les choses ont commencé à se gater : la partition xfs
s'est demontée et impossible de la remonter.
Comme tout admin qui doit sauvegarder 250Go sur des cartouches de 15Go,
j'avais des sauvegardes en retard.
Bref, je vais essayer de recuperer les données de mon disque (qui
démarre encore) et de restaurer ensuite les fichiers qui manquent.
J'installe un nouveau disque en master et passe celui qui a des pbs en
slave.
Je crée une partition identique (lvm dans mon cas) sur le deuxième et
utilise le programme dd_rescue http://www.garloff.de/kurt/linux/ddrescue/.
Bien evidemment, toutes les manipulations suivantes se font sur des
partitions non montées.
Au bout d'un certain nombre d'erreurs (aléatoire), les modes 32bits et
DMA de mes disques "sautent". Le taux de transfert passe alors à 1300kB/s.
Il faut alors stopper dd_rescue (Ctrl+c), réactiver le dma/32bits et
relancer dd_rescue en utilisant l'option -s.
# dd_rescue -s 98351795.0k /dev/hdh1 /dev/hdg1
La valeur à utiliser pour -s est celle donnée dans le résumé de dd_rescue.
J'ai essayé de lancer hdparm pendant que dd_rescue fonctionne. Très
souvent (mais pas tout le temps), cela rendait le process dd_rescue
intuable (lost interrupt 7 dans les logs)
Plusieurs heures plus tard ... la copie est terminée. En tout, quelques
6000 secteurs n'ont pas pu etre lue (3mo environ)
Arret de la machine, désinstallation du disque endommagé et redémarrage.
Un petit vgscan m'indique que mon volume groupe est opérant.
# xfs_check /dev/datavg1/datalv1
Le superblock de xfs est endommagé, il faut utiliser xfs_repair pour le
réparer.
# xfs_repair /dev/datavg1/datalv1
La premiere fois que j'ai lancé cette commande, elle m'a pratiquement
vidé le système de fichier. Je n'ai pu recuperer qu'un dixième de mon
disque.
J'ai donc refait tout le cycle de copie (dd_rescue) et relancé
xfs_repair mais cette fois en l'arretant par un Ctrl+c (phase 2 ou 3 je
ne sais plus). Je sais c'est pas propre mais ca marche ;).
Mon superblock étant réparer, je monte la partition en ro.
J'ai essayé de remonter la partition en mode rw mais celle-ci plantait.
# mount -t xfs /dev/datavg1/datalv1 /mnt/data
Et la au miracle, toutes mes données sont visibles.
Bien evidemment, certains fichiers ne sont pas accesibles.
# tar --ignore-failed-read -cvzf /dev/nosst0 /mnt/data >
/var/log/data.ok 2>/var/log/data.bad
L'option --ignore-failed-read indique à tar de continuer en cas
d'erreurs de lecture des fichiers (990 dans mons cas).
La liste des fichiers qu'il n'a pas pu sauvegarder est dans
/var/log/data.bad
Plus qu'a reconstruire un système de fichier propre et de restaurer les
sauvegardes. A la louche, j'ai recuperer plus de 95% des données du
disques et une liste des fichiers qui posent problème.
Voila, si ça peut servir à quelqu'un.
Morale : si smartd des alarmes t'envoyer, tes données tu dois vite
sauvegarder.
Morale bis : si smartd tu n'as pas installé, ...
Sébastien
... tu risque de te faire ****er
Moi j'ai perdu 100 Go de données comme ça, avec le même problème sauf
que c'étais ReiserFS. Enfin au bout d'un moment, le disque a du être
touché physiquement vu que maintenant il chante quand on le démarre
(genre wouiiiiiiiiiiiiiii clack BIiiiiiiiiiiip etc...)...
:(
Moi je dis : t'as eu de la chance !
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
J'ai reçu quelques mails (2 ou 3) de smartd ressemblant a ceci :
This email was generated by the smartd daemon running on: host name: ***** DNS domain: *** NIS domain: (none) The following warning/error was logged by the smartd daemon: Device: /dev/hdg, ATA error count increased from 0 to 1 For details see host's SYSLOG (default: /var/log/messages). You can also use the smartctl utility for further investigation. No additional email messages about this problem will be sent.
N'ayant pas trop de temps libre, je laissais "couler".
Mais vendredi les choses ont commencé à se gater : la partition xfs s'est demontée et impossible de la remonter.
Comme tout admin qui doit sauvegarder 250Go sur des cartouches de 15Go, j'avais des sauvegardes en retard.
Bref, je vais essayer de recuperer les données de mon disque (qui démarre encore) et de restaurer ensuite les fichiers qui manquent.
J'installe un nouveau disque en master et passe celui qui a des pbs en slave.
Je crée une partition identique (lvm dans mon cas) sur le deuxième et utilise le programme dd_rescue http://www.garloff.de/kurt/linux/ddrescue/. Bien evidemment, toutes les manipulations suivantes se font sur des partitions non montées.
Au bout d'un certain nombre d'erreurs (aléatoire), les modes 32bits et DMA de mes disques "sautent". Le taux de transfert passe alors à 1300kB/s. Il faut alors stopper dd_rescue (Ctrl+c), réactiver le dma/32bits et relancer dd_rescue en utilisant l'option -s. # dd_rescue -s 98351795.0k /dev/hdh1 /dev/hdg1
La valeur à utiliser pour -s est celle donnée dans le résumé de dd_rescue. J'ai essayé de lancer hdparm pendant que dd_rescue fonctionne. Très souvent (mais pas tout le temps), cela rendait le process dd_rescue intuable (lost interrupt 7 dans les logs)
Plusieurs heures plus tard ... la copie est terminée. En tout, quelques 6000 secteurs n'ont pas pu etre lue (3mo environ)
Arret de la machine, désinstallation du disque endommagé et redémarrage. Un petit vgscan m'indique que mon volume groupe est opérant.
# xfs_check /dev/datavg1/datalv1
Le superblock de xfs est endommagé, il faut utiliser xfs_repair pour le réparer.
# xfs_repair /dev/datavg1/datalv1
La premiere fois que j'ai lancé cette commande, elle m'a pratiquement vidé le système de fichier. Je n'ai pu recuperer qu'un dixième de mon disque. J'ai donc refait tout le cycle de copie (dd_rescue) et relancé xfs_repair mais cette fois en l'arretant par un Ctrl+c (phase 2 ou 3 je ne sais plus). Je sais c'est pas propre mais ca marche ;).
Mon superblock étant réparer, je monte la partition en ro. J'ai essayé de remonter la partition en mode rw mais celle-ci plantait.
# mount -t xfs /dev/datavg1/datalv1 /mnt/data
Et la au miracle, toutes mes données sont visibles. Bien evidemment, certains fichiers ne sont pas accesibles.
# tar --ignore-failed-read -cvzf /dev/nosst0 /mnt/data > /var/log/data.ok 2>/var/log/data.bad
L'option --ignore-failed-read indique à tar de continuer en cas d'erreurs de lecture des fichiers (990 dans mons cas). La liste des fichiers qu'il n'a pas pu sauvegarder est dans /var/log/data.bad
Plus qu'a reconstruire un système de fichier propre et de restaurer les sauvegardes. A la louche, j'ai recuperer plus de 95% des données du disques et une liste des fichiers qui posent problème.
Voila, si ça peut servir à quelqu'un.
Morale : si smartd des alarmes t'envoyer, tes données tu dois vite sauvegarder.
Morale bis : si smartd tu n'as pas installé, ...
Sébastien
... tu risque de te faire ****er Moi j'ai perdu 100 Go de données comme ça, avec le même problème sauf que c'étais ReiserFS. Enfin au bout d'un moment, le disque a du être touché physiquement vu que maintenant il chante quand on le démarre (genre wouiiiiiiiiiiiiiii clack BIiiiiiiiiiiip etc...)... :( Moi je dis : t'as eu de la chance !
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
