1 |
On 12/18/2018 10:42 AM, Mick wrote: |
2 |
> I know others have commented on the reliability of recovering data from drives |
3 |
> connected via USB caddy, but I have had satisfactory results on a number of |
4 |
> cases. |
5 |
|
6 |
I think it completely depends on the type of problem. In my experience, |
7 |
SATA-to-USB adapters don't deal well with physical hard drive / media |
8 |
errors. (At least compared to SATA connections on the motherboard.) I |
9 |
think their retry mechanisms are somewhat limited. Conversely, software |
10 |
/ file system / logical corruption issues are likely perfectly fine over |
11 |
USB. |
12 |
|
13 |
> I cloned the whole drive having run ddrescue backwards and forwards a couple |
14 |
> of times. c/f/gdisk would see all partitions, but when I tried to mount the |
15 |
> cloned /dev/sdb4 (NTFS) with ntfs-3g it complained there was no device found |
16 |
> (/dev/sdb4). I got the same error with the failing drive. |
17 |
|
18 |
Seeing the partitions in the partition table is independent of the |
19 |
device file being there. - Did the device file exist? - I |
20 |
occasionally have to run (k)part(x) to tell the kernel that the |
21 |
partition is there and to create the device file. |
22 |
|
23 |
> So, I used losetup with --offset on the failing drive itself over USB 2.0 and |
24 |
> was able to mount and recover all the NTFS files. |
25 |
|
26 |
That sounds like the kernel didn't know about the partition and / or the |
27 |
device file didn't exist. losetup will create a new device file (and |
28 |
possibly partitions depending on how you did it). Then you will be able |
29 |
to point standard FS tools at the new device (partition) file. |
30 |
|
31 |
> Over the years I've used clonezilla, ddrescue, testdisk, photorec and losetup |
32 |
> to recover files. On a couple of times where data on the disk had been |
33 |
> overwritten by subsequent operations, I was not able to recover the affected |
34 |
> files. So, if when moving the partition data was overwritten I suspect it |
35 |
> will be very difficult to recover this with conventional software tools. |
36 |
|
37 |
I would expect moving a partition to an earlier location on the drive |
38 |
will take the first block and move it to the new location, then the next |
39 |
block, etc. until finished. I'd expect moving a partition to a later |
40 |
location on the drive will take the last block and move it to the next |
41 |
location, then the previous block, etc. until finished. This way the |
42 |
data is never actually overwritten. Blocks have been moved, and |
43 |
committed to disk, thus vacating the old block. |
44 |
|
45 |
> However, it doesn't hurt to try. :-) |
46 |
|
47 |
I mostly agree. You need to be mindful of physical damage and thermals. |
48 |
|
49 |
|
50 |
|
51 |
-- |
52 |
Grant. . . . |
53 |
unix || die |