diskpart clean + cre par (GPT, exFAT)

[temp657473467657]

I just broke 4TB external HDD, most likely GPT with single exFAT partition (few hours ago tried to use it as destination for Win10 system image when replacing SSD in another machine, but the target has to be NTFS so I assume this one was exFAT).

In diskpart I chose incorrect drive and used commands "clean" and "cre par pri" so the disk was initialized again as GPT. In TestDisk I tried to change the "new" partition type to exFAT and preview the files, but TestDisk told me the FS is corrupted. Scanning GPT in Testdisk is painfully slow, one cylinder per 2-3s (486400 total) and would take ages to complete.

If recovering the partition is even possible, is there a quicker way?
Thanks in advance!

[recuperation]

I just broke 4TB external HDD, most likely GPT with single exFAT partition (few hours ago tried to use it as destination for Win10 system image when replacing SSD in another machine, but the target has to be NTFS so I assume this one was exFAT).

In diskpart I chose incorrect drive and used commands "clean" and "cre par pri" so the disk was initialized again as GPT. In TestDisk I tried to change the "new" partition type to exFAT and preview the files, but TestDisk told me the FS is corrupted. Scanning GPT in Testdisk is painfully slow, one cylinder per 2-3s (486400 total) and would take ages to complete.

If recovering the partition is even possible, is there a quicker way?
Thanks in advance!

Assuming a native speed of 120MB/sek Testdisk should run around 10 hours and not 270 hours according to your description.
You have a problem with your interface, your drive or both.

[temp657473467657]

In the meantime I tried searching with assumption that it was MBR, and then the search speed seemed normal. In GPT it's around 13MB/s according to Task Manager.

[recuperation]

If the sector size of your external drive is 512 Bytes emulated your partition table should be GPT.
If its 4096 it can be MBR as well.
13 MB/second seems to slow.

[temp657473467657]

Yes, it is recognized with 512b sectors and most likely it was GPT. I definitely haven't changed it to MBR myself especially in this capacity, and I doubt Seagate would do it in factory.

"MBR" was chosen only for scan speed testing. Scanning with GPT setting is painfully slow, I tried also on another PC and/or 32/64bit application, and previous version as well. The disk isn't fast, uses SATA-USB3 bridge and SMR technology impacting writes, but read speed was always consistent. We can safely assume its technical condition is all right.

[recuperation]

In the meantime I tried searching with assumption that it was MBR, and then the search speed seemed normal. In GPT it's around 13MB/s according to Task Manager.

MBR seems to restrict the initial search to cylinder boundaries which does not appear correct for your case.

We can safely assume its technical condition is all right.

"We" is not "me".

[temp657473467657]

What do you suggest then?

Is TestDisk generally able to restore the deleted partition(s) in such cases? In other words, is it worth to run the scan and wait for days, with non-zero success chance?
I saw a few other topics with extremely low scanning speed of large GPT disks, but without any hints what to do and/or what is the cause.

[recuperation]

What do you suggest then?

Is TestDisk generally able to restore the deleted partition(s) in such cases? In other words, is it worth to run the scan and wait for days, with non-zero success chance?

viewtopic.php?p=33087#p33087 Point 14

I saw a few other topics with extremely low scanning speed of large GPT disks, but without any hints what to do and/or what is the cause.

There a lots of topics containing hints relating to "smartmontools".