how to get back dat...
 
Notifications
Clear all

how to get back data for DD error

8 Posts
3 Users
0 Reactions
808 Views
(@ermac)
New Member
Joined: 17 years ago
Posts: 3
Topic starter  

Last day I tried to clone my OpenBSD integrating CF but unfortunatly I mistook DD destination file going to my HDD USB instead of the CF.
At now I have a HDD including the first 2 GB (cloned from the CF) on DD writing, and all the other 498GB remaining the same as before.
Before this error my HDD included two partitions a 450GB +/- NTFS one and a 50GB +/- ext3 one.
As regards ext3 partition, I don't mind restoring data.But I really need to restore NTFS partition or files with their original names.

The testdisk that I've run with standard parameters doesn't recognize any NTFS partition. Please find the report below and please help me!! thank you very much!


ext2fs lib 1.41.3, ntfs lib 1000, reiserfs lib none, ewf lib none
/dev/sda LBA, HPA, LBA48, DCO support
/dev/sda size 312581808 sectors
/dev/sda user_max 312581808 sectors
/dev/sda native_max 312581808 sectors
/dev/sda dco 312581808 sectors
Warning can't get size for Disk /dev/mapper/control - 0 B - CHS 1 1 1, sector size=512
Hard disk list
Disk /dev/sda - 160 GB / 149 GiB - CHS 19457 255 63, sector size=512 - ATA Hitachi HTS54321
Disk /dev/sdb - 16 GB / 15 GiB - CHS 15424 64 32, sector size=512 - Verbatim Store 'n' Go
Disk /dev/sdc - 500 GB / 465 GiB - CHS 242255 64 63, sector size=512 - BUFFALO HD-PEU2

Partition table type (auto) Intel
Disk /dev/sdc - 500 GB / 465 GiB - BUFFALO HD-PEU2
Partition table type Intel
New options
Dump No
Cylinder boundary Yes
Allow partial last cylinder No
Expert mode No
New options
Dump No
Cylinder boundary Yes
Allow partial last cylinder No
Expert mode No

Interface Advanced
Geometry from i386 MBR head=64 sector=63

BSD offset 63, nbr_part 16, CHS=(977,64,63) CRC Ok
BSD a 4.2BSD fast filesystem, offset 63, size 528129 0/1/1 -> 130/63/63
BSD b 4.2BSD fast filesystem, offset 528192, size 790272 131/0/1 -> 326/63/63
BSD d 4.2BSD fast filesystem, offset 1318464, size 1576512 327/0/1 -> 717/63/63
BSD e 4.2BSD fast filesystem, offset 2894976, size 266112 718/0/1 -> 783/63/63
BSD f 4.2BSD fast filesystem, offset 3161088, size 266112 784/0/1 -> 849/63/63
BSD g swap, offset 3427200, size 512064 850/0/1 -> 976/63/63
get_geometry_from_list_part_aux head=64 nbr=2
get_geometry_from_list_part_aux head=8 nbr=2
get_geometry_from_list_part_aux head=16 nbr=2
get_geometry_from_list_part_aux head=32 nbr=2
get_geometry_from_list_part_aux head=64 nbr=2
get_geometry_from_list_part_aux head=128 nbr=1
get_geometry_from_list_part_aux head=240 nbr=1
get_geometry_from_list_part_aux head=255 nbr=1
4 * OpenBSD 0 1 1 976 63 63 3939201 [CF Card ]

Analyse Disk /dev/sdc - 500 GB / 465 GiB - CHS 242255 64 63
Geometry from i386 MBR head=64 sector=63

