Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 13/09/2016, à 11: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, à 21:34)

Hors ligne

#2 Le 15/09/2016, à 21: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, à 08: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, à 10: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, à 21: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)

Voici ce que donne Gparted :
1474835658.png

(ou http://pix.toile-libre.org/?img=1474835658.png

Merci pour vos avis.

Dernière modification par EtienneMarc (Le 25/09/2016, à 21:42)

Hors ligne

#6 Le 26/09/2016, à 04: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, à 21: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, à 12: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, à 12:24)

Hors ligne

#9 Le 03/10/2016, à 20: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, à 22: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, à 22: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, à 22:52)

Hors ligne

#12 Le 03/10/2016, à 23: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, à 22: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 03/10/2016, à 23: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 03/10/2016, à 23:50)

Hors ligne

#14 Le 05/10/2016, à 00:33

jamesbad000

Re : Raid endommagé - tentative de récupération de données

Salut Bougron.

Bougron a écrit :

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, à 18: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, à 09: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, à 19:55

EtienneMarc

Re : Raid endommagé - tentative de récupération de données

jamesbad000 a écrit :

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, à 20:11

EtienneMarc

Re : Raid endommagé - tentative de récupération de données

Bougron a écrit :

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.

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, à 20: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, à 21:28

EtienneMarc

Re : Raid endommagé - tentative de récupération de données

jamesbad000 a écrit :

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



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, à 21: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, à 21:44

jamesbad000

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

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, à 22:07

EtienneMarc

Re : Raid endommagé - tentative de récupération de données

jamesbad000 a écrit :
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, à 22: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, à 22:26

Bougron

Re : Raid endommagé - tentative de récupération de données

EtienneMarc a écrit :

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, à 22:32)

Hors ligne

#25 Le 09/10/2016, à 22: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, à 22: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