[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Recupération d'un disque suite à de nombreux secteurs défectueux



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.
> 
> Un petit coup d'oeil dans /var/log/messages.
> 
> ....
> May 29 13:59:45 **** kernel: end_request: I/O error, dev 22:41 (hdh),
> sector 42215854
> May 29 13:59:46 **** kernel: hdh: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> May 29 13:59:46 **** kernel: hdh: dma_intr: error=0x40 {
> UncorrectableError }, LBAsect=42215935, high=2, low=866150
> 3, sector=42215856
> ....
> 
> 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.
> 
> # dd_rescue /dev/hdh1 /dev/hdg1
> 
> dd_rescue: (info): ipos:97381696.0k, opos:97381696.0k,
> xferd:662016.0k       
>                    errs:10, errxfer:5.0k,
> succxfer:662011.0k                 +curr.rate:31788kB/s,
> avg.rate:28889kB/s, avg.load:1.0%               
> 
> 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 !



Reply to: