Partition Table messed up (conversion GPT -> MBR)

[fabrizius]

Hey,

I tried to convert my external 2TB HDD from GPT to MBR because it was not recognized by the Raspberry Pi. I used Acronis Disk Director 12 for the conversion. The process didn't finish so I decided to cancel the process after a few hours. Canceling also did not work so I forced the process to quit because I did not know what else to do.
Now Windows Disk Management recognized the whole drive as unallocated. Then I tried to restore the partitions by giving the Acronis Recovery Wizard a try. The process finished but I'm not pleased with the result.
I tried several tools like Testdisk, zar and dmde to restore my partition table to access my data again but so I far I wasn't lucky.
I recovered all my photos to another disk with Photorec but all meta data is lost.

For some more detailed information please have a look at the following link: http://www.tomshardware.co.uk/answers/id-2645879/partition-table-messed-conversion-gpt-mbr.html

Does anyone have an idea how I can fix the partition table in a way that I can access the data again?

[pcimage]

Try some recovery software such as rstudio, or getdataback, or reclaime.

There are plenty about.

[fzabkar]

Try some recovery software such as rstudio, or getdataback, or reclaime.

There are plenty about.

I don't believe that any of those programs will be able to do any better than Photorec, and that's due to the specific nature of the problem. In fact it should be possible to do an almost perfect manual recovery, if you understand the problem.

The problem is that the user's drive was truncated by GigaByte's BIOS which reserves about 2000 sectors for its backup. When Acronis Disk Destructor tried to convert the GPT structure to MBR, it realised that the existing partition was too big to fit on the now truncated physical drive, and it tried to "fix" this anomaly by moving the entire partition approximately 2000 sectors toward the front of the drive. Unfortunately this process did not complete.

The OP now has a shifted data segment at the beginning of the partition, followed by a gap, plus the remainder of the original partition. The metadata would be referencing sectors on the other side of the gap. AISI the solution is to locate the gap and then image the two data segments on either side and combine them to recreate the original partition. This is something that should not pose too much of a challenge when the drive is in front of you, but would be more difficult to do interactively with the user.

[pcimage]

Try some recovery software such as rstudio, or getdataback, or reclaime.

There are plenty about.

I don't believe that any of those programs will be able to do any better than Photorec, and that's due to the specific nature of the problem. In fact it should be possible to do an almost perfect manual recovery, if you understand the problem.

The problem is that the user's drive was truncated by GigaByte's BIOS which reserves about 2000 sectors for its backup. When Acronis Disk Destructor tried to convert the GPT structure to MBR, it realised that the existing partition was too big to fit on the now truncated physical drive, and it tried to "fix" this anomaly by moving the entire partition approximately 2000 sectors toward the front of the drive. Unfortunately this process did not complete.

The OP now has a shifted data segment at the beginning of the partition, followed by a gap, plus the remainder of the original partition. The metadata would be referencing sectors on the other side of the gap. AISI the solution is to locate the gap and then image the two data segments on either side and combine them to recreate the original partition. This is something that should not pose too much of a challenge when the drive is in front of you, but would be more difficult to do interactively with the user.

Maybe so, but the aforementioned programs may be easier for the OP to use and lessen the chances of mistakes.

Just my opinion. You advise as you see fit.

[fzabkar]

The point I am making is that no matter how user friendly those programs may be, they cannot possibly achieve the desired end due to the unusual nature of the problem. For example, if the MFT (which contains the file name) is pointing to a file at sector X, the actual file will be at sector X+2000.

ICBW though.

[fzabkar]

