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.

Pages : 1 2 3

#1 Le 05/07/2020, à 15:28

Finkelstein

Recuperation des données d'un HDD de NAS

Bonjour a tous,

Hier, mon NAS a rendu l'ame (RIP petit ange parti trop vite ...)
Mais je pense que c'est plutot la carte mere du NAS qui a cramé plutot que le disque dur a l'interieur.
Du coup, j'ai debranché le disque et l'ai mis dans un boitier externe pour le brancher sur mon PC mais lorsque j'essaye d'y accéder par Nautilus j'ai le message suivant :

Impossible d'afficher le contenu de cet emplacement.
Désolé, impossible d'afficher tout le contenu de "nom temporaire du disque dur externe" : Erreur lors de l'obtention 
des informations du fichier "un répertoire présent sur le NAS" : Erreur d'entrée/sortie

Une fois la popup validée, nautilus ne m'affiche rien (comme si le disque était vide)
Lorsque j'essaye de parcourir le disque dur via le terminal c'est un peu mieux, j'obtiens quelques messages

ls: impossible d’accéder a 'Nom d'un répertoire du Nas' : Erreur d'entrée/sortie

Mais tous les répertoires du NAS ne sont pas concernés (j'ai l'impression que ça ne concerne que les répertoire qui contiennent le plus de données : comme celui ou je stocke toute ma musique ou celui où je stocke toutes mes videos, etc ...
Et lorsque j'essaie d'accéder au répertoire qui remonte une erreur, ca me met le message

bash: cd: 'Nom du repertoire accedé': Erreur d'entrée/sortie

Pour les répertoires, qui ne remontent pas d'erreur, je peux y accéder sans problème via le terminal et ouvrir les fichiers qui s'y trouvent.

Est ce que je vais pouvoir récupérer mes données ? et comment ?

Merci de l'aide que vous pourrez m'apporter.

Dernière modification par Finkelstein (Le 05/07/2020, à 15:32)

Hors ligne

#2 Le 05/07/2020, à 20:26

geole

Re : Recuperation des données d'un HDD de NAS

Bonsoir.
réponse rapide de principe ce soir.
acheter un autre disque de taille au moins égale à celle du disque actuel afin d'y dupliquer ce qui sera lisible avec l'application ddrescue

Afin de voir les dégats, fais aussi un  smartctl sur le disque entrée

Dernière modification par geole (Le 05/07/2020, à 20:32)

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

En ligne

#3 Le 05/07/2020, à 23:04

Finkelstein

Re : Recuperation des données d'un HDD de NAS

j'ai passé la commande suivante 

sudo smartctl --scan | grep -i usb

et j'ai obtenu 

/dev/sdd -d usbjmicron # /dev/sdd [USB JMicron], ATA device

J'ai ensuite passé 

sudo smartctl -s on -a -d usbjmicron /dev/sdd

Pour obtenir

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda Green (AF)
Device Model:     ST2000DL003-9VT166
Serial Number:    5YDA0VRW
LU WWN Device Id: 5 000c50 0532faf48
Firmware Version: CC3C
User Capacity:    2000398934016 bytes [2,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5900 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: 1.5 Gb/s)
Local Time is:    Mon Jul  6 00:00:43 2020 CEST
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

General SMART Values:
Offline data collection status:  (0x82)	Offline data collection activity
					was completed without error.
					Auto Offline Data Collection: Enabled.
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: 		(  623) seconds.
Offline data collection
capabilities: 			 (0x7b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					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: 	 ( 366) minutes.
Conveyance self-test routine
recommended polling time: 	 (   2) minutes.
SCT capabilities: 	       (0x30b7)	SCT Status supported.
					SCT Feature Control supported.
					SCT Data Table 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   091   086   006    Pre-fail  Always       -       202544830
  3 Spin_Up_Time            0x0003   093   092   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   084   084   020    Old_age   Always       -       16890
  5 Reallocated_Sector_Ct   0x0033   070   070   036    Pre-fail  Always       -       19800
  7 Seek_Error_Rate         0x000f   062   060   030    Pre-fail  Always       -       958174026930
  9 Power_On_Hours          0x0032   024   011   000    Old_age   Always       -       67448
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       144
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       -       1012
188 Command_Timeout         0x0032   100   098   000    Old_age   Always       -       38655295498
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   073   051   045    Old_age   Always       -       27 (0 1 27 24 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       -       73
193 Load_Cycle_Count        0x0032   082   082   000    Old_age   Always       -       36058
194 Temperature_Celsius     0x0022   027   049   000    Old_age   Always       -       27 (128 0 0 0 0)
195 Hardware_ECC_Recovered  0x001a   023   006   000    Old_age   Always       -       202544830
197 Current_Pending_Sector  0x0012   084   001   000    Old_age   Always       -       1368
198 Offline_Uncorrectable   0x0010   084   001   000    Old_age   Offline      -       1368
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       23595 (165 122 0)
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       2285581834
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       1965015322

SMART Error Log Version: 1
ATA Error Count: 1000 (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 1000 occurred at disk power-on lifetime: 1911 hours (79 days + 15 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 00 08 ff ff ff ef 00      00:00:23.584  READ DMA EXT
  25 00 10 ff ff ff ef 00      00:00:23.583  READ DMA EXT
  25 00 f0 ff ff ff ef 00      00:00:23.560  READ DMA EXT
  25 00 02 b6 1d 12 e0 00      00:00:23.539  READ DMA EXT
  25 00 10 ff ff ff ef 00      00:00:23.537  READ DMA EXT

Error 999 occurred at disk power-on lifetime: 1911 hours (79 days + 15 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 00 08 ff ff ff ef 00      00:51:16.082  READ DMA EXT
  35 00 08 10 ce 1f e0 00      00:51:16.081  WRITE DMA EXT
  ef 03 46 00 00 00 a0 00      00:51:16.023  SET FEATURES [Set transfer mode]
  00 00 00 00 00 00 00 04      00:51:16.003  NOP [Abort queued commands]
  25 00 08 ff ff ff ef 00      00:51:12.739  READ DMA EXT

Error 998 occurred at disk power-on lifetime: 1911 hours (79 days + 15 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 00 08 ff ff ff ef 00      00:51:12.739  READ DMA EXT
  e1 00 00 00 00 00 a0 00      00:51:12.738  IDLE IMMEDIATE
  35 00 08 10 ce 1f e0 00      00:46:29.384  WRITE DMA EXT
  ef 03 46 00 00 00 a0 00      00:46:29.311  SET FEATURES [Set transfer mode]
  00 00 00 00 00 00 00 04      00:46:29.279  NOP [Abort queued commands]

Error 997 occurred at disk power-on lifetime: 1911 hours (79 days + 15 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 00 08 ff ff ff ef 00      00:46:25.991  READ DMA EXT
  35 00 08 10 ce 1f e0 00      00:46:25.990  WRITE DMA EXT
  ef 03 46 00 00 00 a0 00      00:46:25.917  SET FEATURES [Set transfer mode]
  00 00 00 00 00 00 00 04      00:46:25.885  NOP [Abort queued commands]
  25 00 08 ff ff ff ef 00      00:46:22.629  READ DMA EXT

Error 996 occurred at disk power-on lifetime: 1911 hours (79 days + 15 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 00 08 ff ff ff ef 00      00:46:22.629  READ DMA EXT
  35 00 08 10 ce 1f e0 00      00:46:22.628  WRITE DMA EXT
  ef 03 46 00 00 00 a0 00      00:46:22.608  SET FEATURES [Set transfer mode]
  00 00 00 00 00 00 00 04      00:46:22.521  NOP [Abort queued commands]
  25 00 08 ff ff ff ef 00      00:46:19.272  READ DMA EXT

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%         2         -

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.

Malheureusement, je ne sais pas ou ni quoi regarder dans ce resultat

Hors ligne

#4 Le 06/07/2020, à 09:19

geole

Re : Recuperation des données d'un HDD de NAS

Bonjour,
Ce compteur "recense'"  tes messages d'erreur.

197 Current_Pending_Sector  0x0012   084   001   000    Old_age   Always       -       1368

Donc potentiellement 1368 fichiers ou répertoires inaccessibles. En pratique moins car les secteurs illisibles sont souvent consécutifs par paquets de 8 pour ton modèle de disque.

Mais si le secteur décrit un répertoire, cela élimine pleins de fichiers qui pourraient être parfaitement lisibbles.

DDrescue tentera plein de fois d'y acceder mais il y aura toujours des récalcitrants.


Lorsque ddrescue aura dupliqué de façon très rapide, il attaquera les secteurs illisibles et peut le faire des centaines de fois. C'est toi qui décidera qu'il faut cesser car le taux de réussite devient quasiment nul.
La suite sera.
   1) Recupérer tous tes fichiers accessibles de façon normale.
   2) Mettre à zéro tout ce que tu as recupéré avec la commande wipe
   3)  Lancer photorec pour recupérer tout ce qui est lisible et authentifiable.
   4) Mettre des noms pour les fichiers récupérés en les lisant ou en les regardant ou en les écoutant..


Ajout.
Je suis surpris que seulement 1000 erreurs soient tracées

Error 1000 occurred at disk power-on lifetime: 1911 hours (79 days + 15 hours)

Il a certainement cessé de les enregistrer depuis bien longtemps

Dernière modification par geole (Le 06/07/2020, à 10:02)

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

En ligne

#5 Le 06/07/2020, à 09:28

Finkelstein

Re : Recuperation des données d'un HDD de NAS

Je n'ai malheureusement pas d'autre disque de 2To et pour l'instant, je ne peux pas m'en acheter un.

A lire la page wiki de ddrescue, j'ai l'impression qu'il est possible de ne tenter la restauration que sur une partie du disque. Si j'essaie de ne le faire que sur les répertoires qui me renvoient "Erreur d'entree/sortie", c'est jouable ou ça pourrait dégrader la situation ?

Hors ligne

#6 Le 06/07/2020, à 09:45

geole

Re : Recuperation des données d'un HDD de NAS

Je pense que ton disque ne dispose que d'une seule partition.
Donc un fichier volumineux peut être découpé en plusieurs morceaux ce qu'on appelle la fragmentation qui seront n'importe où dans le disque.
et un répertoire peut décrire des fichiers se trouvant n'importe où dans le disque.

Mais si ton disque dispose de plusieurs partitions c'est jouable partition par partition.

J'ai noté que le compteur 7 n'est pas en excellante santé, je te suggère de mettre le disque au repos jusqu'à ce que tu puisses faire l'opération de duplication.

Nota: Si tu as un disque de taille plus importante, c'est jouable en dupliquant dans un fichier.

Dernière modification par geole (Le 06/07/2020, à 09:49)

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

En ligne

#7 Le 06/07/2020, à 12:02

Finkelstein

Re : Recuperation des données d'un HDD de NAS

d’après l'utilitaire disks, il y a plusieurs partition sur le disque (surement créées par le NAS) mais les données sont bien stockées dans une seule et unique partition.

J'ai noté que le compteur 7 n'est pas en excellante santé, je te suggère de mettre le disque au repos jusqu'à ce que tu puisses faire l'opération de duplication.

Je n'ai pas compris ce qu’était le compteur 7

Donc avec ddrescue, on est obligé de faire l’opération de récuperation sur une partition entière

Hors ligne

#8 Le 06/07/2020, à 12:47

geole

Re : Recuperation des données d'un HDD de NAS

Si tu as plusieurs partitions
On va juste faire une duplication  de la partition contenant les données.   Donc taille adaptée pour la duplication
Pour connaître les tailles

lsblk

Il est hors de question de redupliquer  sur le disque    car il fatigue

  5 Reallocated_Sector_Ct   0x0033   070   070   036    Pre-fail  Always       -       19800

il y a déjà eu 19800 secteurs qui ont failli passer à l'état illisible mais qui ont été déplacés de justesse pour être mis ailleurs dans le disque

  7 Seek_Error_Rate         0x000f   062   060   030    Pre-fail  Always       -       958174026930

L'efficacité de lecture est de 062      soit donc une qualité très moyenne  62%      sachant que 30% est la limite acceptable
Comme l'opération de récupération des illisibles est loin  d'être neutre, le système de lecture peut lâcher pendant l'action. C'est d'ailleurs un cas qui stoppe net  l'opération.

et pour authentifier la partition pour la suite.

ls /dev/disk/by-path

Dernière modification par geole (Le 06/07/2020, à 12:53)

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

En ligne

#9 Le 06/07/2020, à 13:42

Finkelstein

Re : Recuperation des données d'un HDD de NAS

ah d'accord !!
Moi qui croyais que le disque etait plutot en bonne santé, c'est loin d'etre le cas donc

Hors ligne

#10 Le 19/09/2020, à 18:40

Finkelstein

Re : Recuperation des données d'un HDD de NAS

Ca y est, je suis equipé pour recupérer les données de mon disque dur endommagé.
Sur la page wiki de ddrescue, il est conseillé que le disque recepteur ne soit pas en ntfs sous peine d'allonger la durée du travail.

Sachant que par la suite, je compte brancher ce disque sur une Raspbian avec tout ou partie des données récupérées (donc sans formatage), quel systeme de fichier est conseillé ?

Le temps de recuperation de 2To de données se compte comment ? en jours ? en heures ? en minutes ?

Hors ligne

#11 Le 19/09/2020, à 20:44

geole

Re : Recuperation des données d'un HDD de NAS

Bonsoir.
Il y a 1368 secteurs illisibles. Sans compter ceux qui seront découverts.
Donc  en jours, sinon en semaines si le disque tient.
D'oû l'intérêt de savoir si on peut traiter par partitions. Ce nouveau disque va récupérer ce qui existe. Ses partitions seront détruites.  Par la suite tu verras comment l'utiliser.

Donc donne le retour de 

lsblk
ls /dev/disk/by-path

Dernière modification par geole (Le 19/09/2020, à 20:51)

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

En ligne

#12 Le 20/09/2020, à 13:06

Finkelstein

Re : Recuperation des données d'un HDD de NAS

La réponse au lsblk (pour l'instant je n'ai pas branché le disque de réception)

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0    7:0    0  55,3M  1 loop /snap/core18/1885
loop1    7:1    0  17,9M  1 loop /snap/pdftk/9
loop2    7:2    0  96,6M  1 loop /snap/core/9804
loop3    7:3    0 140,7M  1 loop /snap/gnome-3-26-1604/100
loop4    7:4    0 161,4M  1 loop /snap/gnome-3-28-1804/128
loop5    7:5    0   2,4M  1 loop /snap/gnome-calculator/748
loop6    7:6    0  62,1M  1 loop /snap/gtk-common-themes/1506
loop7    7:7    0   276K  1 loop /snap/gnome-characters/550
loop8    7:8    0   276K  1 loop /snap/gnome-characters/539
loop9    7:9    0  54,8M  1 loop /snap/gtk-common-themes/1502
loop10   7:10   0   956K  1 loop /snap/gnome-logs/100
loop11   7:11   0   956K  1 loop /snap/gnome-logs/93
loop12   7:12   0    97M  1 loop /snap/core/9665
loop13   7:13   0 255,6M  1 loop /snap/gnome-3-34-1804/33
loop14   7:14   0   2,2M  1 loop /snap/gnome-system-monitor/145
loop15   7:15   0   2,2M  1 loop /snap/gnome-system-monitor/148
loop16   7:16   0 160,2M  1 loop /snap/gnome-3-28-1804/116
loop17   7:17   0    55M  1 loop /snap/core18/1880
loop18   7:18   0 255,6M  1 loop /snap/gnome-3-34-1804/36
loop19   7:19   0 140,7M  1 loop /snap/gnome-3-26-1604/98
loop20   7:20   0   2,4M  1 loop /snap/gnome-calculator/730
sda      8:0    0  59,6G  0 disk 
└─sda1   8:1    0  59,6G  0 part /
sdb      8:16   0 298,1G  0 disk 
└─sdb1   8:17   0 298,1G  0 part /home
sdd      8:48   0   1,8T  0 disk 
├─sdd1   8:49   0 517,7M  0 part 
├─sdd2   8:50   0   1,8T  0 part 
└─sdd4   8:52   0   500M  0 part

La reponse au ls /dev/disk/by-path

pci-0000:00:11.0-ata-1        pci-0000:00:11.0-ata-4        pci-0000:00:12.2-usb-0:2:1.0-scsi-0:0:0:0  pci-0000:02:00.0-usb-0:2:1.0-scsi-0:0:0:0-part1  pci-0000:02:00.0-usb-0:2:1.0-scsi-0:0:0:0-part4
pci-0000:00:11.0-ata-1-part1  pci-0000:00:11.0-ata-4-part1  pci-0000:02:00.0-usb-0:2:1.0-scsi-0:0:0:0  pci-0000:02:00.0-usb-0:2:1.0-scsi-0:0:0:0-part2

Hors ligne

#13 Le 20/09/2020, à 13:15

geole

Re : Recuperation des données d'un HDD de NAS

Bonjour
Le disque a ennuis est donc

sdd      8:48   0   1,8T  0 disk 
├─sdd1   8:49   0 517,7M  0 part 
├─sdd2   8:50   0   1,8T  0 part 
└─sdd4   8:52   0   500M  0 part

Donc très certainement la partition 2 qui fait quasiment la taille du disque
Je me suis un peu trompé pour la seconde commande

ls    -ls   /dev/disk/by-id

Puis tu branches le disque de réception et de nouveau

lsblk -e7
ls    -ls   /dev/disk/by-id

Dernière modification par geole (Le 20/09/2020, à 13:18)

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

En ligne

#14 Le 20/09/2020, à 17:13

Finkelstein

Re : Recuperation des données d'un HDD de NAS

Je confirme c'est bien le disque sdd

Voici le retour de la commande ls -ls /dev/disk/by-id

total 0
0 lrwxrwxrwx 1 root root  9 sept. 20 12:42 ata-SanDisk_SDSSDP064G_132957402102 -> ../../sda
0 lrwxrwxrwx 1 root root 10 sept. 20 12:42 ata-SanDisk_SDSSDP064G_132957402102-part1 -> ../../sda1
0 lrwxrwxrwx 1 root root  9 sept. 20 12:42 ata-ST3320620AS_3QF0R904 -> ../../sdb
0 lrwxrwxrwx 1 root root 10 sept. 20 12:42 ata-ST3320620AS_3QF0R904-part1 -> ../../sdb1
0 lrwxrwxrwx 1 root root  9 sept. 20 12:42 usb-Multi_Flash_Reader_058F0O1111B1-0:0 -> ../../sdc
0 lrwxrwxrwx 1 root root  9 sept. 20 18:05 usb-ST2000DL_003-9VT166_012345678900000001D-0:0 -> ../../sdd
0 lrwxrwxrwx 1 root root 10 sept. 20 18:05 usb-ST2000DL_003-9VT166_012345678900000001D-0:0-part1 -> ../../sdd1
0 lrwxrwxrwx 1 root root 10 sept. 20 18:05 usb-ST2000DL_003-9VT166_012345678900000001D-0:0-part2 -> ../../sdd2
0 lrwxrwxrwx 1 root root 10 sept. 20 18:05 usb-ST2000DL_003-9VT166_012345678900000001D-0:0-part4 -> ../../sdd4
0 lrwxrwxrwx 1 root root  9 sept. 20 12:42 wwn-0x5001b44a0075eff6 -> ../../sda
0 lrwxrwxrwx 1 root root 10 sept. 20 12:42 wwn-0x5001b44a0075eff6-part1 -> ../../sda1

Apres avoir branché le nouveau disque (sans avoir debrancher l'ancien). Le nouveau disque sort de l'emballage, il n'a pas été formaté
Voici le retour de lsblk -e7

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0  59,6G  0 disk 
└─sda1   8:1    0  59,6G  0 part /
sdb      8:16   0 298,1G  0 disk 
└─sdb1   8:17   0 298,1G  0 part /home
sdd      8:48   0   1,8T  0 disk 
sde      8:64   0   1,8T  0 disk 
├─sde1   8:65   0 517,7M  0 part 
├─sde2   8:66   0   1,8T  0 part 
└─sde4   8:68   0   500M  0 part

Puis a nouveau ls -ls /dev/disk/by-id

total 0
0 lrwxrwxrwx 1 root root  9 sept. 20 12:42 ata-SanDisk_SDSSDP064G_132957402102 -> ../../sda
0 lrwxrwxrwx 1 root root 10 sept. 20 12:42 ata-SanDisk_SDSSDP064G_132957402102-part1 -> ../../sda1
0 lrwxrwxrwx 1 root root  9 sept. 20 12:42 ata-ST3320620AS_3QF0R904 -> ../../sdb
0 lrwxrwxrwx 1 root root 10 sept. 20 12:42 ata-ST3320620AS_3QF0R904-part1 -> ../../sdb1
0 lrwxrwxrwx 1 root root  9 sept. 20 12:42 usb-Multi_Flash_Reader_058F0O1111B1-0:0 -> ../../sdc
0 lrwxrwxrwx 1 root root  9 sept. 20 18:10 usb-ST2000DL_003-9VT166_012345678900000001D-0:1 -> ../../sde
0 lrwxrwxrwx 1 root root 10 sept. 20 18:10 usb-ST2000DL_003-9VT166_012345678900000001D-0:1-part1 -> ../../sde1
0 lrwxrwxrwx 1 root root 10 sept. 20 18:10 usb-ST2000DL_003-9VT166_012345678900000001D-0:1-part2 -> ../../sde2
0 lrwxrwxrwx 1 root root 10 sept. 20 18:10 usb-ST2000DL_003-9VT166_012345678900000001D-0:1-part4 -> ../../sde4
0 lrwxrwxrwx 1 root root  9 sept. 20 18:10 usb-ST2000VX_008-2E3164_012345678900000001D-0:0 -> ../../sdd
0 lrwxrwxrwx 1 root root  9 sept. 20 12:42 wwn-0x5001b44a0075eff6 -> ../../sda
0 lrwxrwxrwx 1 root root 10 sept. 20 12:42 wwn-0x5001b44a0075eff6-part1 -> ../../sda1

Hors ligne

#15 Le 20/09/2020, à 20:05

geole

Re : Recuperation des données d'un HDD de NAS

On a la référence de la partition à copier.
0 lrwxrwxrwx 1 root root 10 sept. 20 18:10 usb-ST2000DL_003-9VT166_012345678900000001D-0:1-part2 -> ../../sde2

Il faudrait maintenant que tu formates le nouveau disque  (SDD) en lui créant une  table de partition   de type ms-dos (onglet périphériques) et une partition  (de n'importe quel type) . Le plus simple est de prendre la totalité de l'espace libre.
Puis, tu feras de nouveau les deux commandes pour identifier la nouvelle partition.

lsblk -e7
ls    -ls   /dev/disk/by-id

Tu pourras aussi commencer à installer ddrescue

sudo apt install gddrescue

Préparation de la commande de copie initiale
Rectification

sudo ddrescue    -f    -n    -b4096    /dev/disk/by-id/usb-ST2000DL_003-9VT166_012345678900000001D-0:1-part2     /dev/sdd1   $HOME/ddsuivi

NOTA, la taille de l'unité de copie physique provient de cette ligne du smartcl
Sector Sizes:     512 bytes logical, 4096 bytes physical

Dernière modification par geole (Le 23/09/2020, à 18:40)

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

En ligne

#16 Le 23/09/2020, à 17:07

Finkelstein

Re : Recuperation des données d'un HDD de NAS

Le resultat de lsblk apres formatage en ext4 du disque sdd

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0  59,6G  0 disk 
└─sda1   8:1    0  59,6G  0 part /
sdb      8:16   0 298,1G  0 disk 
└─sdb1   8:17   0 298,1G  0 part /home
sdd      8:48   0   1,8T  0 disk 
sde      8:64   0   1,8T  0 disk 
├─sde1   8:65   0 517,7M  0 part 
├─sde2   8:66   0   1,8T  0 part 
└─sde4   8:68   0   500M  0 part

Le resultat de ls -ls /dev/disk/by-id

total 0
0 lrwxrwxrwx 1 root root  9 sept. 23 17:55 ata-SanDisk_SDSSDP064G_132957402102 -> ../../sda
0 lrwxrwxrwx 1 root root 10 sept. 23 17:55 ata-SanDisk_SDSSDP064G_132957402102-part1 -> ../../sda1
0 lrwxrwxrwx 1 root root  9 sept. 23 17:55 ata-ST3320620AS_3QF0R904 -> ../../sdb
0 lrwxrwxrwx 1 root root 10 sept. 23 17:55 ata-ST3320620AS_3QF0R904-part1 -> ../../sdb1
0 lrwxrwxrwx 1 root root  9 sept. 23 17:55 usb-Multi_Flash_Reader_058F0O1111B1-0:0 -> ../../sdc
0 lrwxrwxrwx 1 root root  9 sept. 23 18:00 usb-ST2000DL_003-9VT166_012345678900000001D-0:1 -> ../../sde
0 lrwxrwxrwx 1 root root 10 sept. 23 18:00 usb-ST2000DL_003-9VT166_012345678900000001D-0:1-part1 -> ../../sde1
0 lrwxrwxrwx 1 root root 10 sept. 23 18:00 usb-ST2000DL_003-9VT166_012345678900000001D-0:1-part2 -> ../../sde2
0 lrwxrwxrwx 1 root root 10 sept. 23 18:00 usb-ST2000DL_003-9VT166_012345678900000001D-0:1-part4 -> ../../sde4
0 lrwxrwxrwx 1 root root  9 sept. 23 18:03 usb-ST2000VX_008-2E3164_012345678900000001D-0:0 -> ../../sdd
0 lrwxrwxrwx 1 root root  9 sept. 23 17:55 wwn-0x5001b44a0075eff6 -> ../../sda
0 lrwxrwxrwx 1 root root 10 sept. 23 17:55 wwn-0x5001b44a0075eff6-part1 -> ../../sda1

et ddrescue est installé

Hors ligne

#17 Le 23/09/2020, à 17:18

Finkelstein

Re : Recuperation des données d'un HDD de NAS

ddrescue: Can't open input file: No such file or directory

Je me suis dit que c'etait /dev/sdd au lieu de /dev/sdd1 mais j'obtiens la meme reponse.
Comme je ne veux pas tout perdre, j'attend ta reponse avant de faire quoi que ce soit d'autre

J'ai verifié, ma variable $HOME est bien positionnée
Peut etre faut il creer une enveloppe vide pour ddsuivi ? ou mettre le chemin du disque emetteur plutot que son ID ?

Hors ligne

#18 Le 23/09/2020, à 18:38

geole

Re : Recuperation des données d'un HDD de NAS

Bonjour
Je pense que le nouveau disque est celui-ci

0 lrwxrwxrwx 1 root root  9 sept. 23 18:03 usb-ST2000VX_008-2E3164_012345678900000001D-0:0 -> ../../sdd

Tu as oublié de créer la partition SDD1  à faire  avec gparted

Il ne faut surtout pas créer le fichier de suivi, il penserait que c'est une reprise 

sudo ddrescue    -f    -n    -b4096    /dev/disk/by-id/usb-ST2000DL_003-9VT166_012345678900000001D-0:1-part2     /dev/sdd1   $HOME/ddsuivi

Dernière modification par geole (Le 23/09/2020, à 18:42)

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

En ligne

#19 Le 23/09/2020, à 20:39

Finkelstein

Re : Recuperation des données d'un HDD de NAS

Ok, c'est en cours, la suite demain.

Par contre, j'ai une question : cette premiere commande va durer 6 heures et je ne pourrais passer la suivante que demain soir. Est ce qu'entre la fin de l'execution de cette premiere commande et le passage de la suivante, je peux debrancher les disques sur lesquels se font les operations ou il est important de les laisser brancher pour une raison quelconque ?

En tout cas, je te remercie pour toute l'aide que tu m'apportes

Hors ligne

#20 Le 23/09/2020, à 20:51

geole

Re : Recuperation des données d'un HDD de NAS

Bonsoir.
Le fichier de suivi permet d'arrêter et de redémarrer quand on le souhaite en continuant.

si tu as mis sdd1 , fais attention à ce qu'au prochain démarrage , il soit encore SDD1.
Pour la suite, un autre intervenant répondra car je fais un petit break pendant  six jours..
.

Dernière modification par geole (Le 23/09/2020, à 20:54)

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

En ligne

#21 Le 29/09/2020, à 22:56

Finkelstein

Re : Recuperation des données d'un HDD de NAS

La premiere passe a l'air de s'etre plutot bien passée.
Malheureusement, je n'ai pas pensé a garder le compte rendu de realisation mais, de memoire, il y a + de 95% du disque d'origine qui a pu etre recupéré sans probleme.
Pour l'instant, je n'ai pas regardé le contenu du disque de reception.

Est ce qu'il y a d'autres etapes ensuite ?

Hors ligne

#22 Le 02/10/2020, à 09:34

geole

Re : Recuperation des données d'un HDD de NAS

Bonjour

La première passe récupère ce qu'il est possible de récupérer facilement
Les relances  suivantes, tentent de récupérer ce qui ne l'a pas été.

C'est l'ajout de trois nouveaux paramètres dans la commande par exemple      -R  -r3     -c1


On peut faire durer ces séquences pas mal de temps.   On arrête souvent pour ces causes
   - Le disque émetteur est devenu H.S.
   - Quelques passages consécutifs n'ont pu rien récupérer.
    - L'utilisateur estime  que la récupération de quelques secteurs   est devenue trop longue.
On passe alors à étape suivante pour faire
   A) soit une duplication de la copie avant réparation
   B) soit directement le contrôle par fsck   de la qualité de la copie
Au pire on termine par photorec


Pour un suivi d'exécution    avec un autre terminal

ddrescuelog  -tvv  <nom_fichier_journal> 
drescuelog -l-    <nom_fichier_journal>

Dernière modification par geole (Le 02/10/2020, à 09:35)

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

En ligne

#23 Le 05/10/2020, à 19:26

Finkelstein

Re : Recuperation des données d'un HDD de NAS

Je lance cette commande pour récupérer les fichiers endommagés

sudo ddrescue -d -f -R -r3 -b4096 -c1 /dev/disk/by-id/usb-ST2000DL_003-9VT166_012345678900000001D-0\:1-part2 /dev/sdd1 $HOME/ddsuivi

J'ai vérifié que les disques avaient toujours le meme id

Hors ligne

#24 Le 06/10/2020, à 07:36

Finkelstein

Re : Recuperation des données d'un HDD de NAS

Voici le résultat de cette passe :

GNU ddrescue 1.22
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 1998 GB, tried: 532480 B, bad-sector: 208896 B, bad areas: 48

     ipos:  154753 MB, non-trimmed:        0 B,  current rate:       0 B/s
     opos:  154753 MB, non-scraped:        0 B,  average rate:       8 B/s
non-tried:        0 B,  bad-sector:   462848 B,    error rate:     204 B/s
  rescued:    1998 GB,   bad areas:       40,        run time:  2h 13m 35s
pct rescued:   99.99%, read errors:      404,  remaining time:         n/a
                              time since last successful read:     13m 52s
Finished

Si j'ai bien tout compris, j'ai récupéré quelques aréas qui étaient "bad" (8 d'après ce que je lis).
Est ce que repasser la même commande peut s'avérer utile ? D’après ce que j'ai compris, on peut repasser cette commande a l'infinie sans jamais tout récupérer mais la je suis a 99.99% de récupération, je me demande si ca vaut le coup de continuer (peut etre encore une fois).

Je n'ai pas osé regardé mais dans quel etat se trouvent les données sur le disque de reception ? est ce lisible et rangé comme ca l'était sur le disque d'origine ou tout est en vrac ?

Hors ligne

#25 Le 06/10/2020, à 13:21

geole

Re : Recuperation des données d'un HDD de NAS

Bonjour.
Effectivement tu as récupéré 8 zones  en 2 heures 13 minutes mais il en reste encore 40
Vu la relative vitesse du passage,  tu as intérêt  à encore faire  un passage. Tu verras bien s'il récupère  encore quelque chose.

Voila le problème.
A ce niveau, on se pose la question de savoir  s'il faut continuer ou pas.
     Comme cela a été vite sans problème,   on ne risque pas grand chose à refaire des essais tant qu'il y a de la récupération effectuée.

  Mais il y a des cas, où c'est très long, que le disque chauffe et disparaisse... Il faut attendre des heures qu'il refroidisse..
On va alors se poser la question:   Est-ce bien utile de continuer???      La réponse n'est pas aisée.
   Les secteurs défectueux    sont à ranger  dans quatre catégories.
  1) Ceux (peu nombreux)   qui définissent la structure de la partition.    Si on ne les récupère pas, il faudra utiliser testdisk en technique deep search
  2) Ceux en nombre variable qui ne contiennent aucune donnée.      S'il n y a que ceux-là , c'est complètement inutile de vouloir les récupérer!!!
  3) Ceux qui contiennent des structures de fichiers. C'est important de les récupérer car ils contiennent les noms de fichiers.
  4) Ceux qui contiennent des données de fichiers.     Cela peut être important de les récupérer ou pas suivant la nature des fichiers ou leur nom.

Le gros problème est de mettre les secteurs dans l'une de ces quatre catégories.   Ce n'est pas facile, C'est expliqué au chapitre 4 de la documentation ddrescue  Mais je ne maîtrise pas très bien... 

Je sais que lorsque cette répartition est faite, on demande de récupérer les secteurs 1 par 1 en fournissant leurs n°
  On commencera évidement  par les plus importants et on ne fera pas ceux qui ne contiennent aucune donnée. mais je ne connais pas d'outil qui va fabriquer la commande à partir des sorties du chapitre 4.   Si on frappe un mauvais numéro , on peut croire que la récupération est bonne alors qu'il n'en est rien.   Je ne suis pas certain qu'il y ait des exemples dans le forum.


Voici donc les étapes à faire lorsque tu décideras que cela ne vaut plus le coup de  continuer à tenter de récupérer

A)   Optionnel:    Sauver la récupération sur un autre disque afin  de sécuriser les étapes suivantes
        Sur une fausse manipulation de remise en état
      Sur un constat que la réparation montre qu'on aurait du tenter de récupérer quelques secteurs de plus car il y a eu de grosses pertes.
    Cette séquence est rarement faite.

B) Optionnel mais fortement recommandée et souvent oubliée  pourtant elle est rapide.
    Mettre à zéro  toutes les parties qui n'ont pas été copiées et qui peuvent contenir des données du disque de récupération qui viendraient polluer une éventuelle récupération de fichier par l'application photorec
