#1 Le 13/09/2016, à 12:16
- EtienneMarc
Raid endommagé - tentative de récupération de données
Bonjour,
J'ai un DD 2Go (avec 3 partitions) qui faisait partie d'une config RAID1 qui me pose des problèmes, et avant d'aller plus loin dans la résolution du problème lié au RAID, je voulais savoir si l'utilisation de l'option "tentative de récupération de données" de Gparted pouvait mettre en péril les autres futures actions sur ce disque ?
En clair, est-ce que je risque d'aggraver mon cas si j'utilise cette option sur ce disque ?
Mon principal objectif est de récupérer mes données sur la 3eme partition pour les copier sur un autre support.
Merci de votre aide.
Dernière modification par EtienneMarc (Le 30/09/2016, à 22:34)
Hors ligne
#2 Le 15/09/2016, à 22:55
- EtienneMarc
Re : Raid endommagé - tentative de récupération de données
Un petit up pour être sûr de ne pas me lancer - tout seul - dans une opération sans retour :-)
Merci
Hors ligne
#3 Le 24/09/2016, à 09:41
- EtienneMarc
Re : Raid endommagé - tentative de récupération de données
Je vais dobc faire le saut dans l'inconnu... J'espère que tout se passera bien..
Merci
Hors ligne
#4 Le 24/09/2016, à 11:02
- moko138
Re : Raid endommagé - tentative de récupération de données
Je découvre ton fil trop tard.
Tout ce que je peux te dire c'est que gparted n'est pas un logiciel de récupération de données.
Il sait lancer fsck (et le fait avant toutte modif de partition).
Il sait copier une partition saine (et peut-être une partition pas saine sous certaines réserves).
Sur la récupération de données, tu trouveras des fils spécifiques de rmy et de Bougron.
Une façon classique de ne pas
mettre en péril les autres futures actions sur ce disque
c'est de commencer par faire une ou deux images du disque.
Tu n'as pas dit quels étaient les systèmes de fichiers de ces trois partitions.
Tu n'as pas montré le partitionnement, même théorique.
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#5 Le 25/09/2016, à 22:40
- EtienneMarc
Re : Raid endommagé - tentative de récupération de données
Merci de ta réponse.
Je voulais essayer car à la lecture, gparted propose de "réparer" la partition...
En fait, il s'agit d'un disque de 2 To qui faisait partie d'un NAS en RAID1, donc j'ai déjà une copie du disque .
Le disque est partitionné en 3, et la première partition "non-alloué" qui doit être celle utilisé par le NAS pour sa gestion semble endommagée. (mon problème est que le NAS ne peut plus lire mes données, mais elle doivent pourtant être toujours là, dans la partition de 1.8 To, la troisième qui en "linux-raid" mais que je ne sais pas comment monter)
(ou http://pix.toile-libre.org/?img=1474835658.png
Merci pour vos avis.
Dernière modification par EtienneMarc (Le 25/09/2016, à 22:42)
Hors ligne
#6 Le 26/09/2016, à 05:03
- moko138
Re : Raid endommagé - tentative de récupération de données
1) Ce que tu appelles "partition non allouée" N'est PAS une partition. C'est de l'espace (ici 32 Mio) non utilisé. Ce disque a donc deux partitions.
2) À ma connaissance, quand gparted propose de "réparer" une partition, il ne fait rien d'autre que lancer un fsck automatique, adapté au type de cette partition.
3) Tu devrais changer le titre pour quelque chose de plus explicite, par exemple
"raid endommagé, tentative de récupération".
4) Comme je ne connais rien au raid,
je passe la main.
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#7 Le 30/09/2016, à 22:37
- EtienneMarc
Re : Raid endommagé - tentative de récupération de données
Merci moko138
Je viens de changer le titre.
Si quelqu'un à une idée sur comment lire cette partition "linux-raid", je suis plus que preneur !
Merci
Hors ligne
#8 Le 01/10/2016, à 13:21
- Bougron
Re : Raid endommagé - tentative de récupération de données
Bonjour
Je comprends mal ta phrase qui parle du passé
"J'ai un DD 2Go (avec 3 partitions) qui faisait partie d'une config RAID1 "
Qu'est devenu son frère jumeau? qu'es devenu ce RAID1 L'as-tu déactivé?
Pourquoi cette phrase "avant d'aller plus loin dans la résolution du problème lié au RAID"
Dans l'ensemble lorsqu'on a un RAIDS1 opérationnel, c'est l'application MDADM qui traite le problème matériel.
Il faut donc que tu en dises un peu plus sur le problème que tu as.
J'ai noté
"Mon principal objectif est de récupérer mes données sur la 3eme partition pour les copier sur un autre support."
Dans ce contexte, une seule application "ddrescue"
Elle sait dupliquer la partition sur un autre support en oubliant ce qui n'est pas lisible.
Si tu disposes quelque part de l'ex-jumelle de cette partition, elle pourra finaliser la copie en continuant avec cette jumelle.
Cependant si tu as détruit le RAIDS parce qu'il te disait que le secteur N était illisible, cela veut dire qu'il n'est pas lisible sur aucune des deux partitions.
Voilà ce que je peux te dire en première approche en attendant de mieux cerner la raison de la duplication de la partition et non des fichiers qu'elle contient.
Je ne possède pas de RAIDS logiciel donc pas d'expérience pratique de l'application.
Dernière modification par Bougron (Le 01/10/2016, à 13:24)
Hors ligne
#9 Le 03/10/2016, à 21:29
- EtienneMarc
Re : Raid endommagé - tentative de récupération de données
Bonjour Bougron,
je vais essayer d'être plus clair :-)
J'ai (j'avais !) un NAS Lenovo ix2-200 (spécifications) en RAID1 (donc 2 DD en miroir, pas de RAID logiciel) de 2 To (2 DD de To chacun).
Mon NAS ne parvient plus à lire les disques et ne me propose que l'option formatage. (Peut-être parce que je suis arrivé à 90/95% de sa capacité ?)
J'ai donc 2 DD jumeaux, qui sont dans le même état.
Mon idée était d'en garder de coté par sécurité, et de ne travailler que sur un seul disque.
J'ai sorti les DD du NAS, pour brancher un des 2 disques en USB avec un adaptateur.
J'imagine que mes données sont sur la partition de 1.8 To. Elle apparaît en "linux-raid" que je ne sais pas lire.
Pour partir d'une configuration la plus propre possible, j'ai préparé une clé Live-USB avec Ubuntu 16.04 en mode persistant.
Je ne suis pas certain, mais je crois que si je parvenais à lire cette partition, on pourrait déjà avoir une idée plus claire du problème.
Merci
Hors ligne
#10 Le 03/10/2016, à 23:41
- jamesbad000
Re : Raid endommagé - tentative de récupération de données
Bonsoir.
A lire les spec et la doc de ce machin, on apprend pas grands chose de la techno raid utilisée ni de la façon dont on pourrait récupérer. Néanmoins, comme c'est du raid1, il doit y avoir moyen de remettre la main sur le système de fichier. Quitte à inventer une méthode non conventionnelle...
Pour commencer un petit classique
sudo parted -l
sudo lsblk -o SIZE,NAME,FSTYPE,LABEL,MOUNTPOINT
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne
#11 Le 03/10/2016, à 23:45
- Bougron
Re : Raid endommagé - tentative de récupération de données
Bonsoir
Je ne suis pas du tout certain que la cause soit celle que tu indiques. Mais probablement une plus grave..
Sur le disque RAIDS qui est monté, tu vas identifier son point de montage /dev/sdX par la commande
sudo fdisk -l
Tu vas lister l'implémentation des partitions par la commande
sudo blkid | grep sdX
en remplaçant X par la bonne valeur. Tu en donneras le retour. Tu vas aussi identifier le taux remplissage par la commande
df -h | grep sdX
en remplaçant X par la bonne valeur .Tu en donneras aussi le retour. Tu vas aussi regarder l'état du disque . Il faut que tu installes l'application GSMARTCONTROL qui est dans la logithéque. et tu donneras le retour de la commande.
sudo smartctl -s on -a /dev/sdX
en remplaçant X par la bonne valeur. Au résultat de cette commande, On aura une idée de la qualité du disque.
Tu peux déjà commencer à lire la documentation ddrescue et à installer cet outil car c'est avec lui qu'on fera la duplication: Durée estimée entre 24 heures et 10 jours en fonction des débits des disques.
Ne lances pas immédiatement la duplication car sa codification va dépendre de ce qu'on verra comme qualité des deux disques.
Si la commande smartctl fonctionne bien, tu débranches ce disque RAID et tu branches le second. Tu refais les mêmes opérations.
A partir de là, je serais apte à te proposer un scénario de duplication.
Dernière modification par Bougron (Le 03/10/2016, à 23:52)
Hors ligne
#12 Le 04/10/2016, à 00:04
- jamesbad000
Re : Raid endommagé - tentative de récupération de données
En fait je n'avais pas vu l'image de gparted. Mais la mention "linux-raid" laisse à penser que c'est du raid logiciel
du coup tu pourra enchainer un
sudo apt-get install mdadm
Comme tu as un live persistant ça ne sera pas perdu.
PS: A ce stade les manip proposées par Bougron ne sont pas contradictoires, mais complémentaires (surtout le smartcl).
Dernière modification par jamesbad000 (Le 04/10/2016, à 23:50)
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne
#13 Le 04/10/2016, à 00:47
- Bougron
Re : Raid endommagé - tentative de récupération de données
Bonsoir Jamesbad000
Je ne suis pas sur du tout que mettre ce logiciel sert à quelque chose. Le plus simple serait de lancer gparted et de virer le flag RAID.
On devrait alors voir apparaître le vrai type de partition. Certainement du EXT2.
J'ai comme idée que le système raids RAID a sauté lorsque le même secteur n° N est devenu illisible sur les deux disques.
Cela peut se produire si le suivi n'est pas sérieux. Et dans un système RAIDS d'un particulier le suivi RAID n'est jamais sérieux.
D'ailleurs, il suffit de voir la docu pour comprendre qu'il est totalement impossible de savoir comment faire le suivi.
Par exemple, j'ai deux petits raids, Je serais informé qu'un disque a laché lorsqu'il y aura une petite loupiote qui s'allumera. Mais elle est a l'atrriere. Je ne regarde que tous les 6 mois. Au pire le RAIDS est de meilleure qualité, mais le paramétrage d'alerte a une vieille adresse email et n'arrive pas à destination. Et même si l'alerte arrive, il faut la traiter et pas dire: Mais c'est vrai, il y a 8 mois, j'ai reçu un drôle d'email!!!!
L'idée que j'ai en tête, est que les deux disques sont fichus et donc prendre ce qui est bon dans les deux pour le regrouper dans le tout nouveau qui va certainement être commandé. Il pourrait n'y avoir que quelques secteurs manquants à l'appel.
C'est pour cela que je souhaite voir la taille des partitions pour être certain quelles sont totalement identique en taille. A partir de là, je fais le pari qu'elles sont identique en structure......
Dernière modification par Bougron (Le 04/10/2016, à 00:50)
Hors ligne
#14 Le 05/10/2016, à 01:33
- jamesbad000
Re : Raid endommagé - tentative de récupération de données
Salut Bougron.
Je ne suis pas sur du tout que mettre ce logiciel sert à quelque chose.
Tu sais moi les certitudes...
A ce stade il y a au moins une indication qui donne une forte probabilité qu'il y ait un raid logiciel prit en charge par linux.
Et aucune information sur un problème matériel. Qui sera éventuellement mis en évidence par smartctl.
Par ailleurs, je peux t'affirmer qu'une partition raid linux ne se résume pas à un flag RAID (Tu notera que la mention "linux-raid" apparait dans la colonne "système de fichier" et non dans la colonne "drapeau".
Et pour cause, car le système de fichier réel se trouve encapsulé dans le système de fichier raid
voilà ce que donne l'analyse d'une partition raid contenant un système de fichier ext4 que j'ai créé :
sudo mdadm --create /dev/md0 --level=1 --assume-clean --raid-devices=2 /dev/loop1 missing
(...)
mdadm: array /dev/md0 started.
sudo mkfs.ext4 -L TESTRAID /dev/md0
mke2fs 1.42.9 (4-Feb-2014)
Rejet des blocs de périphérique : complété
Étiquette de système de fichiers=TESTRAID
(...)
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété
10G loop1 linux_raid_member Extensa:0
10G └─md0 ext4 TESTRAID
fred@Extensa:/media/data$ sudo mdadm --misc /dev/loop1 -E
/dev/loop1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : d3398948:c618d92c:2ad73b98:74fb7510
Name : Extensa:0 (local to host Extensa)
Creation Time : Wed Oct 5 00:58:26 2016
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 20955136 (9.99 GiB 10.73 GB)
Array Size : 10477440 (9.99 GiB 10.73 GB)
Used Dev Size : 20954880 (9.99 GiB 10.73 GB)
Data Offset : 16384 sectors
Tout ceci se trouve au début de la partition là ou se trouverait normalement le système de fichier ext4 que j'ai créé sur le volume raid.
La dernière ligne "data offset" donne l'emplacement du système de fichier ext4 que j'ai créé en formatant le volume raid
et effectivement a cet emplacement je trouve le super bloc ext4 avec le "magic number" d'un système de fichier ext4 (53ef) à l'offset 438 et le nom que j'ai attribué au système de fichier (TESTRAID)
fred@Extensa:/media/data$ sudo hd -s $((16384*512)) -n 2048 /dev/loop1
00800000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00800400 00 00 0a 00 e0 f7 27 00 98 ff 01 00 b1 c0 26 00 |......'.......&.|
00800410 f5 ff 09 00 00 00 00 00 02 00 00 00 02 00 00 00 |................|
00800420 00 80 00 00 00 80 00 00 00 20 00 00 00 00 00 00 |......... ......|
00800430 7a 34 f4 57 00 00 ff ff 53 ef 01 00 01 00 00 00 |z4.W....S.......|
00800440 79 34 f4 57 00 00 00 00 00 00 00 00 01 00 00 00 |y4.W............|
00800450 00 00 00 00 0b 00 00 00 00 01 00 00 3c 00 00 00 |............<...|
00800460 42 02 00 00 7b 00 00 00 80 3f e7 60 d0 82 4a 11 |B...{....?.`..J.|
00800470 b8 b2 42 f2 7c d9 58 fd 54 45 53 54 52 41 49 44 |..B.|.X.TESTRAID|
00800480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Dernière modification par jamesbad000 (Le 22/10/2016, à 19:59)
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne
#15 Le 05/10/2016, à 10:05
- Bougron
Re : Raid endommagé - tentative de récupération de données
Bonjour jamesbad000.
On attend donc avec impatience le résultat du smartctl.
Tu viens de démontrer me semble-t-il que la structure RAIDS logiciel de linux est un système de fichier EXT4 encapsulé.
Il est fort possible que cet appareil utilise la même logique.
Mais je pense réellement que la structure est identique entre les deux disques:
Si le secteur N d'un disque contient une donnée XYZ, le secteur N de l'autre disque contient aussi la donnée XYZ
Il serait surprenant que cela soit le secteur N+P qui stockerait cette même donnée sous la forme ZXZ.
C'est pour cela que dans l'opération de DDrescue si tel est le besoin , je ne vois pas l' intérêt d'utiliser un logiciel supplémentaire car DDrescue est très proche d'un accès physique.
S'il se révèle que la cause est probablement la qualité des deux disques, je propose:
1) L'achat d'un troisième disque de taille au moins identique.
Sans en être certain, il m'a semblé que la description de cet appareil exigeait la même marque de disque. Ce qui me semble anormal.
=> Le principe d'un raid1 est d'éviter d'avoir deux disques du même constructeur fabriqués le même jour donc potentiellement affectés du même défaut de fabrication.
2) Faire une duplication rapide du premier disque sur le nouveau (en 1 passe)
3) Compléter la duplication rapide avec le second disque (en 1 passe)
4) Continuer la duplication approfondie avec le second disque (en 3 ou 9 passes).
5) Continuer la duplication approfondie avec le premier disque (en 3 ou 9 passes).
A partir de cet instant, on verra bien s'il manque quelques secteurs.
Si OUI, on écrira une marque spécifique sur ce qui n'a pas été copié et il faudra vivre avec.
6) On pourra même dupliquer ce disque neuf sur l'un des deux disques s'il semble que l'un soit encore dans un état acceptable (Ce dont je doute). Mais on pourra dupliquer ce disque sur un nouveau disque neuf.
7) On pourra reconstituer le RAIDS soit avec l'appareil. Soit avec le logiciel....... Dans ce contexte de re-fabrication je suis très limité en compétence n'ayant pas encore pratiqué.
PS; Je n'ai pas d'idée particulière pour dire que s'il n'y a plus de place disponible sur le disque, il est normal que le "système" propose de formater. Il me semble que même pour un RAIDS, on devrait être informé qu'il n'y a plus de place disponible.
Hors ligne
#16 Le 09/10/2016, à 20:55
- EtienneMarc
Re : Raid endommagé - tentative de récupération de données
Bonsoir.
A lire les spec et la doc de ce machin, on apprend pas grands chose de la techno raid utilisée ni de la façon dont on pourrait récupérer. Néanmoins, comme c'est du raid1, il doit y avoir moyen de remettre la main sur le système de fichier. Quitte à inventer une méthode non conventionnelle...
Pour commencer un petit classique
sudo parted -l sudo lsblk -o SIZE,NAME,FSTYPE,LABEL,MOUNTPOINT
Voilà....
(J'exécute ubuntu depuis un USB Live)
ubuntu@ubuntu:~$ sudo parted -l
Modèle: ATA ST1000LM024 HN-M (scsi)
Disque /dev/sda : 1000GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : gpt
Disk Flags:
Numéro Début Fin Taille Système de fichiers Nom Fanions
1 1049kB 538MB 537MB fat32 démarrage, esp
2 538MB 983GB 983GB ext4
3 983GB 1000GB 17,1GB linux-swap(v1)
Modèle: Multiple Card Reader (scsi)
Disque /dev/sdb : 31,8GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags:
Numéro Début Fin Taille Type Système de fichiers Fanions
1 1049kB 31,8GB 31,8GB primary fat32 démarrage
Modèle: ASMedia AS2115 (scsi)
Disque /dev/sdc : 2000GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : gpt
Disk Flags:
Numéro Début Fin Taille Système de fichiers Nom Fanions
1 33,6MB 21,5GB 21,5GB primary msftdata
2 21,5GB 2000GB 1979GB primary msftdata
ubuntu@ubuntu:~$ sudo lsblk -o SIZE,NAME,FSTYPE,LABEL,MOUNTPOINT
SIZE NAME FSTYPE LABEL MOUNTPOINT
931,5G sda
512M ├─sda1 vfat
915,1G ├─sda2 ext4
15,9G └─sda3 swap [SWAP]
29,6G sdb iso9660 Ubuntu 16.04 LTS amd64
29,6G └─sdb1 vfat LiveUSB /cdrom
1,8T sdc
20G ├─sdc1 linux_raid_member
1,8T └─sdc2 linux_raid_member ix2-3:1
1024M sr0
1,3G loop0 squashfs /rofs
Merci
Hors ligne
#17 Le 09/10/2016, à 21:11
- EtienneMarc
Re : Raid endommagé - tentative de récupération de données
Bonsoir
Je ne suis pas du tout certain que la cause soit celle que tu indiques. Mais probablement une plus grave..
Sur le disque RAIDS qui est monté, tu vas identifier son point de montage /dev/sdX par la commandesudo fdisk -l
Tu vas lister l'implémentation des partitions par la commande
sudo blkid | grep sdX
en remplaçant X par la bonne valeur. Tu en donneras le retour. Tu vas aussi identifier le taux remplissage par la commande
df -h | grep sdX
en remplaçant X par la bonne valeur .Tu en donneras aussi le retour. Tu vas aussi regarder l'état du disque . Il faut que tu installes l'application GSMARTCONTROL qui est dans la logithéque. et tu donneras le retour de la commande.
sudo smartctl -s on -a /dev/sdX
en remplaçant X par la bonne valeur. Au résultat de cette commande, On aura une idée de la qualité du disque.
Tu peux déjà commencer à lire la documentation ddrescue et à installer cet outil car c'est avec lui qu'on fera la duplication: Durée estimée entre 24 heures et 10 jours en fonction des débits des disques.
Ne lances pas immédiatement la duplication car sa codification va dépendre de ce qu'on verra comme qualité des deux disques.Si la commande smartctl fonctionne bien, tu débranches ce disque RAID et tu branches le second. Tu refais les mêmes opérations.
A partir de là, je serais apte à te proposer un scénario de duplication.
1 J'ai enlevé la partie (ram1,2...) qui ne me semblait pas pertinente : le resultat de sudo fdisk -l donne donc
Disque /dev/sda : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 1B81A42F-B528-4F05-A12B-5E0E0ED4AD12
Périphérique Start Fin Secteurs Size Type
/dev/sda1 2048 1050623 1048576 512M EFI System
/dev/sda2 1050624 1920208895 1919158272 915,1G Linux filesystem
/dev/sda3 1920208896 1953523711 33314816 15,9G Partition d'échange Linux
Disque /dev/sdb : 29,6 GiB, 31784435712 octets, 62078976 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0004b81d
Périphérique Amorçage Start Fin Secteurs Size Id Type
/dev/sdb1 * 2048 62074879 62072832 29,6G b W95 FAT32
Disque /dev/sdc : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: AECE1C56-60D7-4C61-ABCB-6127CD29975C
Périphérique Start Fin Secteurs Size Type
/dev/sdc1 65536 42008576 41943041 20G Microsoft basic data
/dev/sdc2 42008584 3907029106 3865020523 1,8T Microsoft basic data
puis :
ubuntu@ubuntu:~$ sudo blkid | grep sdc
/dev/sdc1: UUID="f3aaf588-9714-38b6-870a-7b38754b4c47" TYPE="linux_raid_member" PARTLABEL="primary" PARTUUID="f2f31eb5-b49e-4b77-b7a4-6e072cec1e81"
/dev/sdc2: UUID="c1bbff60-7220-38ff-a3b0-2ffecda60d36" UUID_SUB="01843f89-0822-55c3-2f6d-07ab70d536ae" LABEL="ix2-3:1" TYPE="linux_raid_member" PARTLABEL="primary" PARTUUID="3f612759-aad3-4641-9f41-e8f54bbab08e"
la commande df -h | grep sdc ne me retourne rien.
Pour la dernière commande, le résultat est un peu long...
ubuntu@ubuntu:~$ sudo smartctl -s on -a /dev/sdc
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-21-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.14 (AF)
Device Model: ST2000DM001-9YN164
Serial Number: S1E13V10
LU WWN Device Id: 5 000c50 05ba039dd
Firmware Version: CC4B
User Capacity: 2.000.398.934.016 bytes [2,00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sun Oct 9 19:07:19 2016 UTC
==> WARNING: A firmware update for this drive may be available,
see the following Seagate web pages:
http://knowledge.seagate.com/articles/en_US/FAQ/207931en
http://knowledge.seagate.com/articles/en_US/FAQ/223651en
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF ENABLE/DISABLE COMMANDS SECTION ===
SMART Enabled.
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
See vendor-specific Attribute list for marginal Attributes.
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 592) seconds.
Offline data collection
capabilities: (0x73) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 234) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x3085) SCT Status supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 093 088 006 Pre-fail Always - 127586957
3 Spin_Up_Time 0x0003 096 095 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 099 099 020 Old_age Always - 1322
5 Reallocated_Sector_Ct 0x0033 051 051 036 Pre-fail Always - 64904
7 Seek_Error_Rate 0x000f 084 060 030 Pre-fail Always - 326971022
9 Power_On_Hours 0x0032 082 082 000 Old_age Always - 16314
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 99
183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0
184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0
187 Reported_Uncorrect 0x0032 001 001 000 Old_age Always - 341
188 Command_Timeout 0x0032 096 096 000 Old_age Always - 20 20 20
189 High_Fly_Writes 0x003a 099 099 000 Old_age Always - 1
190 Airflow_Temperature_Cel 0x0022 069 041 045 Old_age Always In_the_past 31 (2 83 31 21 0)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 86
193 Load_Cycle_Count 0x0032 057 057 000 Old_age Always - 86964
194 Temperature_Celsius 0x0022 031 059 000 Old_age Always - 31 (0 17 0 0 0)
197 Current_Pending_Sector 0x0012 100 092 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 092 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 10190h+08m+20.402s
241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 1389206958230
242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 152040399235349
SMART Error Log Version: 1
ATA Error Count: 340 (device log contains only the most recent five errors)
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.
Error 340 occurred at disk power-on lifetime: 16307 hours (679 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 40 ff ff ff 4f 00 2d+15:17:38.537 READ FPDMA QUEUED
60 00 f0 ff ff ff 4f 00 2d+15:17:38.537 READ FPDMA QUEUED
60 00 f0 ff ff ff 4f 00 2d+15:17:38.537 READ FPDMA QUEUED
60 00 f0 ff ff ff 4f 00 2d+15:17:38.537 READ FPDMA QUEUED
60 00 10 ff ff ff 4f 00 2d+15:17:38.536 READ FPDMA QUEUED
Error 339 occurred at disk power-on lifetime: 16307 hours (679 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 ff ff ff 4f 00 2d+14:59:48.858 READ FPDMA QUEUED
61 00 10 18 ba 90 41 00 2d+14:59:48.822 WRITE FPDMA QUEUED
61 00 68 90 ba 90 41 00 2d+14:59:48.822 WRITE FPDMA QUEUED
61 00 08 78 ba 90 41 00 2d+14:59:48.822 WRITE FPDMA QUEUED
60 00 08 ff ff ff 4f 00 2d+14:59:46.562 READ FPDMA QUEUED
Error 338 occurred at disk power-on lifetime: 16307 hours (679 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 ff ff ff 4f 00 2d+14:57:47.129 READ FPDMA QUEUED
60 00 08 d8 da 67 40 00 2d+14:57:47.119 READ FPDMA QUEUED
60 00 08 40 55 5e 40 00 2d+14:57:47.103 READ FPDMA QUEUED
60 00 20 b0 62 59 40 00 2d+14:57:47.100 READ FPDMA QUEUED
60 00 10 a0 62 59 40 00 2d+14:57:47.078 READ FPDMA QUEUED
Error 337 occurred at disk power-on lifetime: 16307 hours (679 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 20 ff ff ff 4f 00 2d+14:49:25.516 READ FPDMA QUEUED
60 00 00 ff ff ff 4f 00 2d+14:49:24.641 READ FPDMA QUEUED
60 00 80 ff ff ff 4f 00 2d+14:49:24.641 READ FPDMA QUEUED
60 00 20 ff ff ff 4f 00 2d+14:49:24.583 READ FPDMA QUEUED
60 00 80 ff ff ff 4f 00 2d+14:49:24.561 READ FPDMA QUEUED
Error 336 occurred at disk power-on lifetime: 16307 hours (679 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 20 ff ff ff 4f 00 2d+14:45:27.981 READ FPDMA QUEUED
60 00 f0 ff ff ff 4f 00 2d+14:45:27.981 READ FPDMA QUEUED
60 00 f0 ff ff ff 4f 00 2d+14:45:27.981 READ FPDMA QUEUED
60 00 00 ff ff ff 4f 00 2d+14:45:27.981 READ FPDMA QUEUED
60 00 08 58 cb 65 40 00 2d+14:45:27.974 READ FPDMA QUEUED
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
Par contre, je ne pourrai faire les mêmes opérations sur le deuxième disque que demain soir..
Merci de votre aide.
Hors ligne
#18 Le 09/10/2016, à 21:12
- jamesbad000
Re : Raid endommagé - tentative de récupération de données
Ok, donc comme je le suggérais dans mon message suivant, il faudrait installer la prise en charge du raid sur le live
sudo apt-get install mdadm
ensuite déconnecter le disk usb. Attendre 10 Seconde avant de le reconnecter.
Puis un nouveau
sudo lsblk -o SIZE,NAME,FSTYPE,LABEL,MOUNTPOINT
Pour voir s'il monte le raid en auto ou s'il va falloir le faire à la main
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne
#19 Le 09/10/2016, à 22:28
- EtienneMarc
Re : Raid endommagé - tentative de récupération de données
Ok, donc comme je le suggérais dans mon message suivant, il faudrait installer la prise en charge du raid sur le live
sudo apt-get install mdadm
ensuite déconnecter le disk usb. Attendre 10 Seconde avant de le reconnecter.
Puis un nouveausudo lsblk -o SIZE,NAME,FSTYPE,LABEL,MOUNTPOINT
Pour voir s'il monte le raid en auto ou s'il va falloir le faire à la main
Voilà le résultat (toujours sur le même disque - il faut que je récupère l'autre demain)
ubuntu@ubuntu:~$ sudo lsblk -o SIZE,NAME,FSTYPE,LABEL,MOUNTPOINT
SIZE NAME FSTYPE LABEL MOUNTPOINT
931,5G sda
512M ├─sda1 vfat
915,1G ├─sda2 ext4
15,9G └─sda3 swap [SWAP]
29,6G sdb iso9660 Ubuntu 16.04 LTS amd64
29,6G └─sdb1 vfat LiveUSB /cdrom
1,8T sdc
20G ├─sdc1 linux_raid_member
1,8T └─sdc2 linux_raid_member ix2-3:1
1024M sr0
1,3G loop0 squashfs /rofs
Hors ligne
#20 Le 09/10/2016, à 22:30
- EtienneMarc
Re : Raid endommagé - tentative de récupération de données
Question additionnelle à Bougron et jamesbad000
j'utilise un Ubuntu USB_Live pour ces tests . Est-ce que pour vous c'est très différent si je fais ces manip depuis mon Linux Mint (rosa) habituel ?
Merci de votre aide.
Hors ligne
#21 Le 09/10/2016, à 22:44
- jamesbad000
Re : Raid endommagé - tentative de récupération de données
Voilà le résultat (toujours sur le même disque - il faut que je récupère l'autre demain)
- De toute façon terminons les analyse sur ce disque. (Qui au demeurant semble avoir un coup de fatigue au vu du nombre de secteurs réaloués qui apparaisent dans le résultat de smartctl...)
- Pour mint, je ne saurais répondre a priori...
- En attendant, que donne
sudo mdadm --misc /dev/sdc2 -E
sudo mdadm -A /dev/md0 /dev/sdc2
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne
#22 Le 09/10/2016, à 23:07
- EtienneMarc
Re : Raid endommagé - tentative de récupération de données
EtienneMarc a écrit :Voilà le résultat (toujours sur le même disque - il faut que je récupère l'autre demain)
- De toute façon terminons les analyse sur ce disque. (Qui au demeurant semble avoir un coup de fatigue au vu du nombre de secteurs réaloués qui apparaisent dans le résultat de smartctl...)
- Pour mint, je ne saurais répondre a priori...
- En attendant, que donne
sudo mdadm --misc /dev/sdc2 -E sudo mdadm -A /dev/md0 /dev/sdc2
Ok.
Bon, comme j'ai redémarré ma session USB_Live, mon disque RAID est maintenant en sda
j'ai adapté les lignes de commandes.
ubuntu@ubuntu:~$ sudo mdadm --misc /dev/sda2 -E
/dev/sda2:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
Array UUID : c1bbff60:722038ff:a3b02ffe:cda60d36
Name : ix2-3:1
Creation Time : Thu Dec 6 00:43:25 2012
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 3865020248 (1842.99 GiB 1978.89 GB)
Array Size : 1932510124 (1842.99 GiB 1978.89 GB)
Super Offset : 3865020504 sectors
Unused Space : before=0 sectors, after=256 sectors
State : clean
Device UUID : 01843f89:082255c3:2f6d07ab:70d536ae
Update Time : Sat Sep 3 12:40:11 2016
Checksum : 6c89398b - correct
Events : 775222
Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
et
ubuntu@ubuntu:~$ sudo mdadm -A /dev/md0 /dev/sda2
mdadm: /dev/md0 assembled from 1 drive - need all 2 to start it (use --run to insist).
Hors ligne
#23 Le 09/10/2016, à 23:18
- jamesbad000
Re : Raid endommagé - tentative de récupération de données
Ok ca à l'air pas mal. Mais on doit visiblement forcer le démarrage du raid avec le disque en moins
donc on recommence avec une option de plus
sudo mdadm -A --run /dev/md0 /dev/sda2
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne
#24 Le 09/10/2016, à 23:26
- Bougron
Re : Raid endommagé - tentative de récupération de données
Question additionnelle à Bougron et jamesbad000
j'utilise un Ubuntu USB_Live pour ces tests . Est-ce que pour vous c'est très différent si je fais ces manip depuis mon Linux Mint (rosa) habituel ?
Merci de votre aide.
Bonsoir
Tu peux (tu dois) travailler avec ton ubuntu standard (Mint). Ton disque interne n'a pas de problème. C'est ton disque externe qui a un problème.
Jamesbond0007 te fait installer le logiciel de gestion d'un raids. Autant le faire avec le ubuntu installé car il n'est pas certain que la clé USB soit persistante..... Si cela marche.... c'est beaucoup plus simple. Puisque ce disque n'est pas encore complétement HS.
S'il est duplicable logiquement, Cela sera parfait.
Je n'interviens pas sur les conseils MDADM que je connais quasiment pas. https://forum.ubuntu-fr.org/viewtopic.php?id=1997683
J'ai cependant noté son très mauvais état.
5 Reallocated_Sector_Ct 0x0033 051 051 036 Pre-fail Always - 64904
Dernière modification par Bougron (Le 09/10/2016, à 23:32)
Hors ligne
#25 Le 09/10/2016, à 23:32
- jamesbad000
Re : Raid endommagé - tentative de récupération de données
@Bougron J'ai noté les secteurs réaloués...
Pour le moment on est sur la bonne voie. Inutile de venir expérimenter les différences entre ubuntu et Mint. Donc je suggère de poursuit sur la clef usb pour le moment.
EtienneMarc pourra toujours vérifier a postéri s'il peut reproduire les manip qu'on vient de faire avec mint
Dernière modification par jamesbad000 (Le 09/10/2016, à 23:34)
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne