Someone asked me to try to recover the data from a WD40EFRX 4TB HDD. At first the SMART status showed 43 “pending” sectors, then that number increased to 55 during the first transfer attempts, but remained stable for several hours afterwards.
I proceeded to clone the whole drive with HDDSuperClone. There was a bad area near the begining, but then it copied at a steady rate around 60MB/s. Then, about halfway through, it started to have more severe issues; at that point the “pending sector count” increased dramatically, reaching 1167. Looking at the graphic presentation of the recovery provided by HDDSCViewer, I noticed a pattern of alternating stripes, with larger stripes of easily accessible sectors (copied at a rate above 50MB/s), and smaller stripes of unreadable sectors. That kind of pattern indicates that one head is failing, right ? I stopped the copy and tried again starting from sector 7000000000, near the end (which is not practical by the way with HDDSuperClone GUI, I had to edit the log file, changing the input value in the parameters would result in an error) : it showed the same pattern, and again, even when it could transfer something, it appeared as 00s only in the preview.
Now, the owner told me that the drive contained about 1TB of data. Since I successfully cloned about 2TB, everything should be there. But :
– according to GParted, the larger partition contains 553.46GB out of 3.63TB, which could just mean that the owner overestimated the actual amount of data ;
– GParted could gather valid information from the source drive, albeit with difficulty (I could even mount it and see the contents), but it gave an error warning when analysing the corresponding partition from the recovery drive {1} ;
– I noticed that it copied only 00s quite early on, when the copy was at about 12% if I remember correctly, and there was no sign of trouble at that point ;
– when the whole drive is opened in WinHex, it appears totally empty beyond sector 918566948 / offset 470306277376 (it doesn't stop abruptly, it seems to be the end of a video file, and the last non-empty sector ends with zeroes), or sector 909137956 / offset 465478633472 relative to the start of the partition, which is indeed about 12%. So there is a ~120GB discrepancy. How can it be ? Where can it be ? Could the missing data be located at the end of the partition, with a lot of free space in between ? How could I know for sure ?
When I saw that it was copying only zeroes, I re-read HDDSuperClone's manual and tried to apply the method described there to clone only the used portion, but apparently it requires the “virtual disk” feature which is only available on the “Pro” version. Since the main partition is formatted in Ext4, I couldn't use ddru_ntfsbitmap which easily creates ddrescue mapfiles for NTFS partitions. I also tried to increase the “skip size” to a much larger value, like 10MB, but it would go back to 4096 almost immediately. So unfortunately I could only let it clone everything, and it's frustrating because I may have been able to recover much more useful sectors (provided that there is indeed more data somewhere) if that head hadn't been worn out by reading 1.5TB of 00s...
What could be done at this point to complete the clone as much as possible and as efficiently as possible ? (Short of replacing the bad head...)
I tried using ddru_findbad, but it returned nothing, apparently it can't analyse the partitions.
Code:
lubuntu@lubuntu:~$ sudo ddru_findbad /dev/sda /media/lubuntu/Q_SD/WD40EFRX_ddrescue_export.log -o /media/lubuntu/Q_SD/WD40EFRX_findbad.log
Command line input was processed succesfully
ddru_findbad 1.11 20141015
Target = /dev/sda
Logfile = /media/lubuntu/Q_SD/WD40EFRX_ddrescue_export.log
Output base name = /media/lubuntu/Q_SD/WD40EFRX_findbad.log
Sector size = 512
Loop wait time = 2
More info = false
Extra output = false
Quick = false
Quick ntfs = false
Target /dev/sda is detected to be a block device
Neither mmstat or fsstat gave results
The partition table or file system could be corrupt
Cannot determine if target is whole drive or single partition
See file /media/lubuntu/Q_SD/WD40EFRX_findbad2.log_debug.txt for more info
The main partition is formatted in Ext4; I don't know much about that file-system. Apparently the metadata structures are disseminated in “inode” files located all over the partition, instead of being stored in a single structure like the MFT in NTFS. And it turns out that neither WinHex nor R-Studio can reconstruct the complete file-tree. If I can't complete the clone, are there better tools to analyse partial Ext4 partitions ?
At worst I could resort to raw file carving, but it would be frustrating since the partition can still be mounted and the directory structure can still be parsed. Is there at least a way of copying the empty directory structure, to help the owner sort out the mountain of files with nondescript names that comes out of that recovery method ? On Windows I use Robocopy /CREATE for that purpose, so I'm looking for an equivalent command in Linux / Lubuntu.
As a side question : I noticed that the “power-on time” was high at 32975 hours, but the “start / stop count” in particular seems extremely high at 84281. It would mean that the drive was on for less than 30 minutes on average. Isn't that abnormal ? Or is it related to the regular operation of that range of drives, if they spin down automatically when idle or something like that ?
{1} GParted error message :
Code:
Filesystem volume name: <none>
Last mounted on: /media/sdb4
Filesystem UUID: 1b5a9115-a28c-4f16-8e7d-c4c3d9d4cb09
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: unsigned_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 243900416
Block count: 975575808
Reserved block count: 19511516
Free blocks: 830488873
Free inodes: 243819640
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 791
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Thu Dec 10 08:54:28 2015
Last mount time: Mon Apr 15 13:26:30 2019
Last write time: Mon Apr 15 13:59:43 2019
Mount count: 172
Maximum mount count: -1
Last checked: Thu Dec 10 08:54:28 2015
Check interval: 0 (<none>)
Lifetime writes: 26 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: e1c45096-875e-4d9c-a701-f8dcb039618e
Journal backup: inode blocks
FS Error count: 2751
First error time: Sun Apr 14 07:06:01 2019
First error function: ext4_find_entry
First error line #: 935
First error inode #: 18219009
First error block #: 0
Last error time: Mon Apr 15 13:59:43 2019
Last error function: __ext4_get_inode_loc
Last error line #: 4199
Last error inode #: 18219197
Last error block #: 72876075</i>
<i>dumpe2fs 1.42.9 (4-Feb-2014)
Journal superblock magic number invalid!</i>
<i>Impossible de lire le contenu du système de fichiers.
Pour cette raison, certaines opérations peuvent être indisponibles.
La raison peut être l'absence d'un paquet logiciel.
Voici la liste des paquets logiciels nécessaires pour la prise en charge du système de fichiers ext4 : e2fsprogs v1.41+.
Attachment:
2019-05-23-024659_1022x760_scrot.png [ 164.97 KiB | Viewed 25898 times ]
SMART status after the first transfer operations.
Attachment:
2019-05-23-190151_786x656_scrot.png [ 102.55 KiB | Viewed 25898 times ]
HDDSuperClone copying only 00s beyond ~12%, but at a decent rate of ~60MB/s.
Attachment:
2019-05-24-014637_786x656_scrot.png [ 103.7 KiB | Viewed 25898 times ]
Starting to seriously struggle...
Attachment:
2019-05-24-020414_786x656_scrot.png [ 105.75 KiB | Viewed 25898 times ]
...but then goes back to full speed...
Attachment:
2019-05-24-020426_786x656_scrot.png [ 106.44 KiB | Viewed 25898 times ]
...and struggles again...
Attachment:
2019-05-23-235000_1330x1024_scrot.png [ 39.89 KiB | Viewed 25898 times ]
HDDSCViewer, “stripes” pattern.
Attachment:
2019-05-24-020543_1330x1024_scrot.png [ 39.53 KiB | Viewed 25898 times ]
Same pattern much further down the road.
Attachment:
2019-05-24-024015_1023x633_scrot.png [ 161.82 KiB | Viewed 25898 times ]
SMART status at that point.
Attachment:
2019-05-24-044525_777x530_scrot.png [ 70.41 KiB | Viewed 25898 times ]
GParted, source drive.
Attachment:
2019-05-24-044554_777x530_scrot.png [ 68.57 KiB | Viewed 25898 times ]
GParted, recovery drive.