BSD offset 63, nbr_part 16, CHS=(977,64,63) CRC Ok
BSD a 4.2BSD fast filesystem, offset 63, size 528129 0/1/1 -> 130/63/63
BSD b 4.2BSD fast filesystem, offset 528192, size 790272 131/0/1 -> 326/63/63
BSD d 4.2BSD fast filesystem, offset 1318464, size 1576512 327/0/1 -> 717/63/63
BSD e 4.2BSD fast filesystem, offset 2894976, size 266112 718/0/1 -> 783/63/63
BSD f 4.2BSD fast filesystem, offset 3161088, size 266112 784/0/1 -> 849/63/63
BSD g swap, offset 3427200, size 512064 850/0/1 -> 976/63/63
get_geometry_from_list_part_aux head=64 nbr=2
get_geometry_from_list_part_aux head=8 nbr=2
get_geometry_from_list_part_aux head=16 nbr=2
get_geometry_from_list_part_aux head=32 nbr=2
get_geometry_from_list_part_aux head=64 nbr=2
get_geometry_from_list_part_aux head=128 nbr=1
get_geometry_from_list_part_aux head=240 nbr=1
get_geometry_from_list_part_aux head=255 nbr=1
Current partition structure
4 * OpenBSD 0 1 1 976 63 63 3939201 [CF Card ]
Ask the user for vista mode
Computes LBA from CHS for Disk /dev/sdc - 500 GB / 465 GiB - CHS 242256 64 63
Allow partial last cylinder Yes
search_vista_part 1

search_part()
Disk /dev/sdc - 500 GB / 465 GiB - CHS 242256 64 63

BSD offset 63, nbr_part 16, CHS=(977,64,63)
BSD offset 63, nbr_part 16, CHS=(977,64,63) CRC Ok
BSD a 4.2BSD fast filesystem, offset 63, size 528129 0/1/1 -> 130/63/63
BSD b 4.2BSD fast filesystem, offset 528192, size 790272 131/0/1 -> 326/63/63
BSD d 4.2BSD fast filesystem, offset 1318464, size 1576512 327/0/1 -> 717/63/63
BSD e 4.2BSD fast filesystem, offset 2894976, size 266112 718/0/1 -> 783/63/63
BSD f 4.2BSD fast filesystem, offset 3161088, size 266112 784/0/1 -> 849/63/63
BSD g swap, offset 3427200, size 512064 850/0/1 -> 976/63/63
OpenBSD 0 1 1 976 63 62 3939200 [CF Card ]

HFS+ magic value at 30330/1/1
part_size 21136
HFS 30330 1 1 30335 16 31 21136
HFS+, 10 MB / 10 MiB
get_geometry_from_list_part_aux head=64 nbr=3
get_geometry_from_list_part_aux head=8 nbr=3
get_geometry_from_list_part_aux head=16 nbr=3
get_geometry_from_list_part_aux head=32 nbr=3
get_geometry_from_list_part_aux head=64 nbr=3
get_geometry_from_list_part_aux head=128 nbr=2
get_geometry_from_list_part_aux head=240 nbr=2
get_geometry_from_list_part_aux head=255 nbr=1

Results
* OpenBSD 0 1 1 976 63 63 3939201 [CF Card ]
L HFS 30330 1 1 30335 63 63 24129
HFS+, 12 MB / 11 MiB
SIGINT detected! TestDisk has been killed.


   
Quote
(@mscotgrove)
Prominent Member
Joined: 17 years ago
Posts: 940
 

If it is just 2GB that has been overwritten, there is a good chance that the the original NTFS drive will still be largely intact. A normal $MFT starts at sector 0x60003F (or 0x600800 - for Vista/win7) and 2GB is sector 0x400000). This is assumimg that the NTFS partition is first

Any good data recovery program will beable recreate a boot sector, new BPB and read most of the data from the disk. Yu will have tp force the recovery program to undertand it is reading an NTFS disk, and ignore thecurrent boot sector information

The Ext3 partition will just require the boot sector to be rebuilt


   
ReplyQuote
(@ermac)
New Member
Joined: 17 years ago
Posts: 3
Topic starter  

Does any opensource software exist to do what you suggest me to do in your post?
If yes, what's its name?


   
ReplyQuote
(@mscotgrove)
Prominent Member
Joined: 17 years ago
Posts: 940
 