@fabrizius, you said that you tried recovering your data with various tools but your results were unsatisfactory. I suspect that files near the beginning of the partion would have been OK but files near the end would have been corrupt. Am I correct? If so, could you examine a good file, eg a JPG, with a hex editor, eg HxD (http://mh-nexus.de/en/hxd)? Look for a "JFIF" signature or similar at the beginning of the file. Now open a corrupt JPG file in your editor and search for this same signature. If my hypothesis is correct, you should find this signature at around 2000 sectors into the file.

[fzabkar]

This is what I think happened:

Code:

            .-------------------------------------------------------.
            |                                                       |
            |  MFT  FileA           FileB              FileC        |   original FS
            |                                                       |
            '-------------------------------------------------------'


            .--------------------------------------------------......
            |                                                  |    |   Gigabyte BIOS
            |  MFT  FileA           FileB              FileC   |BIOS|   backup and HDD
            |                                                  |    |   truncation
            '--------------------------------------------------''''''


       .-------------------------+----+------------------------......   incomplete
       |                         |    |                        |    |   partition
       |   MFT  FileA         Fil|    |eB         x    FileC   |BIOS|   shift by
       |                         |    |                        |    |   Acronis
       '-------------------------+----+------------------------''''''
                                 |    |
                             --->|    |<---

                             2113 sector gap

AISI, FileA would be recovered correctly, FileB would be damaged in the middle, and FileC would be damaged at the beginning. The MFT would expect to find FileC at sector x, not at its original location.

Perhaps I'm underestimating the ability of R-Studio and GDB, but ISTR at least one case where a user was unable to effect a proper recovery after a failed partition move.

[fabrizius]

Hey, thanks for the advice but I can't find a single corrupt jpeg among the recovered files. Every single one of them seems to be OK.
Maybe it's not as bad as it seems but the metadata of thousands of pictures is lost. It can't be too bad if all the jpegs were recovered, no? :/

[fzabkar]

You need the MFT to recover the file and folder names, but you can't use the MFT to recover the file contents. PhotoRec will recover the files intact because it doesn't use the MFT to locate them (it just looks for header information), whereas tools that rely on the MFT will produce corrupt results. At least that's how it appears to me.

At the outset you stated that the initial recovery (with Acronis or other tools) was "unsatisfactory". I assumed this to mean that at least some of the files were corrupt. These were the files that I was hoping to examine. Do you have an example? You could use DMDE to view the folder structure and "recover" a recent file to another drive. This file will most likely have been written to the end of the partition.

BTW, did you have any luck with the tools suggested by pcimage? It could be that I have misunderstood the nature of your problem.

[fabrizius]

Okay I understand. Dmde and easyrecovery recovered some corrupt files. I found two files among them - a working one and a corrupt one with almost the same file name. The working one has the JFIF right at the beginning at offset 6. The corrupt one has the signature at 9006.
So far I only did read operations with the HDD because I fear that I make it worse if I try to do something else and because I do not have a full backup (only recovered the pictures without metadata).

[fzabkar]

An offset of 0x9000 corresponds to 72 sectors. I was expecting something of the order of 2113, ie at offset 0x108206 or thereabouts.

Can you find any other JFIF signature within this file?

[fabrizius]

No, in this particular file there's no other signature. Some working ones have the EXIF signature at the beginning and a corrupt one has it nearly at the end of the file at 1BE006. I can't see a pattern or something..

[fzabkar]

If you edit the first corrupt file and remove the stuff before 0x9000, does the edited file show up in your image viewer? If so, does the image match the file's name?

[fabrizius]

I removed the stuff before the signature on 3 files. #1 was recovered completely (meta data and filename). #2 was recovered almost completely (some glitches at the bottom of the image) the file name and meta data matched. The last one also has glitches at the bottom and the image does not match the file name.

[fzabkar]

ISTM that the damage to files #1 and #2 is consistent with a shift toward the beginning of the drive. However, I don't understand why each file's metadata is not shifted by the same number of sectors. In short, I think your testing confirms the nature of the problem, but I don't think that there is an easy solution for recovering your filenames.

You could try sorting PhotoRec's results:

http://www.cgsecurity.org/wiki/After_Using_PhotoRec
http://builtbackwards.com/projects/photorec-sorter/

[fabrizius]

The problem seems to be similar to what you described, yes. I'm starting to believe that there's no easy way to get the meta data of my photos back.
Any suggestion what tool or operation to use to give it a last try? I'm close to giving up, then I can at least use the drive again...

[fzabkar]

I think there should be tools that can at least organise your files based on the signature (eg Exif, JFIF) and/or the date/time stamps, camera model numbers, etc. Even the File/Folder search function of Windows can do that.

Here is an example:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  FF D8 FF E1 1B C1 45 78 69 66 00 00 49 49 2A 00  ÿØÿá.ÁExif..II*.
00000010  08 00 00 00 09 00 0F 01 02 00 05 00 00 00 7A 00  ..............z.
00000020  00 00 10 01 02 00 0C 00 00 00 80 00 00 00 12 01  ..........€.....
00000030  03 00 01 00 00 00 01 00 00 00 1A 01 05 00 01 00  ................
00000040  00 00 8C 00 00 00 1B 01 05 00 01 00 00 00 94 00  ..Œ...........”.
00000050  00 00 28 01 03 00 01 00 00 00 02 00 00 00 32 01  ..(...........2.
00000060  02 00 14 00 00 00 9C 00 00 00 13 02 03 00 01 00  ......œ.........
00000070  00 00 02 00 00 00 69 87 04 00 01 00 00 00 B0 00  ......i‡......°.
00000080  00 00 F8 01 00 00 53 4F 4E 59 00 00 44 53 52 2D  ..ø...SONY..DSR-
00000090  50 44 31 35 30 50 20 00 48 00 00 00 01 00 00 00  PD150P .H.......
000000A0  48 00 00 00 01 00 00 00 32 30 31 33 3A 30 35 3A  H.......2013:05:
000000B0  33 30 20 31 36 3A 30 35 3A 30 36 00 11 00 9A 82  30 16:05:06...š‚

ISTR that someone in this forum was sellling a tool that could sort and auto-rename such files.

[jermy]

ISTR that someone in this forum was sellling a tool that could sort and auto-rename such files.

It's not so hard to write that tool

[HaQue]

Until you actually start writing it and realise a week has passed, and all the other things you have been required to do have been neglected.. Things like that have a way of seeming deceivingly easy, then blowing out like crazy.

[michael chiklis]

I think there should be tools that can at least organise your files based on the signature (eg Exif, JFIF) and/or the date/time stamps, camera model numbers, etc. Even the File/Folder search function of Windows can do that.

Here is an example:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  FF D8 FF E1 1B C1 45 78 69 66 00 00 49 49 2A 00  ÿØÿá.ÁExif..II*.
00000010  08 00 00 00 09 00 0F 01 02 00 05 00 00 00 7A 00  ..............z.
00000020  00 00 10 01 02 00 0C 00 00 00 80 00 00 00 12 01  ..........€.....
00000030  03 00 01 00 00 00 01 00 00 00 1A 01 05 00 01 00  ................
00000040  00 00 8C 00 00 00 1B 01 05 00 01 00 00 00 94 00  ..Œ...........”.
00000050  00 00 28 01 03 00 01 00 00 00 02 00 00 00 32 01  ..(...........2.
00000060  02 00 14 00 00 00 9C 00 00 00 13 02 03 00 01 00  ......œ.........
00000070  00 00 02 00 00 00 69 87 04 00 01 00 00 00 B0 00  ......i‡......°.
00000080  00 00 F8 01 00 00 53 4F 4E 59 00 00 44 53 52 2D  ..ø...SONY..DSR-
00000090  50 44 31 35 30 50 20 00 48 00 00 00 01 00 00 00  PD150P .H.......
000000A0  48 00 00 00 01 00 00 00 32 30 31 33 3A 30 35 3A  H.......2013:05:
000000B0  33 30 20 31 36 3A 30 35 3A 30 36 00 11 00 9A 82  30 16:05:06...š‚

ISTR that someone in this forum was sellling a tool that could sort and auto-rename such files.

WinHex should be able to do that.