View Single Post
  #12  
Old February 17th 14, 03:45 PM posted to alt.comp.hardware.pc-homebuilt
Paul
external usenet poster
 
Posts: 13,364
Default Best app for partition recovery

Jim wrote:
On 17/02/2014 00:57, Paul wrote:
Jim wrote:
On 16/02/2014 20:48, Paul wrote:
Jim wrote:

Hi guys thanks for your replies so far i'm in a real pickle here.
The drive is a new WD3TB Black, however it is only showing up in
recover software as 747GB, i need it to be able to show me what is
on the whole 3TB drive any idea folks?
I love these fat drives but when you loose em it's a nightmare.

Jim

Piece of cake. I've seen this, but it's a function of
the OS you're using. I get similar symptoms in Win2K.
(I have a 3TB WD Black.)

It also depends, on what you used to prepare the drive.
Western Digital provides a free copy of Acronis TIH, suitable
for installing the Extended Capacity Manager. Only problem is,
at some point in the past, I installed some other Acronis
software, it installed a driver, and the driver was not
removable. So the new software, could not install its driver.
This complicates the process of getting the
Extended Capacity Manager working.

I can promise you, that the data is still accessible. I was
able to access the upper 747GB, using a loopback mount in
Linux, using a little-known offset parameter. That allows
me to get to the partitions that might be hiding up near
the end. But to do that, I had a fairly good idea, what
the offset should be. It only took a little bit of searching,
by taking snapshots with "dd", to figure out where the file
system header was.

I doubt one of the older data recovery programs is going
to be entirely happy working on your problem. So perhaps
you can provide a few details of what you've tried, and
I'll see if I can jog my memory as to what I did to fix it.

I've worked with the Extended Capacity Manager twice,
and both experiences were horrible (blinding rage horrible).

The Acronis TrueImage Cleanup Utility is here. It
can remove the old driver, if one is present. The Acronis
staff thought you could not successfully write one of these,
but a user in one of their forums, showed them how.
(If the driver is uninstalled in the wrong order, it
would cause the OS to blue screen.)

http://kb.acronis.com/content/34876

A standalone driver package exists. When I installed
this in Windows 8.1 Preview for example, I was able
to use the entire 3TB of disk, just as I see it in
WinXP today. But the required metadata was already on
the disk, for that driver to use.

https://kb.acronis.com/system/files/...ksetup2013.zip


But what that doesn't do, is it doesn't do the
Extended Capacity Manager step. ECM writes a 256KB
chunk of metadata, at the 2TiB mark. The upper virtual
disk, appears just after that point. And both times I
worked with ECM, it *refused* to allow me to click the
button, and install. And I didn't keep careful notes,
with all the flailing I was doing, of what fixed it.

So bottom line is:

1) Your data isn't lost. It can be accessed from Linux, for
free, with a bit of work. The upper 747GB or whatever,
is treated like a big bitmap. The -o loop option in the
Linux mounter, allows a file system to be mounted on a
mount point. Even though Linux would not normally allow
access above 2TiB on an MBR disk, the offset in the loopback
mounter supports 64 bit numbers.

2) Depending on OS, the OSes behave stupidly, even when you
do things mostly right. I've tried cranking down the
first 2TB partition by small amounts, to get them to behave
better. But I think what was really ****ing off the OS,
was cylinder offsets (WinXP style) versus megabyte offsets
(Windows 7 style). The Extended Capacity Manager, was using
one style on the lower disk, and another on the virtual disk.

Acronis should be soundly whipped, for the mess they made there.
Not a pleasant experience at all, and double the work for
me that it should have been. Thank God they made that
Cleaner utility, or I'd still be swearing and tearing
out my hair!

Paul
Hi Paul thanks for the reply, boy is this a can of worms i wish i had
never opened and stuck with my smaller 1TB Blacks.

OK when i started using these 3TB drives i was coming up withthe
2.2TB issue and suggested to use GPT or something like that but what
i didn't like was at the begining of the drive was a smaller 128mb
hidden partition so i wanted to find a way round it and format the
drive keeping it nice and clean and i used so many differnt apps to
get it the way I wanted i thinkn i used a free app from Paragon
called "Paragon partition manager free edition" but i can't be 100%
to be hobnest on how it was formated it could have been a number of
way. i was going to reformat it using GPT but thought better of it,
as yet i have wrote nothing to the dud drive. I know my data is there
but getting it is not straight forward.

I am running a new instal of win 7 U x64 to be honest i should be
able to get my hands on any of the latest software most offer
shareware with option to upgrade to recover so i'm happy to do that,
i'm willing to buy anything to get my data back.

Jim


According to this, the partition type on the protective MBR would be
0xEE if you had set it up GPT.

http://en.wikipedia.org/wiki/GUID_Partition_Table

You can use PTEDIT32, to look at the MBR partition table. Even if
it's the "fake" "protective" MBR, you can still look at it to verify
you did set it up as GPT. You unzip that first. Then, right click
on the ptedit32.exe program, and select "Run as Administrator". The
program returns an Error 5 if you attempt to use it without the
Administrator authority (since it accesses the raw disk).

ftp://ftp.symantec.com/public/englis...s/PTEDIT32.zip


Once you've got some positive feedback, as to what it is,
you can try TestDisk, as a confidence builder. The idea
would be, to see if TestDisk sees GPT or not.

http://en.wikipedia.org/wiki/Testdisk

"TestDisk recognizes the following disk partitioning:

...
GUID Partition Table === GPT
"

Note that, most of the time, you get an "opinion" from TestDisk,
and don't accept it's offer to write anything back. If you
need to quit TestDisk, you can press control-C to stop it.
It would probably take a long time, for it to scan the whole
disk on 1MB boundaries or something, looking for file system
headers. The reason for not immediately accepting an offer
to write a new disk header, is because it doesn't do enough
checks and balances. But still, it can be educational, to
see what it is capable of digging up.

TestDisk can display the file names in a partition it finds.
Which would be another confidence builder.

http://www.cgsecurity.org/mw/images/List_files.gif

( http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step )

*******

The article on "GUID_Partition_Table" says:

"GPT also provides redundancy, writing the GPT header and
partition table both at the beginning and at the end of
the disk.
"

That suggests to me, if something has "gone missing", it's
the file system header in the partition itself that
got damaged somehow.

You might also check Event Viewer, to see if the
software that attempts to mount file systems, has left
any error message(s) about what it found.

Using CHKDSK, would be reserved for the home stretch,
when the partition is mountable. CHKDSK is a double-edged sword,
in that, if the disk is health, it's probably worth running.
If the disk has problems with read/write or mechanical problems,
CHKDSK can make things much worse than when you started. CHKDSK
has been known to entirely trash a partition, when the disk itself
is sick or an IDE cable is slightly loose.

Paul

Afternoon Paul, well this is looking more worrying as it only ever seems
to show up as 750 odd GB, having ran PTEDIT32 and testdisk i took some
screen shots and stopped because testdisk gave a message saying not to
go any further if disk size was reported wrong which it is, below are
the links for screen shots.

http://imageshack.com/a/img716/2622/34nm.jpg
http://imageshack.com/a/img593/9896/gk7c.jpg

I was being quite optimistic last night and thought if this went well i
will not have enough spare space to take stuff off so i bought another
3TB Black last night, looks like i might have been kidding myself

Jim


Yeah, my problem is, I don't understand what the OS is doing
in this case.

Your first picture confirms GPT. That's the protective or fake
MBR we're looking at. And the size field corresponds to 2TiB
for the fake (as large a 32 bit unsigned number as possible).

The second picture, looks like what I might see on Win2K.
And I don't understand what Win2K does in that case. I mean,
I could understand, if some math was done with 32 bit unsigned
arithmetic, that is where the 747GB number is coming from.

