| 1 |
On Tuesday, 18 December 2018 18:51:55 GMT Grant Taylor wrote: |
| 2 |
> On 12/18/2018 10:42 AM, Mick wrote: |
| 3 |
> > I know others have commented on the reliability of recovering data from |
| 4 |
> > drives connected via USB caddy, but I have had satisfactory results on a |
| 5 |
> > number of cases. |
| 6 |
> |
| 7 |
> I think it completely depends on the type of problem. In my experience, |
| 8 |
> SATA-to-USB adapters don't deal well with physical hard drive / media |
| 9 |
> errors. (At least compared to SATA connections on the motherboard.) I |
| 10 |
> think their retry mechanisms are somewhat limited. Conversely, software |
| 11 |
> / file system / logical corruption issues are likely perfectly fine over |
| 12 |
> USB. |
| 13 |
|
| 14 |
I ran ddrescue while the drive was still on the laptop. The clone was on the |
| 15 |
USB caddy. |
| 16 |
|
| 17 |
|
| 18 |
> > I cloned the whole drive having run ddrescue backwards and forwards a |
| 19 |
> > couple of times. c/f/gdisk would see all partitions, but when I tried to |
| 20 |
> > mount the cloned /dev/sdb4 (NTFS) with ntfs-3g it complained there was no |
| 21 |
> > device found (/dev/sdb4). I got the same error with the failing drive. |
| 22 |
> |
| 23 |
> Seeing the partitions in the partition table is independent of the |
| 24 |
> device file being there. - Did the device file exist? - I |
| 25 |
> occasionally have to run (k)part(x) to tell the kernel that the |
| 26 |
> partition is there and to create the device file. |
| 27 |
|
| 28 |
The disk block device is there and so is the first partition (only): |
| 29 |
|
| 30 |
ls -la /dev/sdb* |
| 31 |
brw-rw---- 1 root disk 8, 16 Dec 19 11:20 /dev/sdb |
| 32 |
brw-rw---- 1 root disk 8, 17 Dec 19 11:20 /dev/sdb1 |
| 33 |
|
| 34 |
|
| 35 |
However, there's 6 partitions in total: |
| 36 |
|
| 37 |
Disk /dev/sdb: 1953525168 sectors, 931.5 GiB |
| 38 |
Model: LucidPort USB300 |
| 39 |
Sector size (logical/physical): 512/512 bytes |
| 40 |
Disk identifier (GUID): 1A95F5D1-5630-4E06-9DC3-36841C786DDF |
| 41 |
Partition table holds up to 128 entries |
| 42 |
Main partition table begins at sector 2 and ends at sector 33 |
| 43 |
First usable sector is 34, last usable sector is 1953525134 |
| 44 |
Partitions will be aligned on 2048-sector boundaries |
| 45 |
Total free space is 4770 sectors (2.3 MiB) |
| 46 |
|
| 47 |
Number Start (sector) End (sector) Size Code Name |
| 48 |
1 2048 821247 400.0 MiB 2700 Basic data partition |
| 49 |
2 821248 1353727 260.0 MiB EF00 EFI system partition |
| 50 |
3 1353728 1615871 128.0 MiB 0C01 Microsoft reserved |
| 51 |
... |
| 52 |
4 1615872 1911737034 910.8 GiB 0700 Basic data partition |
| 53 |
5 1911738368 1915412479 1.8 GiB 2700 |
| 54 |
6 1915412480 1953523711 18.2 GiB 0700 Basic data partition |
| 55 |
|
| 56 |
I can see partition 4 I was trying to recover, but could not add it: |
| 57 |
|
| 58 |
partx --show --nr 4 /dev/sdb |
| 59 |
NR START END SECTORS SIZE NAME UUID |
| 60 |
4 1615872 1911737034 1910121163 910.8G Basic data partition fea85fb3- |
| 61 |
cfdb-4868-a1ad-bab264dad237 |
| 62 |
|
| 63 |
partx --add --nr 4 /dev/sdb |
| 64 |
partx: /dev/sdb: error adding partition 4 |
| 65 |
|
| 66 |
partx --add /dev/sdb |
| 67 |
partx: /dev/sdb: error adding partitions 1-6 |
| 68 |
|
| 69 |
In any case, losetup with offset/size succeeded in mounting it and I was able |
| 70 |
to access the fs on it. |
| 71 |
-- |
| 72 |
Regards, |
| 73 |
Mick |
Archives