
Originally Posted by
oolon
The OP does not appear to use linux just states a friend imaged it using linux. I prefer to use kpartx so I can access all the partitions on the disk without having to guess at the offset.
I read it as OP imaged it himself with some help (perhaps from an online forum?).. I also noticed the statement "ideally in Windows", however as I had the suggestion had been made that OP had at least used linux before, I gave solutions which fit the criteria. Incidentally, my suggestions are substantially cheaper than £65 or £120, but it's not my wallet at the end of the day.
You also don't have to guess the offset, you can calculate it like so:
Code:
# fdisk -l
Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
<SNIP>
Device Boot Start End Blocks Id System
/dev/sda1 63 2930272064 1465136001 fd Linux raid autodetect
Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
<SNIP>
Device Boot Start End Blocks Id System
/dev/sdb1 63 2930272064 1465136001 fd Linux raid autodetect
Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
<SNIP>
Device Boot Start End Blocks Id System
/dev/sdc1 63 2930272064 1465136001 fd Linux raid autodetect
Disk /dev/sdd: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0b0b0b0b
Device Boot Start End Blocks Id System
/dev/sdd1 * 63 192779 96358+ 83 Linux
/dev/sdd2 192780 4192964 2000092+ 82 Linux swap / Solaris
/dev/sdd3 4192965 156296384 76051710 83 Linux
Disk /dev/md0: 3000.6 GB, 3000598396928 bytes
<SNIP>
Now... 63 (start) * 512 (sector size) = 32256, and as it's a full disk image (i.e. not a partition) that OP is trying to recover, then we can assume that 32256 is correct (yes, assumption is the mother of all screw ups), but hey - it doesn't matter anyway as OP is going to image it back to disk.
@OP using dd should work fine for you, but it will take a while and it will have no visual output. Also, as you mentioned that the image was taken as a recovery step, it may be worthwhile using the noerror and sync options for dd.
# fdisk -l
(you'll get a similar output to what I posted above - e.g. my root drive above is the 80GB one and I have three identical 1.5TB disks + a 3TB virtual disk. If you can't pinpoint the disk you're after, then it might be an idea to power down and pull the cables from the other disks)
# dd if=diskimage.bin of=/dev/sda conv=noerror,sync
(/dev/sda is the first disk, so again, **check this is the one you want - dd will not ask you if you're sure** noerror,sync means that dd doesn't fail on write and if it does come across a bad block, it keeps the filesystem synced).
If you open another terminal and issue the command:
# killall -s USR1 dd
then go back to the terminal running dd, it should give you an output similar to the below (giving you a rough idea of how long it is taking).
Code:
2778143+0 records in
2778143+0 records out
1422409216 bytes (1.4 GB) copied, 8.79078 s, 162 MB/s
(note - the "#" at the start of a command denotes running with elevated privileges, e.g. using "su" or "sudo")