need to recover mbr on ST950032 5AS seagate from HP HDX w/ Vista 32-bi

[d8apzl]

Well, 13 errors mean little, it is the type and extension of each that may make the difference.

They appear to be read errors, bad sectors most likely.

I will translate this to plain English for you (two possible alternative translations) :

I do work for Seagate, as a matter of fact it is 15 years that I am the delivery boy, what I usually say to my friends is that I am chief engineer at Seagate, and they believe me, I actually hve no idea on how a hard disk is made or how it works, but since also my friends know nothing about hard disks, I'l just tell this guy that there is nothing to do about the disk.

I actually am chief engineer at Seagate and I can of course recover any drive, whatever the damage is, but since it would cost me time, dedication and what not, I'll simply tell this guy that there is nothing to do about the disk.

Yah, probably the latter internal cust. service guy asked tech w/ "proprietary" sw & equipment did not want to spend any time on it, lost all hope and/or unenlightened. have you ever considered working for seagate/hitachi?

$MFT begins at 6498000+306=6498306 (and NOT 6498310).

Please, do check that on the image sector 6498306 does begin with "FILE0" and that around the middle you can read "$.M.F.T.m.i.r.r.".

Appears @ '6498306' on the image I made with ddrd. I see "$.M.F.T.M.i.r.r."

The image I had zipped (image[3326976000-3332096000].dd) and posted was from the actual disk.. Maybe the read errors prevented the backup of those sectors.

Your "quest" is not (yet) finished.

That would be too easy, yes?

Theoretically this would be around sector 206848+976564224/2=488488960, possibly the already given 488488952

So you should GOTO sector 488488000 (to be on the safe side) and search again for "46494C4530".

Forgive me, I may be missing something.

The math in the first equation seems off.. I got.. 206848+976564224/2=488385536

I searched the failing drive from 488488000 for "46494C4530" and haven't found anything yet. @ 488492200 and counting..

Also, in the complete image I made with ddrd I only have '217356288' total SECTORS

I cannot search more than that.

Can you also please post the actual EXACT size (in bytes) of the whole image taken (just to make sure I can replicate it "virtually")?

in TinyHex - total / 217356288

in ddrd actual failing disk - total / 976768065

The condition of the $MFT is not at all "bad", at least form the set of sectors you posted.

If the drive is still functional after the Seagate guy's attempts (if any) a good idea would be to try again imaging a bunch of sectors, trying this time "backwards".

The drive appears to be in the same state it was in when I gave it to him (same read errors?).

The same range [3326976000-3332096000] would do nicely . (the missing two first sector of the $MFT are now filled with 00's or FF's and this may be a sign of a read error, that in some cases can be avoided by imaging "backwards", also, try doing this partial image a couple of times, once as soon as the disk is on - "cold disk" - and once after the disk has been powered by at least half an hour - "hot disk", you never know).

Let me try this out. in ddrd on failing disk:

• Start: 332697600
  
• End: 333209600
  
• Size: 512000
  
• Read Direction: <--
  
• produced a 250MB file, compressed to 252KB (attached)
  

EDIT: Strange, but I checked '6498306' on the failing disk and the result was totally different, there was no $MFTmirr.

Now I'm searching for ($.M.F.T.m.i.r.r) '24004D00460054004D00690072007200' from SECTOR 488380000 on the failing disk.

image170341171200-170603315200.zip

Edited July 29, 2012 by d8apzl

[jaclaz]

Let's see if we can clear the "math" aspects.

The partition table in the MBR says that you have two partitions.

#0 07 00 0 32 33 12 223 19   2048 204800
#1 07 80 12 223 20 1023 254 63   206848 976564224 

The above data is expressed in sectors (i.e. you multiply them by 512 to have bytes).

So you have:

2,048 "unused" sectors

204,800 sectors used by first partition

976,564,224 sectors used by second partition

2,048+204,800+976,564,224=976,771,072 sectors x 512 = 500,106,788,864 bytes <-this is the theoretical size of the whole disk (and of the image)

Addresses in the MBR are expressed in sectors and relative to the beginning of the disk.

Addresses in the PBR or bootsector are expressed in clusters and relative to the beginning of Volume (in your case, like in, say, 99.99% of cases, your filesystesm uses clusters 4,096 bytes in size). This means that a cluster is 8 sectors.

On your volume "range of size" the NTFS by default will place the $MFT at cluster #786,432.

786,432 x 8 = sector #6,291,456 but since the volume starts @ (2,048+204,800)=206,848 when you access the whole disk or the image, it will be on sector (206,848+6,291,456)=6,498,304

Still by default, the $MFT Mirror is placed at 1/2 (one half) of the Volume.

So - seemingly- @ 976,564,224/2=488,282,112 which corresponds, when you open the whole disk or image to 206,848+488,282,112=488,488,960

But the above is "wrong", because there are two things I omitted:

1. since it is an address inside the volume, it has to be accessed in clusters
   
2. there is always one sector after the volume but inside the space reserved for it dedicated to the backup of the bootsector
   

In reality, the volume can be at the most 976,564,224-1= 976,564,223 sectors, which, in clusters means 976,564,223/8=122,070,527.9 clusters

So, if you do 122,070,527/2=cluster 61,035,263,5, and in bytes 61,035,263 x 8 = 488,282,104 bytes.

Consequently the %MFT mirror should be @ 206,848+488,282,104=488,488,952, or, more simply, one cluster before what you would expect by doing the simplified calculation.

I hope the above explains it all .

I'll check the new file extracted and let you know.

Edit: quickly checked, I now see where the problem is .

You are continuing to "mix" between the "sectors" and "bytes" fields of the datarescuedd tool.

I asked you the SAME range you had already posted that in bytes was (the datarescuedd uses bytes in filenames):

[3326976000-3332096000], but what you now posted is:

[170341171200-170603315200]

You evidently had issues of some kind with datarescuedd.

You have a PARTIAL image.

We are doing a "Clone", so if the original is 976,768,065 sectors or 500,105,249,280 bytes, the copy, strangely enough, has to be the EXACT same size.

Go back to square #7:

and this time READ the post and the given links.

In explorer the size of the image MUST be (Properties) EXACTLY 500,105,249,280 bytes.

Or if you need to do partial images, the re-assembled file MUST have the same exact size....

Still there is an inconsistency with the theoretical size as calculated from the MBR data, but that could be irrelevant or caused by some miscaòculation/corruption, all the other data seems like "consistent".

jaclaz

Edited July 29, 2012 by jaclaz