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