1 |
Duncan wrote: |
2 |
> If you have a spare drive of the same size or larger, you can try dd, or |
3 |
> probably better yet, merge dd-rescue and try it. They copy a file or |
4 |
> part of one, in this case an entire block device, from one location to |
5 |
> another, "raw". What you want to do is copy the entire bad device, /dev/ |
6 |
> sdc above, to the new device. Then you have a copy to play around with |
7 |
> without worrying about making the bad device worse before you get |
8 |
> whatever you were trying to get off of it, off. |
9 |
> |
10 |
Duncan, |
11 |
|
12 |
thanks for the ddrescue explanation, I will surely give it a try. |
13 |
|
14 |
Yesterday evening I got a new drive double the size of the damaged one, |
15 |
created a 250Gb partition on it and tried: |
16 |
# dd if=/dev/hdb of=/mnt/disk_500/sdb.img |
17 |
|
18 |
It stopped after few kb due to read errors. So I modified to |
19 |
dd conv=noerror if=/dev/hdb of=/mnt/disk_500/sdb.img |
20 |
|
21 |
and after some time I got a 250Gb sdb.img on the new drive. |
22 |
Then started the fun (it was already past midnight). When I created the |
23 |
new partition I noted down the superblock backup locations. |
24 |
Unfortunately, every: |
25 |
# e2fsck -b xxx -B 4096 /mnt/disk_500/sdb.img |
26 |
|
27 |
returned 'bad superblock'. After googling for some utility to scan disc |
28 |
for superblocks, I ended up with testdisk (it's ~amd64). To my |
29 |
understanding this works on real HW only, so I had to reconnect the |
30 |
damaged HD and let it do its job. testdisk found the superblocks, but |
31 |
according to it they were at the exact locations I had already noted, so |
32 |
no help. I also tried to let it search for partitions because I read it |
33 |
has an option to parse the directory. It worked, it let me see the list |
34 |
of lost files, but that's all, it has no option to recover. But at least |
35 |
it told me there is some good superblock somewhere. |
36 |
|
37 |
Finally I went back to the sdg.img and used "od | less" to look at what |
38 |
was present at the superblock location. What I saw was, I believe, a |
39 |
part of the superblock (an almost regular patter of numbers, increasing, |
40 |
which could be a list of blocks? I need to study ext2) but the point is |
41 |
that this pattern began well before the 'theoretical address' of the |
42 |
superblock. |
43 |
|
44 |
So my hypothesis is that the bad blocks or sectors at the beginning of |
45 |
the partition were not copied, or only partly copied, by dd, and due to |
46 |
this the superblocks are all shifted down. Although I don't like to |
47 |
access again the hw, maybe I should try: |
48 |
# dd conv=noerror,sync bs=4096 if=/dev/hdb of=/mnt/disk_500/sdb.img |
49 |
|
50 |
to get an aligned image. Problem is I don't know what bs= should be. |
51 |
Block size, so 4k? |
52 |
|
53 |
Any other option I might have? |
54 |
|
55 |
thanks, |
56 |
|
57 |
raffaele |
58 |
-- |
59 |
gentoo-amd64@g.o mailing list |