SOLVED!Restore partition to GPT disk screwed up entire disk.

[jbraner]

Hi,

I tried testing a restore today - using my linux rescue disk - and had a very unpleasant surprise.

- I had made a backup of a whole disk with 2 Windows partitions and a Data partition (plus EFI but lets not worry about that.)
- I then tried a "practice restore" of just the data partition to a different disk which has some free space on it.
- The destination disk is 3TB and has 2 other data partitions and a lot of free space.
- I tried restoring directly to the free space, and gave it a partition size to create.
- It completely hosed the whole destination disk!
- the partition manager in BIU seemed to think the disk was OK, but Windows saw the disk as empty, and Acronis disk director saw it as a MBR disk that had no partitions on it. (of course a 3TB disk can't really be MBR anyway)

- Then I deleted all the partitions and created new empty ones.
- I tried restoring one of the destroyed partitions of the destination disk (I had made a practice IFW backup earlier)
- this seemed to restore correctly - but again the entire disk was hosed! Same as above.

I went back to the BIU partition manager - and it still thought the disk looked OK (with the restored partition and the second empty one from the above process)
- In BIU partition manager I deleted the restored data partition - and then recovered it.
Lo and behold - now the disk is OK and Windows sees it OK. (I'm still restoring the second data partition because it was blown away earler)
So the "hosed" disk wasn't *that* bad - but obviously I can't do this after every restore (go to BIU part mgr, delete part, then recover it)

So - my question is this,
Obviously something is wrong. Do I need to check the "disk geometry" settings?
What would make the restore process (restoring just one partition) screw up the entire disk? (as far as Windows is concerned)
Come to think of it - why would BIU partition manager be perfectly happy with the disk - but Windows and the Acronis partition manager are confused?

After my first "mistake", I was literally restoring one partition to exactly the same disk as it was backed up from - so something is very wrong with my settings.

sorry for the long winded post - does anyone have any ideas about this?

Obviously - I'll do further experiments on a completely different "TEST" disk.

[TeraByte Support]

Sounds like a restore to the same slot (Move to Original Entry) type
option or restored after creating gaps and windows doesn't like any
gaps, hence the "Remove MS GPT Gaps" option on the boot item.

[jbraner]

TeraByte Support wrote:
> Sounds like a restore to the same slot (Move to Original Entry) type
> option or restored after creating gaps and windows doesn't like any
> gaps, hence the "Remove MS GPT Gaps" option on the boot item.

well, this option doesn't exist when restoring just one partition.
Yes - it is restoring to the same slot (that's not unusual) and Windows is perfectly happy with the disk as it is. It should also be happy when one of it's partitions is replaced with a near identical one.

This program seems geared to use with MBR disks. I've been experimenting all day today, and it seems like it's overwriting something on the first track - making it look like a MBR disk with one partition.
This must be like the "protective MBR" mentioned here
https://www.howtogeek.com/193669/whats- ... g-a-drive/

I've gotten to a point where after a restore, Windows sees the disk but it is offline due to a "signature collision". If I set it to online it seems happy - but this doesn't seem like a normal way to restore a partition.
The only setting in ifw (or ifl) having to do with signatures - seems to have to do with Windows drive letters - and I don't necessarily want to restore that - so it's deselected. I'll happily fix it in Windows (or Acronis drive director)

To recap:
- perfectly happy GPT disk
- two data partitions (yes there's free space in between them - this is perfectly normal as either one can be expanded easily - without having to shift an entire partition first)
- restore over the top of one of the partitions
- the "destination" partition will be blown away - perfectly normal
- after the restore, the entire disk looks OK to Terabyte utilities but
- in the Acronis utility it looks like like a MBR disk with one big empty partition
- in Windows it has the "signature collision" but can be put "online" and seems OK

This is not right.
At least today I found out that the entire disk is not destroyed - but ifl (and the ifw rescue disk does exactly the same thing) is messing with the first track, and maybe messing with the disk signature (as opposed to the Windows drive letter associated with it).
I'm trying all the combinations of settings, and not writing to first track (it still seems set to auto) and *everything* is deselected on the restore options screen.
Global options set to
align to 1MB boundries
Align MBR for BIOS auto mode (is this causing the problem?)
assume same target system
validate geometry before use
use source host geometry

Simple mode is not an option as it only restores "simple mode" backups

This is starting to seem more complicated than it's worth - this should be a pretty straightforward procedure, shouldn't it?

[TeraByte Support(PP)]

If it's just a signature collision issue, that's easy to avoid. If you're going to restore a partition that already exists in the system (that is, one with the same GUID) and you're not restoring over the existing partition, use the "Change GUID" restore option to have the restored partition assigned a different GUID. Otherwise, bringing it online with Disk Management is fine -- it will change the GUID.

As for the Acronis utility seeing an MBR type disk with one big empty partition, that's sounds normal since that's what a GPT drive MBR partition table looks like (one big partition). You would need to view it as a GPT disk.

[Brian K]

John,

I can confirm Paul's comments. In IFU I copied a data partition to another disk and didn't select "Change GUID". Booting into Win10 showed no drive letters for partitions on the target disk. Disk Management showed the disk was Offline. The partitions were present but there were no drive letters or partition information. Bringing the disk Online fixed it.

[jbraner]

TeraByte Support(PP) wrote:
> If it's just a signature collision issue, that's easy to avoid. If you're
> going to restore a partition that already exists in the system (that is,
> one with the same GUID) and you're not restoring over the existing
> partition, use the "Change GUID" restore option to have the
> restored partition assigned a different GUID. Otherwise, bringing it online
> with Disk Management is fine -- it will change the GUID.

Paul and Brian K
THANK YOU!!
That works fine!
I thought the GUID was for each disk - not each partition. :-\
I *knew* it had to be something I was missing! I know this product is mature - it *must* be able to do this easily...
(mind you - Acronis True Image just restores it without any mention of GUIDs etc)

>
> As for the Acronis utility seeing an MBR type disk with one big empty
> partition, that's sounds normal since that's what a GPT drive MBR partition
> table looks like (one big partition). You would need to view it as a GPT
> disk.

Nah - it knows what to do with GPT disks
[attachment=0]GPT disk.jpg[/attachment]
It just didn't know what to do when the GUID wasn't unique.

Rgds,