Pour ton contexte,  cela devrait être cette commande

ddrescue --fill-mode=- --force --synchronous /dev/zero    /dev/sdd1    $HOME/ddsuivi

C) Lancer le contrôle

sudo fsck -y   -f  /dev/sdd1

J'ai mis l'option y pour éviter de devoir répondre en permanence Y aux multiples questions qu'on comprend mal!
Tu peux ne pas mettre Y si tu souhaites répondre
Cette réparation peut durer un certain temps.

D)   Si on n'a pas de chance, il va y avoir trop de pertes de données. Dans ce contexte trois pistes:
    1 )   Analyser le répertoire lost-found et tenter de récupérer au mieux.
    2) Si on avait sauvé la partition, on peut restorer et relancer des séquences de récupération par ddrescue. Mais à ne faire que si le dernier ddrescue avait encore récupéré des zones. On peut penser qu'on  aurait encore pu en récupérer un peu  si on avait été moins pressé.

   3) Le cas le plus fréquent.
      a) Sauver tous les répertoires récupérés dans une autre partition.
      b)  Mettre des zéros dans les répertoires sauvés https://doc.ubuntu-fr.org/wipe
      c) Installer photorec https://doc.ubuntu-fr.org/photorec
      d) Récupérer toutes les zones qui ne sont pas à  zéros
      e) Mettre des noms sympathiques dans les fichiers numérotés récupérés

     

NOTA
La partition de réception est un clone parfait de la partition d'émission à l'exception des zones qui n'ont pas réussi à être  copiées et qui contiendront uniquement des zéros si on n'a pas oublié. Sinon ce sont leurs anciennes valeurs.

Dernière modification par geole (Le 06/10/2020, à 14:42)

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

En ligne

Pages : 1 2 3