Skip to main content

Windows Volume GUIDs changed after recovery of GPT disk

Thread needs solution
Beginner
Posts: 1
Comments: 0

I did a backup and restore of a whole Windows disk with GPT with Acronis True Image 2019 Rescue boot media on the same PC (the data partition itself, the EFI partition and a track 0). What I noticed was that after recovery, the volume GUIDs shown inside Windows are different, whereas I need the volume GUID to be the same as before the backup since some Windows functionality (UWF) relies on them.

When I was doing backup/recover with an MBR disk, the volume GUIDs were stable when checking "Recover disk signature" during recovery. However, the checkbox is not available for the GPT disk.

Is there any way to get stable volume GUIDs?

0 Users found this helpful
Forum Hero
Posts: 70
Comments: 8349

I haven't seen this answered yet... I wonder if it is to prevent boot collisions with modern UEFI/GPT bios?  I'm really not sure.  A couple of old threads on this:

https://forum.acronis.com/forum/acronis-true-image-home-forum-older-versions/restore-gpt-disk-no-longer-allows-signature

https://forum.acronis.com/forum/acronis-true-image-2019-forum/restore-and-disc-signature

However, as a work-a-round, I found a post by Mustang suggests it can be manually modified with diskpart to make it the same again if need be.

https://forum.acronis.com/forum/acronis-true-image-2017-forum/disk-signature-reassignment-during-disk-cloning

And example instructions that seem pretty straight forward:

https://www.thewindowsclub.com/disk-signature-collision-problem

For example, you can set the new id as uniqueid disk ID= 1456ACBD

Beginner
Posts: 1
Comments: 1

In Acronis 2020 (perhaps for 2019 as well), selecting each individual partition in the restore (but not the full disk checkbox), will result in the existing partition GUIDs on the disk being preserved. They won't be made to match your backup source, but the restore operation won't change them any further.

However, as you've noted, if you do a full disk restoration, the partition GUIDs will always be changed to be different from the backup source. If the existing full disk GUID in LBA1 matches the backup source, it will be preserved (as will any "disk signature" in the protective MBR), but those are also regenerated to random values if what is currently on disk does not match the backup source.

I assume this is all to be super defensive about disk clashes, but it's annoying that the software provides so little control. I would just use the "select all the partitions, but not the full disk" approach, except that that method doesn't restore the rest of "Track0" between LBA34 and the start of the first partition.