My software would, but it is not open source. Demo is free to evaluate the principle and see if your data is there.


   
ReplyQuote
jaclaz
(@jaclaz)
Illustrious Member
Joined: 18 years ago
Posts: 5133
 

Well, you can still operate "manually" the good, ol' way. )

You ALREADY have a copy of the bootsector (as last sector of the partition, just outside the filesystem space).

The $MFT as said is usually way off the first 2 GBs.

It is normally at LCN 786432 (dec) which, with a cluster size of 8 sector would make 6,291,456 sectors or 3,221,225,472 inside the partition.

You can get some hints/methods/tools reading this thread
http//www.msfn.org/board/index.php?showtopic=145574

What I would do

  1. verify that the $MFT is actually where it should be and valid.
  2. create a new virtual disk (sparse file) the EXACT same size as the "partially overwritten" one
  3. create in it a partition with the same exact size and start point as the "partially overwritten" one
  4. format it under the same exact system it was originally formatted
  5. dd the first 2 Gb (again exact) from the "new, empty partition" to the "partially overwritten" one
  6. restore the bootsector from the copy on last sector (you can do it manually or use TESTDISK)
  7. [/listo]

    At this point you should have a perfectly "sound" filesystem, BUT with a number of file pointers that now lead you to 00'ed sectors (everything that actually was in the first 2 Gb is "lost forever".

    Yu should have NO problems whatsoever using tools like NTFSWALKER or DMDE
    http//dmitrybrant.com/ntfswalker
    http//softdm.com/
    to get all the files that were NOT in the first 2Gb.

    Most probably you could even run "directly" a chkdsk on the volume, but it is not advised until you have done all you can with the two apps before mentioned, as in that way you may be able to recover also some file fragments that would probably be "fixed" by the chkdsk.

    I take that in this particular case "freeware" can be used instead of "Open Source".

    jaclaz


   
ReplyQuote
(@mscotgrove)
Prominent Member
Joined: 17 years ago
Posts: 940
 

It is normally at LCN 786432 (dec) which, with a cluster size of 8 sector would make 6,291,456 sectors or 3,221,225,472 inside the partition.

Numbers are MUCH easier when displayed, and thought of in Hex

It is normally at LCN 0xc0000 which, with a cluster size of 8 sector would make 0x600000 sectors or 0xc0000000 inside the partition.

Just add the start of the partition and you will probably find the start sector of the $MFT to be 0x60003f or 0x600800. No complex arithmethic required!

NB I think Jaclaz is rfering to a copy of the BPB in the final sector of the NTFS partition. I cannot see a Boot sector after the end of the partition (possible I am not looking far enough) . The BPB would need to be written to the first sector of the partition typically sector 0x3f or 0x800, assuming that the first partition was the required NTFS


   
ReplyQuote
jaclaz
(@jaclaz)
Illustrious Member
Joined: 18 years ago
Posts: 5133
 

Numbers are MUCH easier when displayed, and thought of in Hex

Sure, what makes 0x2710 multiplied by 0x14 ? ?

D

NB I think Jaclaz is rfering to a copy of the BPB in the final sector of the NTFS partition.

Sure, that's how NTFS work (different from the early "NT 3.x" version)
http//www.ntfs.com/ntfs-partition-boot-sector.htm
http//support.microsoft.com/kb/153973/en-us

I cannot see a Boot sector after the end of the partition (possible I am not looking far enough) .

it is not "after the end", it is last sector of the partition (i.e. ONLY sector outside of the filesystem).
Or, if you prefer, the NTFS filesystem uses one sector less of the number that is present in the partition table for the partition size.
This last sector if the copy of the first sector of the NTFS partition.

jaclaz


   
ReplyQuote
(@ermac)
New Member
Joined: 17 years ago
Posts: 3
Topic starter  

TNK to all!! D D D D D


   
ReplyQuote
Share: