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.

#26 Le 09/10/2016, à 23:51

EtienneMarc

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

jamesbad000 a écrit :

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

C'est magique !
Avec cette commande, mon disque monte et j'ai accès au contenu (mes +/- 100.000 photos) :-)
Même si 'imagine que s'il y a des secteurs défectueux, certains fichiers sont compromis.

Demain, je fais les mêmes opérations avec l'autre disque, que je posterai dès que possible.

Merci

Hors ligne

#27 Le 09/10/2016, à 23:57

jamesbad000

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

PS:  il faut éviter au maximum de faire tourner ce disque pour rien (en attendant d'être rassuré sur l'état de l'autre disque). Vu que celui ci  semble sur la pente descendante...


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#28 Le 09/10/2016, à 23:58

EtienneMarc

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

Bougron a écrit :

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.

[....]

J'ai cependant noté son très mauvais état.
5 Reallocated_Sector_Ct   0x0033   051   051   036    Pre-fail  Always       -       64904


Ma clé n'est effectivement pas persistante, je crois que c'est lié aux options de boot UEFI sur ma machine (et du coup c'est un peu chiant de tout remettre à chaque fois - mais c'est un autre problème !). L'utilisation de ma config habituelle (Mint) dev rait me simplifier la vie :-)

Merci

Hors ligne

#29 Le 10/10/2016, à 21:28

EtienneMarc

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

Je continue donc sur ma Ubuntu USB_Live et voici le résultat de toutes les commandes exécutées hier sur l'autre disque :

sudo parted -l
Cela retourne une erreur (que je fasse I ou R, je ne peux pas en sortir)

ubuntu@ubuntu:~$ sudo parted -l
Modèle: ATA ST1000LM024 HN-M (scsi)
Disque /dev/sdb : 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/sdc : 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


Avertissement: Erreur de synchronisation/fermeture /dev/sdd1: Erreur
d'entrée/sortie sur l'hôte cible
Réessayer/Retry/Ignorer/Ignore?                                           

sudo lsblk -o SIZE,NAME,FSTYPE,LABEL,MOUNTPOINT

ubuntu@ubuntu:~$ sudo lsblk -o SIZE,NAME,FSTYPE,LABEL,MOUNTPOINT
  SIZE NAME   FSTYPE            LABEL                  MOUNTPOINT
931,5G sdb                                             
  512M ├─sdb1 vfat                                     
915,1G ├─sdb2 ext4                                     
 15,9G └─sdb3 swap                                     [SWAP]
 29,6G sdc    iso9660           Ubuntu 16.04 LTS amd64 
 29,6G └─sdc1 vfat              LiveUSB                /cdrom
  1,8T sdd                                             
   20G ├─sdd1 linux_raid_member                        
  1,8T └─sdd2                                          
 1024M sr0                                             
  1,3G loop0  squashfs                                 /rofs

sudo fdisk -l

ubuntu@ubuntu:~$ sudo fdisk -l
Disque /dev/ram0 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram1 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram2 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram3 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram4 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram5 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram6 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram7 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram8 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram9 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram10 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram11 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram12 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram13 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram14 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/ram15 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes


Disque /dev/loop0 : 1,3 GiB, 1433468928 octets, 2799744 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 512 Bytes
I/O Größe (minimal/optimal): 512 Bytes / 512 Bytes




Disque /dev/sdb : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Typ der Medienbezeichnung: gpt
Medienkennung: 1B81A42F-B528-4F05-A12B-5E0E0ED4AD12

Périphérique      Start        Fin   Secteurs Größe Type
/dev/sdb1          2048    1050623    1048576   512M EFI System
/dev/sdb2       1050624 1920208895 1919158272 915,1G Linux filesystem
/dev/sdb3    1920208896 1953523711   33314816  15,9G Partition d'échange Linux


Disque /dev/sdc : 29,6 GiB, 31784435712 octets, 62078976 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 512 Bytes
I/O Größe (minimal/optimal): 512 Bytes / 512 Bytes
Typ der Medienbezeichnung: dos
Medienkennung: 0x0004b81d

Périphérique Amorçage Start      Fin Secteurs Größe Id Type
/dev/sdc1    *         2048 62074879 62072832 29,6G  b W95 FAT32


Disque /dev/sdd : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 33553920 Bytes
Typ der Medienbezeichnung: gpt
Medienkennung: 79D3FF8F-F2FB-4F10-A50D-4737800C3E39

Périphérique    Start        Fin   Secteurs Größe Type
/dev/sdd1       65536   42008576   41943041   20G Microsoft basic data
/dev/sdd2    42008584 3907029106 3865020523  1,8T Microsoft basic data

sudo blkid | grep sdd

ubuntu@ubuntu:~$ sudo blkid | grep sdd
/dev/sdd1: UUID="f3aaf588-9714-38b6-870a-7b38754b4c47" TYPE="linux_raid_member" PARTLABEL="primary" PARTUUID="689052f8-fbae-4f4d-b8ed-196dd523e3b5"

df -h | grep sdd ne retourne rien

sudo smartctl    -s   on   -a   /dev/sdd

ubuntu@ubuntu:~$ sudo smartctl    -s   on   -a   /dev/sdd
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:    S1E13TJK
LU WWN Device Id: 5 000c50 05ba09209
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:    Mon Oct 10 19:19:53 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: 		(  584) 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: 	 ( 233) 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   101   099   006    Pre-fail  Always       -       117598002
  3 Spin_Up_Time            0x0003   095   094   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   099   099   020    Old_age   Always       -       1277
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       1136
  7 Seek_Error_Rate         0x000f   085   060   030    Pre-fail  Always       -       377246060
  9 Power_On_Hours          0x0032   080   080   000    Old_age   Always       -       17537
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       70
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       -       142
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       2 2 2
189 High_Fly_Writes         0x003a   098   098   000    Old_age   Always       -       2
190 Airflow_Temperature_Cel 0x0022   069   038   045    Old_age   Always   In_the_past 31 (10 255 31 28 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       -       60
193 Load_Cycle_Count        0x0032   057   057   000    Old_age   Always       -       86841
194 Temperature_Celsius     0x0022   031   062   000    Old_age   Always       -       31 (0 17 0 0 0)
197 Current_Pending_Sector  0x0012   099   099   000    Old_age   Always       -       286
198 Offline_Uncorrectable   0x0010   099   099   000    Old_age   Offline      -       286
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       11426h+38m+41.511s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       28217392130936
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       151519062630933

SMART Error Log Version: 1
ATA Error Count: 843 (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 843 occurred at disk power-on lifetime: 17537 hours (730 days + 17 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      00:06:05.146  READ FPDMA QUEUED
  60 00 08 ff ff ff 4f 00      00:06:05.121  READ FPDMA QUEUED
  60 00 20 08 00 00 40 00      00:06:05.121  READ FPDMA QUEUED
  60 00 08 00 00 00 40 00      00:06:05.121  READ FPDMA QUEUED
  60 00 08 80 ff 80 42 00      00:06:04.901  READ FPDMA QUEUED

Error 842 occurred at disk power-on lifetime: 17537 hours (730 days + 17 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      00:06:05.146  READ FPDMA QUEUED
  60 00 08 ff ff ff 4f 00      00:06:05.121  READ FPDMA QUEUED
  60 00 20 08 00 00 40 00      00:06:05.121  READ FPDMA QUEUED
  60 00 08 00 00 00 40 00      00:06:05.121  READ FPDMA QUEUED
  60 00 08 80 ff 80 42 00      00:06:04.901  READ FPDMA QUEUED

Error 841 occurred at disk power-on lifetime: 17537 hours (730 days + 17 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 00 00 00 40 00      00:03:32.689  READ FPDMA QUEUED
  60 00 01 ff ff ff 4f 00      00:03:32.688  READ FPDMA QUEUED
  60 00 01 ff ff ff 4f 00      00:03:32.687  READ FPDMA QUEUED
  60 00 01 87 ff 80 42 00      00:03:32.687  READ FPDMA QUEUED
  60 00 01 ff ff ff 4f 00      00:03:32.687  READ FPDMA QUEUED

Error 840 occurred at disk power-on lifetime: 17537 hours (730 days + 17 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 00 00 00 40 00      00:03:32.689  READ FPDMA QUEUED
  60 00 01 ff ff ff 4f 00      00:03:32.688  READ FPDMA QUEUED
  60 00 01 ff ff ff 4f 00      00:03:32.687  READ FPDMA QUEUED
  60 00 01 87 ff 80 42 00      00:03:32.687  READ FPDMA QUEUED
  60 00 01 ff ff ff 4f 00      00:03:32.687  READ FPDMA QUEUED

Error 839 occurred at disk power-on lifetime: 17537 hours (730 days + 17 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      00:03:32.045  READ FPDMA QUEUED
  60 00 08 80 ff 80 42 00      00:03:32.020  READ FPDMA QUEUED
  60 00 08 ff ff ff 4f 00      00:03:32.019  READ FPDMA QUEUED
  ec 00 01 00 00 00 00 00      00:03:32.016  IDENTIFY DEVICE
  25 03 08 00 10 00 40 00      00:03:32.000  READ DMA EXT

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.

ensuite, j'installe sudo apt-get install mdadm

sudo lsblk -o SIZE,NAME,FSTYPE,LABEL,MOUNTPOINT

ubuntu@ubuntu:~$ sudo lsblk -o SIZE,NAME,FSTYPE,LABEL,MOUNTPOINT
  SIZE NAME               FSTYPE            LABEL                  MOUNTPOINT
  1,8T sda                                                         
   20G ├─sda1             linux_raid_member                        
   20G │ └─md0            LVM2_member                              
    4G │   ├─md0_vg-BFDlv ext2                                     
   16G │   └─md0_vg-vol1  xfs                                      
  1,8T └─sda2                                                      
931,5G sdb                                                         
  512M ├─sdb1             vfat                                     
915,1G ├─sdb2             ext4                                     
 15,9G └─sdb3             swap                                     [SWAP]
 29,6G sdc                iso9660           Ubuntu 16.04 LTS amd64 
 29,6G └─sdc1             vfat              LiveUSB                /cdrom
 1024M sr0                                                         
  1,3G loop0              squashfs                                 /rofs

sudo mdadm --misc /dev/sda2 -E

ubuntu@ubuntu:~$ sudo mdadm --misc /dev/sda2 -E
mdadm: No md superblock detected on /dev/sda2.

sudo mdadm -A /dev/md0 /dev/sda2

ubuntu@ubuntu:~$ sudo mdadm -A /dev/md0 /dev/sda2
mdadm: no recogniseable superblock on /dev/sda2
mdadm: /dev/sda2 has no superblock - assembly aborted

J'en deduis qu'il n'arrive pas à lire la partie sda2 ?

Merci de votre aide

Hors ligne

#30 Le 10/10/2016, à 21:53

jamesbad000

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

Hello.

Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes

Original ce pc cause en  4 langues (et 3 alphabets) différents en 2 phrases. En fait c'est pas ROSA ta version c'est "au nom de la rose"

A par ça je suis au regret de d'annoncer que l'état de ce disque est bien pire que l'autre : Il a moins de secteurs réalloués, mais en revanche il a 286 secteurs en attente de réallocation. Ce qui est nettement plus rédhibitoire.
==> Les secteurs réalloués correspondent a des secteurs de réserve qui ont été utilisés pour se substituer à des secteurs qui posaient des problèmes de lectures écriture (Pas de perte de données, mais la quantité élevée laisse présager des problèmes à +- cours terme)

Les secteurs en attentes de réallocation sont des secteurs que le disque n'a absolument pas réussi à lire pour déplacer les données sur un secteur de réserve. (Ca peut changer, mais vu la quantité...)

Donc déjà déconnecte ce disque, le temps que je t'expose les différentes stratégies possible  (+rapide ou +sur)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#31 Le 10/10/2016, à 22:02

EtienneMarc

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

jamesbad000 a écrit :

Hello.

Unités : секторов of 1 * 512 = 512 octets
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes

Original ce pc cause en  4 langues (et 3 alphabets) différents en 2 phrases. En fait c'est pas ROSA ta version c'est "au nom de la rose"

Là je suis avec Ubuntu USB_Live (le même qu'hier mais non persistant)

Pour les strategies possibles, pas de soucis,je ne suis pas si pressé maintenant que je sais que TOUT n'est pas perdu sur l'autre disque.
Sur mes 2 To, j'ai environ 600 Gb de photos, qui sont la partie la plus importante à récupérer.

(je pensais néammoins que mes DD Seagate Barracuda étaient de meilleure qualité - car ils ont à peine 3 ans)

Merci !

Hors ligne

#32 Le 10/10/2016, à 22:15

EtienneMarc

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

je ne sais pas si ça aide, mais depuis ma Mint Rosa, le

sudo parted -l donne ça :

myself@myself-N550JK ~ $ sudo parted -l
[sudo] password for myself: 
Modèle: ATA ST1000LM024 HN-M (scsi)
Disque /dev/sda : 1000GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : gpt

Numéro  Début   Fin     Taille  Système de fichiers  Nom  Fanions
 1      1049kB  538MB   537MB   fat32                     démarrage
 2      538MB   983GB   983GB   ext4
 3      983GB   1000GB  17,1GB  linux-swap(v1)


Modèle: ASMedia AS2115 (scsi)
Disque /dev/sdc : 2000GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : gpt

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


Modèle: Mappeur de périphériques Linux (linear) (dm)
Disque /dev/mapper/md0_vg-BFDlv : 4295MB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : loop

Numéro  Début  Fin     Taille  Système de fichiers  Fanions
 1      0,00B  4295MB  4295MB  ext2


Modèle: Mappeur de périphériques Linux (linear) (dm)
Disque /dev/mapper/md0_vg-vol1 : 17,2GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : loop

Numéro  Début  Fin     Taille  Système de fichiers  Fanions
 1      0,00B  17,2GB  17,2GB  xfs


Erreur: Impossible d'ouvrir /dev/md0 - étiquette de disque non reconnue.

Hors ligne

#33 Le 10/10/2016, à 22:16

EtienneMarc

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

EtienneMarc a écrit :

je ne sais pas si ça aide, mais depuis ma Mint Rosa, le

sudo parted -l donne ça :

myself@myself-N550JK ~ $ sudo parted -l
[sudo] password for myself: 
Modèle: ATA ST1000LM024 HN-M (scsi)
Disque /dev/sda : 1000GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : gpt

Numéro  Début   Fin     Taille  Système de fichiers  Nom  Fanions
 1      1049kB  538MB   537MB   fat32                     démarrage
 2      538MB   983GB   983GB   ext4
 3      983GB   1000GB  17,1GB  linux-swap(v1)


Modèle: ASMedia AS2115 (scsi)
Disque /dev/sdc : 2000GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : gpt

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


Modèle: Mappeur de périphériques Linux (linear) (dm)
Disque /dev/mapper/md0_vg-BFDlv : 4295MB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : loop

Numéro  Début  Fin     Taille  Système de fichiers  Fanions
 1      0,00B  4295MB  4295MB  ext2


Modèle: Mappeur de périphériques Linux (linear) (dm)
Disque /dev/mapper/md0_vg-vol1 : 17,2GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : loop

Numéro  Début  Fin     Taille  Système de fichiers  Fanions
 1      0,00B  17,2GB  17,2GB  xfs


Erreur: Impossible d'ouvrir /dev/md0 - étiquette de disque non reconnue.

et la commande suivante :

myself@myself-N550JK ~ $ sudo lsblk -o SIZE,NAME,FSTYPE,LABEL,MOUNTPOINT
  SIZE NAME                      FSTYPE            LABEL MOUNTPOINT
931,5G sda                                               
  512M ├─sda1                    vfat                    /boot/efi
915,1G ├─sda2                    ext4                    /
 15,9G └─sda3                    swap                    [SWAP]
  1,8T sdc                                               
   20G ├─sdc1                    linux_raid_member       
   20G │ └─md0                   LVM2_member             
    4G │   ├─md0_vg-BFDlv (dm-0) ext2                    
   16G │   └─md0_vg-vol1 (dm-1)  xfs                     
  1,8T └─sdc2                    LVM2_member             
 1024M sr0    

Hors ligne

#34 Le 10/10/2016, à 23:17

jamesbad000

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

Bon ces dernières info n'apportent pas grand chose de plus.

Si ce n'est que l'apparition d'un système de fichier LVM sur sdc2 me fait un peu tiquer.
Ca peut résulter d'une lecture partielle (quand même assez probable au vu des différents éléments).
Ou bien de l'écrasement réel de tout ou partie des données. Le "tout" étant  assez improbable sans que tu en sois informé, car ça aurait forcément prit de temps. Donc à moins que tu pense qu'une telle chose ait pu avoir lieu, je vais ignorer ce point

En terme de stratégie de récup donc :
La méthode rapide c'est de revenir à la situation d'hier soir sur l'autre disque et de lancer une simple copie de l'arborescence de répertoire vers un autre disque sain (la place nécessaire pour recevoir la copie étant égale au volume occupé sur le disque source.
Le risque de cette méthode est que ce disque qui montre quand même des signes inquiétant commence à poser des problème en cours de copie et oblige à passer sur la 2 ème méthode en ayant diminué les chances de récupérer intégralement par la 2ème méthode. Puisqu'il va falloir solliciter à nouveau le disque pour relire les même données...

La méthode plus fiable c'est celle proposée par bougron. Copie intégrale de la partition sur un autre disque, à partir du disque en meilleurs état dans un 1er temps avec ddrescue. Puis si copie incomplète, on peut boucher les trous avec ce qui est lisible sur l'autre disque (fonctionnalité de ddrescue) (Et ensuite faire des passes supplémentaire avec chacun des 2 disques pour insister sur d'éventuels secteurs illisibles). Auquel cas il te faut absolument 1,8To mini

Dernière modification par jamesbad000 (Le 10/10/2016, à 23:20)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#35 Le 10/10/2016, à 23:20

Bougron

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

Bonsoir.

Je suis l'évolution. J'utilise actuellement un ipad. c'est moins pratique pour les copier/coller.
L'implantation des deux partitions du premier disque est
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

L'implantation des deux partitions du second disque est
/dev/sdd1       65536   42008576   41943041   20G Microsoft basic data
/dev/sdd2    42008584 3907029106 3865020523  1,8T Microsoft basic datac

Les implantations sont identiques. c'est ce que je voulais verifier.
.
on peut donc dupliquer le disque afin de conserver la structure raids sur le nouveau disque neuf.

J'ai noté que les partitions étaient formatées ntfs.....

Dernière modification par Bougron (Le 10/10/2016, à 23:39)

Hors ligne

#36 Le 11/10/2016, à 00:27

jamesbad000

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

bougron a écrit :

on peut donc dupliquer le disque afin de conserver la structure raids sur le nouveau disque neuf.

J'avais proposé de ne copier que la partition. Mais effectivement ça ne coute pas beaucoup plus cher. Et c'est nécessaire   si on a pour objectifs de remonter une config raid...

bougron a écrit :

J'ai noté que les partitions étaient formatées ntfs.....

Ca par contre je vois pas où. A ma connaissance on n'a jamais vu le contenu du volume raid après montage


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#37 Le 11/10/2016, à 09:15

Bougron

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

Bonjour à vous
D'abord, la réponse de FDISK:   Pour moi les deux partitions semblent bien en structure  NTFS et non EXTn
Mais très certainement à la norme windows à base de volume logique pour fonctionner en RAIDS. Ce qui expliquerait la vision de MINT 

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/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

J'ai regardé un peu le fonctionnement du lenovo
En théorie, il a la fonctionnalité 'With automatic RAIDS rebuild'
Je ne sais pas trop ce que cela signifie:
    On enlève le disque HS , on met un disque neuf, et il refabrique à partir de l'autre.
    Mais il a seulement proposé de formater si j'ai bien compris.
   Est-ce parce qu'il a considéré que l'autre disque était trop usagé et il ne voulait pas prendre ce risque?

Il a la fonctionnalité JBOD
Je suis incapable de savoir si après avoir migré en JBOD, il est capable de revenir en RAID sans redemander un formatage.

Je pense que tu vas vouloir remettre en route le RAID. Je propose l'achat d'un disque de taille au moins égale à 2TO
De mettre ce disque neuf à la place des deux disques qui d'ailleurs ne sont plus présent dans le Lenovo.
Puis de voir s'il est possible d'activer ce RAIDS  avec un seul disque, Si non, on le migre en JBOD.

Puis on pourra dupliquer.   La duplication ne doit absolument pas se faire avec une commande dd ou quelque chose de semblable pour trois raisons
    1) La durée de duplication peut aller de 24 heures à 10 jours et il n'est pas équipé de commande de reprise si arrêt accidentel.
           DD n'a pas la possibilité de suivi. Mais il y en a d'autres qui ont cette possibilité.
   2) Le plus important
        Pas mal d'utilitaires veulent lire un secteur N, S'ils ne peuvent pas le lire, ils insistent énormément avant de déclarer que le secteur est illisible. C'est comme cela que j'ai vu une destruction du disque se finir pendant une duplication par mécanique HS.
3)  Si Cela ne fonctionne pas du premier coup, il faut relancer en indiquant en paramètre le CI de reprise sans se tromper.
         Ce qui est automatique avec DDRESCUE.

Cependant on peut aussi choisir de dupliquer sur un disque externe classique et mettre deux disques neufs dans le Lenovo et reconstituer plus tard le RAIDS  (matériel? Logiciel?) à partir du disque NEUF.

Il est bon de se rappeler que les deux disques sont àgés de 16314 heures et 17737 heures.   
Que le premier disque a déjà détecté 64904 secteurs dont la lecture était très difficile et méritaient d'être remplacé. Chose qu'il a pu faire.
Il est certain qu'il va en découvrir d'autres pendant la phase de lecture de la totalité du disque. Il va vouloir réparer si lecture standard.
Que le second disque a déjà détecté 1422 secteurs dont la lecture était très difficile et méritaient d'être remplacé. Chose qu'il a pu faire pour 1136 d'entre  eux  mais pas pour 286.  Dont très certainement quelques-uns contenant la description de la structure des fichiers.

Dernière modification par Bougron (Le 11/10/2016, à 09:34)

Hors ligne

#38 Le 11/10/2016, à 21:04

EtienneMarc

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

Bon, si j'ai bien compris :

  • Il me faut tout d'abord un nouveau disque de 2 To.

  • Comme j'envisage de remonter mon NAS en RAID, il m'en faut aussi un 2eme...


Comme je serais assez partisan de dupliquer sur un disque externe classique et mettre deux disques neufs dans le Lenovo et reconstituer plus tard le RAID à partir du disque NEUF.

  • J'acheterais 2 disques (identiques suivant les recos Lenovo), on considérerait le premier comme le "disque externe classique" (sur un deuxième port USB).

  • Une fois les données récupérées, en passant par le cloud ou mon PC perso (1To), je sauverais mes données

  • Et je mets en suite les 2 nouveaux disques dans le NAS pour refaire un RAID vide,

  • Sur lequel je re-transférerais mes données.

Est-ce que c'est jouable ou complètement débile ?

Avez-vous un conseil à me donner sur la marque/modèle à choisir ?

Mais je ne me rends peut être pas bien compte, mais c'est beaucoup  16314 heures et 17737 heures pour des disques durs ? Moins de 2 ans, cela me semble court.
(c'est juste une question - je comprends qu'ils sont désormais trop abîmés pour pouvoir se reposer dessus). Et quel avenir pour ces disques ? Est-ce qu'il est raisonnable de les recycler en disques externes ?

Merci de votre aide et vos avis !

Hors ligne

#39 Le 11/10/2016, à 21:50

Bougron

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

Bonsoir.
Je vois que tu joues la sécurité en dupliquant d'abord sur un disque externe.
et  que ce disque externe tu le sauvegardera logiquement avant de le réintégrer dans le NAS.
Il faut maintenant que tes deux disques (l'usagé) et le neuf soient accessibles simultanément

Pour les disques,  Tu es dans une bonne moyenne car ils ont dépassés 10000 heures. https://forum.ubuntu-fr.org/viewtopic.p … #p21605194

Pour les vieux disques, tu peux les reformater et les utiliser en RAIDS1 logiciel avec MDADM.

Voici un cas récent https://forum.ubuntu-fr.org/viewtopic.p … #p21604703
J'en ai rencontré aussi un de 8 To de début d'année avec seulement 1 mois au compteur https://forum.ubuntu-fr.org/viewtopic.p … #p21289521



Voici un ajout sur la durée de vie des disques   http://www.lesnumeriques.com/disque-dur … 38879.html

Dernière modification par Bougron (Le 13/10/2016, à 19:17)

Hors ligne

#40 Le 11/10/2016, à 21:59

EtienneMarc

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

qund je sidais passer 95% de 2TO sur 1 To, c'est en faisant du ménage, et en stockant des en plus des fichiers sur des espaces temporaires.

Mon idée est d'utiliser un de deux futurs nouveaux disques pour faire la duplication physique puis le vider (vers mon PC et d'autres espaces de stockage) pour le mettre ensuite avec son jumeau dans le NAS en RAID
(ca permet d'acheter 2 disques 2To au lieu de 3 smile  )

Hors ligne

#41 Le 13/10/2016, à 22:05

EtienneMarc

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

Bon

je devrais avoir mes 2 nouveaux DD de 2 To demain soir ou samedi matin. (Western Digital RED 2To)
J'espère trouver également un adaptateur SATA USB supplémentaire !

Bonne soirée

Hors ligne

#42 Le 14/10/2016, à 00:28

Bougron

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

Bonsoir.

La codification sera donc de commencer par:

Faire la copie des secteurs de bonne qualité du premier disque usagé que je nomme sdb sur le disque neuf que je nomme sdc

    sudo ddrescue          -f -n -b4096 -c63  /dev/sdb   /dev/sdc /home/%USER/ddsuivi
    sudo ddrescue      -d -f -r0 -b4096 -c1   /dev/sdb   /dev/sdc /home/%USER/ddsuivi
    sudo ddrescue   -R -d -f -r0 -b4096 -c1   /dev/sdb   /dev/sdc /home/%USER/ddsuivi

Puis démonter le disque sdb et monter le second disque usagé. S'assurer qu'il s'appelle bien sdb et que le fichier de suivi est toujours présent et continuer la copie des secteurs de bonne qualité.

    sudo ddrescue      -d -f -r0 -b4096 -c1   /dev/sdb   /dev/sdc /home/%USER/ddsuivi
    sudo ddrescue   -R -d -f -r0 -b4096 -c1   /dev/sdb   /dev/sdc /home/%USER/ddsuivi

Puis on fait le point pour voir si tout est copié ou si il y a encore des secteurs à copier.

    sudo ddrescuelog -l-     -b4096     /home/%USER/ddsuivi    > /home/%USER/ddbadblocs
    cat /home/%USER/ddbadblocs

Puis on s'attaque aux mauvais blocks directement avec ce même disque, D'abord, il est monté, et puis sa mécanique me semble moins usée.
Dans ce contexte, la lecture va être beaucoup plus lente car le programme va exiger un résultat dans la mesure du possible.

sudo ddrescue      -d -f -r9 -b4096 -c1   /dev/sdb   /dev/sdc /home/%USER/ddsuivi
sudo ddrescue   -R -d -f -r9 -b4096 -c1   /dev/sdb   /dev/sdc /home/%USER/ddsuivi

De nouveau on regarde s'il y a encore des choses à faire, Si oui on permute les disques entrées et idem.

S'il reste encore des bads blocks, on peut remplacer r9   par r63 et retenter un passage sur les deux disques.
J'ai le souvenir d'une discussion qui a tenté et réussi à en récupérer 4 ou 5 avant de stopper car la durée était trop importante.

Après c'est l'étape finale, écrire les secteurs non recopiés.

sudo ddrescuelog -l-     -b4096     /home/%USER/ddsuivi    > /home/%USER/ddbadblocs
echo "SECTEUR ILLISIBLE On va marquer au fer rouge tous ces secteurs faussement défectueux afin de rechercher dans les fichiers ceux qui sont impactés par SECTEUR ILLISIBLE" >/home/%USER/ddmark
sudo sed 's|^|sudo dd if=/home/%USER/ddmark of=/dev/sdc bs=4096 count=1 seek=|'  /home/%USER/ddbadblocs>/home/%USER/ddecrire
pg /home/%USER/ddecrire

    exécuter le contenu du fichier /home/%USER/ddecrire

Puis regarder comment ce disque sortie se monte.

Dernière modification par Bougron (Le 23/10/2016, à 11:52)

Hors ligne

#43 Le 14/10/2016, à 22:53

EtienneMarc

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

Bonsoir,

J'ai mon nouveau disque de 2 To, un Western Digital RED.
Pour l'instant, je l'ai mis dans un boitier externe, branché sur mon PC (Ubuntu USB_Live) en USB.

Mon disque dur malade (Seagate) est aussi en USB avec un adaptateur.

Voici ce que me donne le sudo parted -l

ubuntu@ubuntu:~$ sudo parted -l
Model: ASMedia AS2115 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name     Flags
 1      33.6MB  21.5GB  21.5GB               primary  msftdata
 2      21.5GB  2000GB  1979GB               primary  msftdata


Model: ATA ST1000LM024 HN-M (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  538MB   537MB   fat32                 boot, esp
 2      538MB   983GB   983GB   ext4
 3      983GB   1000GB  17.1GB  linux-swap(v1)


Model: Multiple Card Reader (scsi)
Disk /dev/sdc: 31.8GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  31.8GB  31.8GB  primary  fat32        boot


Error: /dev/sdd: unrecognised disk label
Model: WDC WD20 EFRX-68EUZN0 (scsi)                                       
Disk /dev/sdd: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags:

et le sudo lsblk -o SIZE,NAME,FSTYPE,LABEL,MOUNTPOINT

ubuntu@ubuntu:~$ sudo lsblk -o SIZE,NAME,FSTYPE,LABEL,MOUNTPOINT
  SIZE NAME   FSTYPE            LABEL                  MOUNTPOINT
  1.8T sda                                             
   20G ├─sda1 linux_raid_member                        
  1.8T └─sda2 linux_raid_member ix2-3:1                
931.5G sdb                                             
  512M ├─sdb1 vfat                                     
915.1G ├─sdb2 ext4                                     
 15.9G └─sdb3 swap                                     [SWAP]
 29.6G sdc    iso9660           Ubuntu 16.04 LTS amd64 
 29.6G └─sdc1 vfat              LiveUSB                /cdrom
  1.8T sdd                                             
 1024M sr0                                             
  1.3G loop0  squashfs                                 /rofs


1 - Faut-il faire quelque chose au préalable sur le disque WD (le neuf) ? 
2 - chose etrange, si je fait la même chose sur mon Linux Mint, je ne vois pas le disque malade (ici sda...) En fait si, mais je ferai toutes les manips depuis ma Ubuntu USB_Live, ainsi, je suis sur d'avoir un environnement propre et standard

Quoiqu'il en soit, je m'arrête là pour ce soir, je n'ai pas la possibilité de continuer. Demain, je pourrai exécuter les commande de Bougron

Merci !

Dernière modification par EtienneMarc (Le 14/10/2016, à 23:00)

Hors ligne

#44 Le 15/10/2016, à 01:30

Bougron

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

Bonsoir.
Telle que tu présentes la situation:
   Le disque abîmé serait SDA    et le disque en réception serait SDD
Il n'y a rien à préparer pour le disque neuf car la commande ddrescue va tout détruire sur ce disque.
D'où l'importance de ne pas se tromper de disque au moment de la duplication.

Dernière modification par Bougron (Le 15/10/2016, à 01:32)

Hors ligne

#45 Le 17/10/2016, à 21:11

EtienneMarc

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

la première commande vient juste de se terminer ! (ouf, je devenais impatient après 2.28 jours...)

ubuntu@ubuntu:~$ sudo ddrescue          -f -n -b4096 -c63  /dev/sdc   /dev/sdd /home/ubuntu/dd/suivi
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued:     2000 GB,  errsize:  38236 kB,  current rate:    81920 B/s
   ipos:     1768 GB,   errors:     163,    average rate:   10131 kB/s
   opos:     1768 GB, run time:    2.28 d,  successful read:       0 s ago
Finished          

je continue avec la 2eme.

Hors ligne

#46 Le 17/10/2016, à 22:28

jamesbad000

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

Hello.
A vue de nez, il doit manquer 163 secteurs dans cette passe.
Avant d'en entamer un 3eme, je suggère de refaire un petit coup de smartctl pour voir comment évolu l'état du disque.

par ailleurs pour la prochaine passe, je suggère de mettre directement -r 10 pour faire directement 10 retry sur les secteurs endommagés avant de passer à l'autre disque. (En fin de compte ça serait mieux de tout récupérer d'un seul disque, car  il y a des meta données RAID qui vont différer d'un disque à l'autre, donc autant éviter une salade)

aussi donner le contenu du fichier de log

sudo cat /home/%USER/ddsuivi

ps -r 0 (0 retry sur un secteur qui n'a pu être lu) est la valeur par défaut. donc identique à la 1ère commande.

Dernière modification par jamesbad000 (Le 17/10/2016, à 23:01)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#47 Le 17/10/2016, à 23:50

EtienneMarc

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

jamesbad000 a écrit :

Hello.
A vue de nez, il doit manquer 163 secteurs dans cette passe.
Avant d'en entamer un 3eme, je suggère de refaire un petit coup de smartctl pour voir comment évolu l'état du disque.

par ailleurs pour la prochaine passe, je suggère de mettre directement -r 10 pour faire directement 10 retry sur les secteurs endommagés avant de passer à l'autre disque. (En fin de compte ça serait mieux de tout récupérer d'un seul disque, car  il y a des meta données RAID qui vont différer d'un disque à l'autre, donc autant éviter une salade)

aussi donner le contenu du fichier de log

sudo cat /home/%USER/ddsuivi

ps -r 0 (0 retry sur un secteur qui n'a pu être lu) est la valeur par défaut. donc identique à la 1ère commande.

Ok.
J'attends la fin de l'operation en cours (sudo ddrescue      -d -f -r0 -b4096 -c1   /dev/sdb   /dev/sdc /home/%USER/ddsuivi)
et je fais le smartctl.

pour la 3eme commande donnée par Bougron, je changerai -r 0 en -r 10 (c'est bien ça ?)

Merci

Hors ligne

#48 Le 18/10/2016, à 04:27

EtienneMarc

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

Voici le résultat de la 2eme commande :


ubuntu@ubuntu:~$ sudo ddrescue      -d -f -r0 -b4096 -c1   /dev/sdc   /dev/sdd /home/ubuntu/dd/suivi
GNU ddrescue 1.19
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:     2000 GB,  errsize:  38236 kB,  errors:     163

Current status
rescued:     2000 GB,  errsize:  25640 kB,  current rate:     4096 B/s
   ipos:     1537 GB,   errors:    1310,    average rate:      720 B/s
   opos:     1537 GB, run time:    4.85 h,  successful read:       0 s ago
Finished              

Hors ligne

#49 Le 18/10/2016, à 04:32

EtienneMarc

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

Et voici le retour de smartctl :

sudo smartctl    -s   on   -a   /dev/sdc

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:    Tue Oct 18 02:29:37 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   077   075   006    Pre-fail  Always       -       134675033
  3 Spin_Up_Time            0x0003   095   095   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   099   099   020    Old_age   Always       -       1346
  5 Reallocated_Sector_Ct   0x0033   051   051   036    Pre-fail  Always       -       64904
  7 Seek_Error_Rate         0x000f   084   060   030    Pre-fail  Always       -       327055630
  9 Power_On_Hours          0x0032   082   082   000    Old_age   Always       -       16379
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       103
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       -       9063
188 Command_Timeout         0x0032   100   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   073   041   045    Old_age   Always   In_the_past 27 (Min/Max 22/49 #595)
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       -       88
193 Load_Cycle_Count        0x0032   057   057   000    Old_age   Always       -       87004
194 Temperature_Celsius     0x0022   027   059   000    Old_age   Always       -       27 (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      -       10254h+02m+46.785s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       1389206976451
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       203373136848859

SMART Error Log Version: 1
ATA Error Count: 9031 (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 9031 occurred at disk power-on lifetime: 16377 hours (682 days + 9 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
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 03 08 ff ff ff 4f 00   2d+12:02:19.633  READ DMA EXT
  ef 03 46 d8 3d 09 00 00   2d+12:02:19.632  SET FEATURES [Set transfer mode]
  ef 03 0c d8 3d 09 00 00   2d+12:02:19.632  SET FEATURES [Set transfer mode]
  ec 03 08 d8 3d 09 00 00   2d+12:02:19.608  IDENTIFY DEVICE
  00 00 00 00 00 00 00 04   2d+12:02:19.527  NOP [Abort queued commands]

Error 9030 occurred at disk power-on lifetime: 16377 hours (682 days + 9 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
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 03 08 ff ff ff 4f 00   2d+12:02:16.965  READ DMA EXT
  ef 03 46 58 0a 8b 00 00   2d+12:02:16.965  SET FEATURES [Set transfer mode]
  ef 03 0c 58 0a 8b 00 00   2d+12:02:16.965  SET FEATURES [Set transfer mode]
  ec 03 08 58 0a 8b 00 00   2d+12:02:16.939  IDENTIFY DEVICE
  00 00 00 00 00 00 00 04   2d+12:02:16.882  NOP [Abort queued commands]

Error 9029 occurred at disk power-on lifetime: 16377 hours (682 days + 9 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+12:02:14.325  READ FPDMA QUEUED
  60 00 08 ff ff ff 4f 00   2d+12:02:13.733  READ FPDMA QUEUED
  25 03 08 ff ff ff 4f 00   2d+12:02:13.129  READ DMA EXT
  ef 03 46 50 0a 8b 00 00   2d+12:02:13.129  SET FEATURES [Set transfer mode]
  ef 03 0c 50 0a 8b 00 00   2d+12:02:13.129  SET FEATURES [Set transfer mode]

Error 9028 occurred at disk power-on lifetime: 16377 hours (682 days + 9 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
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 03 08 ff ff ff 4f 00   2d+12:02:10.454  READ DMA EXT
  ef 03 46 c0 09 8b 00 00   2d+12:02:10.453  SET FEATURES [Set transfer mode]
  ef 03 0c c0 09 8b 00 00   2d+12:02:10.453  SET FEATURES [Set transfer mode]
  ec 03 08 c0 09 8b 00 00   2d+12:02:10.383  IDENTIFY DEVICE
  00 00 00 00 00 00 00 04   2d+12:02:10.347  NOP [Abort queued commands]

Error 9027 occurred at disk power-on lifetime: 16377 hours (682 days + 9 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+12:02:07.772  READ FPDMA QUEUED
  25 03 08 ff ff ff 4f 00   2d+12:02:07.170  READ DMA EXT
  ef 03 46 a0 09 8b 00 00   2d+12:02:07.169  SET FEATURES [Set transfer mode]
  ef 03 0c a0 09 8b 00 00   2d+12:02:07.169  SET FEATURES [Set transfer mode]
  ec 03 08 a0 09 8b 00 00   2d+12:02:07.107  IDENTIFY DEVICE

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.

Hors ligne

#50 Le 18/10/2016, à 10:54

Bougron

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

Bonjour.
Effectivement , on peut tout tenter avec ce disque avant de passer au second disque

=====>   attention  les points de montages que j'ai   /dev/sdb et /dev/sdc ne sont toujours pas adaptés à ton contexte car d'après le smartctl , l'entrée est /dev/sdc et non /dev/sdb

1)  Liste pour savoir

  sudo ddrescuelog -l-     -b4096     /home/%USER/ddsuivi    > /home/%USER/ddbadblocs 
  cat /home/%USER/ddbadblocs

2)  Mais encore un passage en mode rapide par la droite avant de tenter les passages en force

   sudo ddrescue   -R -d -f -r0 -b4096 -c1   /dev/sdb   /dev/sdc /home/%USER/ddsuivi

=====>   ajout.   J'ai compris qu'il est en train de tourner
3) Puis les essais  répétitifs

 sudo ddrescue      -d -f -r10  -b4096  -c1   /dev/sdb   /dev/sdc /home/%USER/ddsuivi
 sudo ddrescue   -R -d -f -r10  -b4096  -c1   /dev/sdb   /dev/sdc /home/%USER/ddsuivi

4) Encore une liste pour savoir  comment est la liste des badblocks à la fin des opération; On va mémoriser cette liste avant de passer au second disque

  sudo ddrescuelog -l-     -b4096     /home/%USER/ddsuivi    > /home/%USER/ddbadblocs 
  cat /home/%USER/ddbadblocs
  cp   /home/%USER/ddbadblocs    /home/%USER/ddbadblocsDuPremierDisque

Un petit coup de smarctl sur ce disque et pourquoi pas aussi sur le disque récepteur.

et enfin passage au second disque si besoin


Pour info, Au premier passage il y a eu  169 erreurs de lectures Mais cela ne  représente pas 169 secteurs mais 169*63
Soit un total de  38236 kB   non récupérés.
Au second passage il y a eu beaucoup plus de zones non récupérées, Mais cette fois-ci l'unité de lecture est bien de 1 secteur physique.
Soit un total de  25640 kB non récupérés.    Donc ce passage a récupéré 12596 kB en moins de 5 heures.

Attendons donc le passage par la droite.

Dernière modification par Bougron (Le 18/10/2016, à 11:41)

Hors ligne