cgsecurity.org

I won't bother you with how it happened but this happened:

A backup disk had this on it

WD30EZRZ 00Z5HB0 ( 3 TB )

I:DATABU 49 GB
J:ProgramsBU 49 GB
K:FILMSBU 1200 GB
L:GGEDBU 1200 GB
M:BACKUP 353 GB

I guess windows makes that a GPT then.

I wanted to install a fresh win 7 as I do every year to my SSD with all

the other disks discoupled. Accidenly I discoupled the SSD and not the

backup disk
So I executed to this disk:

Diskpart
List disk 1
Clean
Create partition primary size=120000 align=4096 l
Format fs=ntfs quick
Active (assuming I want to install an OS)
Exit

and installed win 7 on it to find out after reboot and coupling
all the disks my mistake.
After installing win7 the right way now Windows disk management then gives

on theBUdisk ofcourse a first partition of about 120 GB Primary, active,

(which has about 21 GB written to it). About 2 TB not
assigned and beyond the 2 TB a partiton also not assigned and not
assignable because the disk is now with MBR.

I copied the disk to another one of the same making and size.

I ran testdisk with partition table set to Intel and got


Continue:


adjusted that to get the maximum green partitions. The first is the win7
the second the datbu which I can mis because of backups on external disks
the las four are respectively the former J,K,L,M partitions :


See further below.

Unfortunately some screenshot are missings...
You really should choose EFI GPT, Analyze, Quick Search, Deeper Search. Use the arrow keys to select which partitions you want to keep/recover, switch them to P(rimary).

The missing pictures:

Continue and Write:


Until here I did it all before with the disk set to MBR ( as was )
Because the M partiton was missing I repeated all with the disk set to GPt
with MiniTool Partition Wizard 10 and continued with below hoping to get
the last partition with that.

Analyse after write:


obviously there is a spaceconflict between former L and M.

So after reboot diskmanager shows again:


See further post below.

I think that with the write the disk was set to MBR .I'm not sure because
now there is more then 2 TB assigned. So I might got confused.
So I converted the disk to GPT again and did an EFI GPT quick search.
Result after about 30 hours:


All showed innitialy Deleted and the ones set to P were the only ones
with readable with files in it.
I did start a deep search now ( I know I should have stoped the qs and
started the deep scan right away) but I think that might be of no use.:


So I think the sugestion ""Patrick77, after selecting the disk, you choose
[EFI GPT] instead of [Intel].
Once it's done, Analyse, Quick Search... When all your partitions are
listed, choose Write, confirm, Quit" wouldn't help.

Now I'm thinking of stopping the deep GPT search and going back to the
situation as shown in the disk manager picture and work from there.
Maybe delete the last two partitions > ad new partitions and copy the
missing files from the original disk in to the new partition.
Is that posible and how should I do that?
Edit 17/8 19:25 Did'n't work. Couldn't convert to GPT probably because that wrong disk size.

Thank you for reading this far and I hope anyone can help.

edit: I stopped the gpt deepsearch. I have been busy for 6 days now.
Think it would have been faster just to make all the partitions on the new disk
and copy all the files to it. Should I just do that now? And how would I do that best?

Edit 19:28 I'll try tomorrow to do what I said last. Think I put testdisk in the new PROGRAMSBU and work from there.

GPT is recommended for disk over 2 TB.

I finished the copy and I could copy the files from all the partitions on the overwritten disk.

Unfortunately quite a few files from all partitionsappear to be faulty one way or another.
Some zipfiles which looked good couldn't be opened too. Luckely for some of the important ones
I have a second or even a third backup.

The faulty files looked for instance like this:

583 -r--r--r-- 0 0 47755504 27-Feb-2017 11:52 office_free_2013.exe
583 -r--r--r-- 0 0 64 27-Feb-2017 11:52 office_free_2013.exe:$CmdTcID
583 -r--r--r-- 0 0 26 27-Feb-2017 11:52 office_free_2013.exe:$CmdZnID
583 -r--r--r-- 0 0 26 27-Feb-2017 11:52 office_free_2013.exe:Zone.Identifier

or

581 -r--r--r-- 0 0 25612337 12-Nov-2017 11:56 stellarium_user_guide-0.16.0-1.pdf
581 -r--r--r-- 0 0 26 12-Nov-2017 11:56 stellarium_user_guide-0.16.0-1.pdf:Zone.Identifier

The first files with $CmdZnID are always 64 bytes. The second and with the Zone.Identifier 26 bytes.

Now I'm doing a deep GPT search nevertheless to find out what that gives. ( still about 40 hours to go I think )

To be continued.

Well the GPT deep search finished last evening late. That was with the orginal disk still set at MBR
and that gave some unrecoverable partitions. Helas I couldn't continue this morning because a power loss
during the night so I couldn't make pictures from the result so far and what would be there after "continue".
Since I got my two biggest partitions recovered and have backups or the actual files on other diks
of the other three partions I call it a day.