I guess I could ask silly questions, like is the current OS
viewing the drive, the same OS as prepped it in the first place.
I checked the Wikipedia article, and GPT is supported in
Vista/Win7/Win8. As well as Ubuntu 8.04 (it's up to 13 now).

The BIOS may play some part in this. It probably reports the
size of the drive, to the OS at some point. Choices for
information presentation, would be a CHS tuple (fake geometry)
and LBA size (let's hope that is a 64 bit number). At that point,
I kinda lose my theoretical footing, like what might convince
the BIOS to screw up.

So a possible solution there, would be to write down any
custom BIOS settings, then try a Clear_CMOS. That procedure,
using the jumper, is only to be done with the computer
unplugged. That's a conservative practice, that prevents
bad motherboard design, from causing damage. Some motherboards,
the CMOS jumper shorts something that can burn a particular
component. The user manual would probably say, to remove
power from the computer. In years past, I've found a number
of manuals with mistakes in that section. Including a manual
that encourages you to leave the jumper in the wrong position.
The purpose of clearing CMOS, is to have the BIOS regenerate
the datafill of the CMOS RAM.

Some BIOS have a "Load Default Settings" option. While you could
try that, it may not clear every byte in the CMOS RAM. But may be
sufficient in this case (no reason to assume the un-defined areas
of CMOS, cause the symptoms). After Load Default Settings, doing
a Save, then you go back (without booting the OS) and enter
the custom settings you wrote down earlier. For example, on my
older P4 machine, if I clear CMOS, I have to remember to disable
the Promise Controller, and correct a couple other settings
that don't have good default values. On the machine with the
sound card, I might disable motherboard audio. Just trivial
stuff. Several of my machines might have custom RAM timing,
and I'd have to put that back.

I haven't been able to figure out, where else the geometry
information is coming from.

So some quick tests would be:

1) Boot an alternate OS, and see if the same size value is
visible. If the entire GPT is visible and working, now
you're ready to transfer to another drive.

2) If the alternate OS suffers from the same problem, try
to Clear CMOS or Load Default Setup. Reloading settings
as before. Most IDE disk setting, would be set to LBA,
rather than Large or CHS. Each alternate setting, can have
an effect on the geometry information the BIOS passes to the
OS.

Other than that, because I don't understand what party
is playing with the geometry, I don't know what knob to turn
next. I mean, if I knew, I would have fixed this on my
Win2K installation, so that my 2TiB drive would stop showing
up as the wrong size. Fortunately, nothing bad has happened
with all those size issues. Only if a partition "spans" a
capacity barrier, do you run the risk of corruption.

*******

This page gives some idea, of the sources of geometry info.
(Click the "X" to dismiss the popup they overlay on the good stuff.)

http://support.novell.com/techcenter...assel_edd.html

BIOS: CHS = 10/8/8 bits 1023/255/63
LBA = 64 bit number

Stored on disk itself (MBR?) = CHS, different than BIOS.
Using fake geometry here, allows
changing disk alignment (like on SSDs)
I've done this once, just for kicks.
Changed sectors to 56 or something.

You can see in this example, that Linux appears to have an
interface to the CHS stored in the MBR. You can pass values
on the command line.

http://manpages.ubuntu.com/manpages/...8/fdisk.8.html

OK, it just occurred to me, the PTEDIT32 has a display of
on-disk CHS value. Yours is 97451/255/63. Doing the arithmetic
(roughly, by ignoring whether I'm supposed to be adding one to
one of those fields or whatever)

97451*255*63*512 = 801,561,761,280 --- 747GB

Oh, dear. So that's where the size is coming from. OK, I'm going
to have to shut down the PC, and plug in my 3TB drive now, for
comparison. Of course, it isn't GPT, so the comparison isn't exactly
valid.

Back in a moment...

Paul