"Quick Search" Comparison for EFI GPT and Intel MBR

How to use TestDisk to recover lost partition
Forum rules
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
Post Reply
Message
Author
azer25
Posts: 4
Joined: 21 Mar 2025, 12:48

"Quick Search" Comparison for EFI GPT and Intel MBR

#1 Post by azer25 »

Hi,

Is "Quick Search" faster when the partition is in Intel MBR than when it is in EFI GPT?

I have a 1TB external HDD. One of its partitions became RAW.

TestDisk automatically detected EFI GPT which I validated by leaving it as is. I launched Quick Search, the search took 4 days non-stop. Unfortunately, TestDisk told me that the partitions are unrecoverable!

I had used the same process for the same problem some time ago, and I was able to recover the data.

So I quit TestDisk and restarted it, this time choosing "Intel" and launched "Quick Search". The search this time was much faster, it took approximately less than 3 hours! The data counter was moving much faster.

The question here: Is "Quick Search" faster when the partition is in Intel MBR than when it is in EFI GPT? Have you observed the same thing?
recuperation
Posts: 3163
Joined: 04 Jan 2019, 09:48
Location: Hannover, Deutschland (Germany, Allemagne)

Re: "Quick Search" Comparison for EFI GPT and Intel MBR

#2 Post by recuperation »

I don't know and I don't care because I let TestDisk run unattended.

If your partition search for a 1 TB secret disk (no further information given) lasts four days, this is definitively too long.
If your USB connection is OK, then this results suggests lots of unreadable sectors.

By the way, instead of running TestDisk immediately you are always better of reading out SMART parameters first, cloning the disk using ddrescue as described in the manual and running TestDisk against the physically healthy cloned disk.
Post Reply