Partition Table
I have been searching for the past 4 hours and have been going through tons of pages on this forums, but I still cannot get a definite answer about the issue of the partition table when doing a full disk backup/restore.
All questions are pertaining to full disk backup/restore with the bootable media. I am not looking at file backup.
I hope those in the know can shed some light on these few questions I have:
- The MBR and Track 0 setting restores the entire MBR, except for the partition table. Correct?
- If a sector-by-sector backup is restored, does it restore the partition table, since it's sector by sector?
- What if a non-sector-by-sector backup is restored to an entire disk (means the "Disk 1" option is selected instead of individual partitions), would the partition table be restored?
Thank you.
The partition table would be restored in all of the examples you list.
Track 0 contains the MBR which occupies the first sector of the disk. The partition table is next on disk. Additionally track 0 may contain certain software licensing information.
The partition table would be restored in all of the examples you list.
Track 0 contains the MBR which occupies the first sector of the disk. The partition table is next on disk. Additionally track 0 may contain certain software licensing information.
Thanks for the reply.
I got that information from this post by Pat L, another Acronis MVP Volunteer, who got it from another post by Mark Wharton, also an Acronis MVP Volunteer.
Also, from another post:
restoring the MBR doesn't affect the partition table when restored alone, it does restore any boot code in the MBR (for example if you have a boot loader, code to boot into a recovery partitin, etc.)
Hence my first question, "The MBR and Track 0 setting restores the entire MBR, except for the partition table. Correct?".
There were also some other posts (over multiple pages of Google search) that I came across with contradicting information.
Particularly, one which I remember something along the lines of "restoring the MBR other than disk mode will not restore the partition table"...
Hence, my second and third questions, "If a sector-by-sector backup is restored, does it restore the partition table, since it's sector by sector?" and "What if a non-sector-by-sector backup is restored to an entire disk (means the "Disk 1" option is selected instead of individual partitions), would the partition table be restored?".
Track 0 on a disk occupies in most cases the first 63 sectors of the disk or 512 bytes. Track 0 contains the MBR, Disk Signature, and the partition table. To say that the partition table is not restored when recovery of Track 0 is performed does not make sense. To say that the resstore of Track 0 does not effect the partition table I can agree with.
I respect what Pat L and Mark Wharton have stated in their posts. It boils down to what restore and recovery mean I suppose. What I can say is this, a non sector by sector restore is a recovery of a snapshot of a full disk image of all data on a disk. A sector by sector restore is a complete sector recovery of all sectors of a disk including empty sectors. So the quesiton is then, would the 64 bytes of the partition table contained within the first 512 bytes of the first sector on a disk be recovered to disk during a restore operation? I think so, if not I think the disk would be unusable.
Maybe Pat L, Mark, or another MVP or Acronis Engineer or even another user will chime in here to clarify things for the both of us.
Track 0 on a disk occupies in most cases the first 63 sectors of the disk or 512 bytes. Track 0 contains the MBR, Disk Signature, and the partition table. To say that the partition table is not restored when recovery of Track 0 is performed does not make sense. To say that the resstore of Track 0 does not effect the partition table I can agree with.
I respect what Pat L and Mark Wharton have stated in their posts. It boils down to what restore and recovery mean I suppose. What I can say is this, a non sector by sector restore is a recovery of a snapshot of a full disk image of all data on a disk. A sector by sector restore is a complete sector recovery of all sectors of a disk including empty sectors. So the quesiton is then, would the 64 bytes of the partition table contained within the first 512 bytes of the first sector on a disk be recovered to disk during a restore operation? I think so, if not I think the disk would be unusable.
Maybe Pat L, Mark, or another MVP or Acronis Engineer or even another user will chime in here to clarify things for the both of us.
Yes, precisely, thank you. Now you see why I have those thoughts.
Let's hope someone else in the know can enlighten us.
So... No one from Acronis has any idea?
Do the people from Acronis even check this forum?!
It's a user forum - they do pop up from time to time though. Ultimately though, what's your goal? From personal experience, If I am imaging a full disk on the same machine that is going into the same hardware, I select all partitions, MBR and all - it's an exact copy of the drive that's currenlty in there. Never had a problem pushing an image back to the same machine (even when pushing to a new or different hard drive as long as the new drive is big enough to push the image back to).
When pushing to different hardware though, the recommended method is to not push back MBR track 0 and let Windows recreate that on the new system. Generally this works fine for me as well. Where people run into problems is when they try to push an image from one sytem that is not compatible with another one (and I'm not talknig about drivers). For instance, I have a UEFI only ASUS T200 that only installs as GPT. I can image it and push that image to my desktop or the same system without issue because both support UEFI and GPT disk in the bios. However, I also have an older HP Netbook that is only legacy BIOS (CMS) and only recognizes MBR. As a restult, I can push the image to it, but it will never boot because of limitations with the bios not supporting UEFI and/or GPT disks.
Acronis True Image 2016 allows you to select a partition layout for a target disk after clone operation completion:
- MBR (Master Boot Sector) - a 512-byte boot sector, which is the first sector of a hard disk, used to hold a disk's primary partition table.
- GPT (GUID Partition Table) - a standard for a partition table layout for hard disks. GPT allows disks/partitions size up to 9.4 ZB (9.4 x 10^21 bytes).
Using this wizard you may convert your partitions layout while cloning operation or clone them as is, not changing the layout.
- Copy partitions without changes - select this option to migrate your system as is, not changing the partition layout. Note, in this case the disk space in excess of 2TB will be inaccessible.
- Copy partitions and use a disk as non-system, GPT style - select this option to convert your partition to a GPT layout.
With Acronis True Image 2016 you also can convert BIOS to UEFI systems. For more information please see Unified Extensible Firmware Interface.
Also take a look at this one too...
Recovering your system to a new disk under bootable media
It's a user forum - they do pop up from time to time though. Ultimately though, what's your goal? From personal experience, If I am imaging a full disk on the same machine that is going into the same hardware, I select all partitions, MBR and all - it's an exact copy of the drive that's currenlty in there. Never had a problem pushing an image back to the same machine (even when pushing to a new or different hard drive as long as the new drive is big enough to push the image back to).
When pushing to different hardware though, the recommended method is to not push back MBR track 0 and let Windows recreate that on the new system. Generally this works fine for me as well. Where people run into problems is when they try to push an image from one sytem that is not compatible with another one (and I'm not talknig about drivers). For instance, I have a UEFI only ASUS T200 that only installs as GPT. I can image it and push that image to my desktop or the same system without issue because both support UEFI and GPT disk in the bios. However, I also have an older HP Netbook that is only legacy BIOS (CMS) and only recognizes MBR. As a restult, I can push the image to it, but it will never boot because of limitations with the bios not supporting UEFI and/or GPT disks.
Acronis True Image 2016 allows you to select a partition layout for a target disk after clone operation completion:
- MBR (Master Boot Sector) - a 512-byte boot sector, which is the first sector of a hard disk, used to hold a disk's primary partition table.
- GPT (GUID Partition Table) - a standard for a partition table layout for hard disks. GPT allows disks/partitions size up to 9.4 ZB (9.4 x 10^21 bytes).
Using this wizard you may convert your partitions layout while cloning operation or clone them as is, not changing the layout.
- Copy partitions without changes - select this option to migrate your system as is, not changing the partition layout. Note, in this case the disk space in excess of 2TB will be inaccessible.
- Copy partitions and use a disk as non-system, GPT style - select this option to convert your partition to a GPT layout.
With Acronis True Image 2016 you also can convert BIOS to UEFI systems. For more information please see Unified Extensible Firmware Interface.
Also take a look at this one too...
Recovering your system to a new disk under bootable media
One of my goals is to image a disk exactly as it is, then restore it (back to the same disk) at a later point in time.
But that is irrelevant here. I am not asking how to achieve it. I am asking IF it can be achieved.
I know the purpose of a sector-by-sector backup is to create a raw image of the disk, but I want to know if said raw image can be restored back "as it is", given that there are comments made by your fellow MVPs that the MBR and Track 0 setting do not restore back the partition table, which determines how the partitions are laid out.
If you do a full disk backup and do not do sector by sector, you disk will be exactly the same, however, anythign that was on the disk that had been marked as deleted, but not overwritten, will not be restored (technically it's aleady gone as far as Windows is concerned). Most people will use this method because it's faster and they don't care if the deleted files that may or may not be recoverable with other applications are transferred over. If you do need that piece of mind, do the sector by sector but it takes longer as it will backup the entire drive, even that which is marked as unused or previously deleted.
If you are restoring an image to the exact same system I always select all options, to include MBR track 0. Everythign restores exactly like it was on the original disk because you are restoring exactly what was originally written on the disk. You should do this even if transferring to another disk (say an upgrade from 250GB spinner to a new 500GB SSD). Everything will be exaclty the same.
If you are restoring an image to a new piece of hardware, don't restore the MBR track 0 (that's what Acronis recommends). I have done this though and it still usually is fine as well. However, it may not be if you restore this infomation and the BIOS is configured differently and not compatible (say if the image was originally MBR but the new system doesn't have legacy boot in the bios).
Don't take my word for it though. Test it to be sure. Hopefully you have a spare drive somewhere or can pick one up cheap or borrow one. Once you have one, swap it out with your main drive and push your image back and check the results. The biggest problem with most failed recoveries, is they were never tested until a failure occured and then it's too late. I understand not everyone does not have spare drives lying around or money to buy them for this purpose, but if your data is that important and/or restoring is that important, it should be part of the backup plan.
If you do a full disk backup and do not do sector by sector, you disk will be exactly the same, however, anythign that was on the disk that had been marked as deleted, but not overwritten, will not be restored (technically it's aleady gone as far as Windows is concerned). Most people will use this method because it's faster and they don't care if the deleted files that may or may not be recoverable with other applications are transferred over. If you do need that piece of mind, do the sector by sector but it takes longer as it will backup the entire drive, even that which is marked as unused or previously deleted.
If you are restoring an image to the exact same system I always select all options, to include MBR track 0. Everythign restores exactly like it was on the original disk because you are restoring exactly what was originally written on the disk. You should do this even if transferring to another disk (say an upgrade from 250GB spinner to a new 500GB SSD). Everything will be exaclty the same.
If you are restoring an image to a new piece of hardware, don't restore the MBR track 0 (that's what Acronis recommends). I have done this though and it still usually is fine as well. However, it may not be if you restore this infomation and the BIOS is configured differently and not compatible (say if the image was originally MBR but the new system doesn't have legacy boot in the bios).
Don't take my word for it though. Test it to be sure. Hopefully you have a spare drive somewhere or can pick one up cheap or borrow one. Once you have one, swap it out with your main drive and push your image back and check the results. The biggest problem with most failed recoveries, is they were never tested until a failure occured and then it's too late. I understand not everyone does not have spare drives lying around or money to buy them for this purpose, but if your data is that important and/or restoring is that important, it should be part of the backup plan.
Thank you for your reply.
As a matter of fact, I have briefly tested it before. I tried restoring a non-sector-by-sector backup to another disk and the result was different.
You should be aware that Windows create a MSR partition on UEFI systems. When I restored the non-sector-by-sector backup, the MSR position was changed. And yes, I could restore the MSR back to where it should be manually if the need arises, but that's not the point here.
Point is, either the full disk backup doesn't seem to be backing up the partition table, or the partition table isn't restored "as it is" when restoring a full disk backup.
Hence, my question on whether a non-sector-by-sector backup restores the partition table, and whether it would make a difference if a sector-by-sector backup was restored instead.
Honestly, not sure. That's more in depth of the Acronis backup capabilities than I'm aware. I can't say for sure why the MSR may have been resized or moved to a different location during your tests. I've read that the MSR partion is created by default on GPT disks - especially when Windows installs and it usually comes after the EFI partition, but before the OS. I also read that it starts out as a certain size (based on the original size of the disk) and may shrink if parts of it are used. Were the disks you tested on the same size, maybe that's why they were slightly different? Acronis uses compression (even with default settings) so perhaps the way the files are compressed and expanded during recovery, may slightly change the sizes after restore since the data is written in specific chunks - I'm not sure.
What I do know for sure is that I've never used a sector-by-sector backup in Acronis, but I have backed up and restored each of my three personal systems running Windows 10 x64 (as well as Win 7 x64 and Win 8.1 x64 with ATIH 2015 and 2016) on numerous occassions using the full disk backup and recovery method (I don't use the clone disk utility in ATIH either). After restoring those images, there are no apparent side effects, paritions seem to be in the same order as before. I am able to repartition and reallocate space fine in Windows and with third party tools like partizion wizard free mini tool. I also have a dynamic disk on one pc that seems to be working fine as well - it is a secondary storage disk and not the primary boot disk. Windows repair and recovery still functions as well. I can't see any negative impact of whatever process Acronis is using to backup and and restore images, if it is somehow modifying the MSR on UEFI systems.
Honestly, not sure. That's more in depth of the Acronis backup capabilities than I'm aware. I can't say for sure why the MSR may have been resized or moved to a different location during your tests. I've read that the MSR partion is created by default on GPT disks - especially when Windows installs and it usually comes after the EFI partition, but before the OS. I also read that it starts out as a certain size (based on the original size of the disk) and may shrink if parts of it are used. Were the disks you tested on the same size, maybe that's why they were slightly different? Acronis uses compression (even with default settings) so perhaps the way the files are compressed and expanded during recovery, may slightly change the sizes after restore since the data is written in specific chunks - I'm not sure.
What I do know for sure is that I've never used a sector-by-sector backup in Acronis, but I have backed up and restored each of my three personal systems running Windows 10 x64 (as well as Win 7 x64 and Win 8.1 x64 with ATIH 2015 and 2016) on numerous occassions using the full disk backup and recovery method (I don't use the clone disk utility in ATIH either). After restoring those images, there are no apparent side effects, paritions seem to be in the same order as before. I am able to repartition and reallocate space fine in Windows and with third party tools like partizion wizard free mini tool. I also have a dynamic disk on one pc that seems to be working fine as well - it is a secondary storage disk and not the primary boot disk. Windows repair and recovery still functions as well. I can't see any negative impact of whatever process Acronis is using to backup and and restore images, if it is somehow modifying the MSR on UEFI systems.
Yes, the MSR partition is created by Windows during installation, and as of Windows 10, is 16 MiB in size, comes after the EFI System Partition (ESP) but before the Windows partition.
With regards to the test that I mentioned in my previous post, I restored a non-sector-by-sector full disk backup with the abovementioned MSR to another disk, non-partitioned, and upon restoration, the MSR became the first partition and 128 MiB in size, which cast my doubts that True Image is restoring the partition table "as it is".
In your case, when you did the restore, was the disk already partitioned?
Whenever I do a restore of a full disk, I typically wipe the disk first using diskpart /clean. Then I initialize the disk and make a simple volume before pushing the image. Probably not necessary, but I've made this my standard practice because, in the past, with brand new disks, which are sometimes not initialized by the manufacturer, Acronis didn't always allow a disk to be used for recovery if it wasn't first initilaized.
If Acronis is not restoring the MSR in the exact same location, I'm not sure why that would be and you may be correct that it may not always restore the partition "as is". Perhaps this explains why it is moved first?
https://msdn.microsoft.com/en-us/library/windows/hardware/dn640535(v=vs…
Who creates the MSR?
The MSR must be created when disk-partitioning information is first written to the drive. If the manufacturer partitions the disk, the manufacturer must create the MSR at the same time. If Windows partitions the disk during setup, Windows creates the MSR.
Why must the MSR be created when the disk is first partitioned?
**After the disk is partitioned, there will be no free space left to create an MSR.**
The moving of the MSR partition to being located first on disk is a known result of the recovery process performed by True Image. The MSR changing size from 16 MiB to 128 MiB I believe is a result of the recreation and modification of the MSR to reflect changes in partition order. Logically this would also result in the modification and change to the partition table as well.
In the product documentation section 5.1.1.4 step 9, Recovering your system to a new disk under bootable media, you will note that "On the What to recover step, select the boxes of the partitions to be recovered. Do not select the MBR and Track 0 box." Reason being is that the MBR and Track 0 are recreated by True Image. Restoring the same image to the original disk from which the image was created this step is different in that the MBR and Track 0 are recovered along with the rest of the backup image.
In answer to the OP's question, again logically, True Image does in fact backup the Track 0 with partition table information during a full disk backup. If restoration is necessary to the same disk then Track 0 and MBR are selected during the recovery which restores the disk to an identical partition layout as was true when the backup was created. If recovery is necessary to a different or new disk Track 0 and MBR are not recovered from the backup image so the True Image can recreate them. If this were not the case then the above would not be true.
In practice it seems this step for some makes no difference when recovery is made to a new disk whether in fact the Track 0 and MBR are selected for recovery or not. This may not hold true for all recoveries however so the steps for recovery as outlined should be followed as specified in the documentation.
One of my goals is to image a disk exactly as it is, then restore it (back to the same disk) at a later point in time.
You may want to consider a hardware solution. The EZ-dock 3 clones disk to disk while not connected to a computer.
http://www.kingwin.com/storage/docking-stations/ezd-2537u3/
True Image 2016 will only restore the MSR partition to the correct location when performing a disk mode recovery to the disk from which the image was taken or if the new disk is the exact same size and model as the original. Unchecking the box for the MBR and track 0 results in a partition mode recovery. A partition mode recovery requires that the disk be initialized prior to the recovery. Using the Add New Disk utility in True Image will always create a 128MB MSR and place it first on the disk. MVP Mustang found that using diskpart to set the disk signature of the new disk to that of the original disk before performing a disk mode recovery with ATI2016 resulted in the correct placement of the MSR partition. In my testing I found that only worked when the disks were exactly the same size. Every disk imaging program I have tested handles the MSR better than True Image. The MSR partition should be visible during recovery and the user should be able to specify its location. Before I stopped using True Image I used a method very similar to the guide MVP Mustang posted in the following link to perform a recovery to a new disk.
https://forum.acronis.com/forum/101550
I contacted support about this issue shortly after the release of 2016. Their response resulted in the removal of True Image from all of my systems.
What are the negatives of having the MSR moved to the 1st partition and size increased from 16mb to 128mb (other than the meager 100mb or so difference)? I have never noticed any issues on recovered systems, so I've never seen this as an issue, but now I'm curious.
The moving of the MSR partition to being located first on disk is a known result of the recovery process performed by True Image. The MSR changing size from 16 MiB to 128 MiB I believe is a result of the recreation and modification of the MSR to reflect changes in partition order. Logically this would also result in the modification and change to the partition table as well.
In the product documentation section 5.1.1.4 step 9, Recovering your system to a new disk under bootable media, you will note that "On the What to recover step, select the boxes of the partitions to be recovered. Do not select the MBR and Track 0 box." Reason being is that the MBR and Track 0 are recreated by True Image. Restoring the same image to the original disk from which the image was created this step is different in that the MBR and Track 0 are recovered along with the rest of the backup image.
In answer to the OP's question, again logically, True Image does in fact backup the Track 0 with partition table information during a full disk backup. If restoration is necessary to the same disk then Track 0 and MBR are selected during the recovery which restores the disk to an identical partition layout as was true when the backup was created. If recovery is necessary to a different or new disk Track 0 and MBR are not recovered from the backup image so the True Image can recreate them. If this were not the case then the above would not be true.
In practice it seems this step for some makes no difference when recovery is made to a new disk whether in fact the Track 0 and MBR are selected for recovery or not. This may not hold true for all recoveries however so the steps for recovery as outlined should be followed as specified in the documentation.
So, if I understand you correctly,
- Full disk backup does back up the MBR and Track 0.
- When restoring a full disk backup to the same disk, True Image will restore the partition table "as it is". Does this apply to both non-sector-by-sector and sector-by-sector?
- But if a full disk backup is restored to a different disk, True Image will recreate the partition table. Likewise, does this apply to both non-sector-by-sector and sector-by-sector?
True Image 2016 will only restore the MSR partition to the correct location when performing a disk mode recovery to the disk from which the image was taken or if the new disk is the exact same size and model as the original. Unchecking the box for the MBR and track 0 results in a partition mode recovery. A partition mode recovery requires that the disk be initialized prior to the recovery. Using the Add New Disk utility in True Image will always create a 128MB MSR and place it first on the disk. MVP Mustang found that using diskpart to set the disk signature of the new disk to that of the original disk before performing a disk mode recovery with ATI2016 resulted in the correct placement of the MSR partition. In my testing I found that only worked when the disks were exactly the same size. Every disk imaging program I have tested handles the MSR better than True Image. The MSR partition should be visible during recovery and the user should be able to specify its location. Before I stopped using True Image I used a method very similar to the guide MVP Mustang posted in the following link to perform a recovery to a new disk.
https://forum.acronis.com/forum/101550
I contacted support about this issue shortly after the release of 2016. Their response resulted in the removal of True Image from all of my systems.
In my test, I did not use the "Add New Disk" function. I simply booted from the bootable media, browsed for the image file, select "Recover" and selected the destination disk.
Yes, the DiskPart script is one option of restoring the MSR manually.
What other disk imaging programs that you have tested, that handles the MSR correctly?
The one negative of relocating partitions that was a problem was that of breaking the recovery functions of Windows and OEM recovery partitions. On systems that have an OEM recovery partition which most pre-built boxes do. This has been addressed in True Image in the 2016 version.
Microsoft states that the MSR must be the partition immediatley preceeding the OS partition on disk. When that order is altered then the partitions become out of order so corrections must be made so that Windows and OEM recovery tools remain functional.
Bobbo. I think your questions about sector by sector and non sector by sector answer is yes in both 2 and 3 however, I have not tested these scenarios in a sector by sector restore to verify. I have done non sector by sector restores to both same and new/different disks and can verify that in such cases the answer is yes to both 2 and 3.
In the case of the my test restore to a new disk I used diskpart to convert the new disk to GPT which created the MSR partition as the first partition on disk. I then restored a backup image to that disk excluding Track 0 and MBR. This was completely successful so True Image made whatever modifications necessary to the MSR in its original location which logically I think would mean no changes were made to the MSR but changes were certainly made to the Track 0 and MBR as they were recreated by the True Image application. obviously.
I have wanted to test the following but simply cannot find the time it seems. I would like to take a new disk, convert it to GPT format, then install Windows 10 clean on the disk just to see what the Windows installer would do with the MSR partition. I am curious how serious Microsoft is about its statement that the MSR MUST immediatly preceed the OS partition. It the Windows installer moves the existing partition then I guess there may be some reason that I am not aware of that exists that makes this so.
The one negative of relocating partitions that was a problem was that of breaking the recovery functions of Windows and OEM recovery partitions. On systems that have an OEM recovery partition which most pre-built boxes do. This has been addressed in True Image in the 2016 version.
Could you elaborate on this? How was it addressed?
Bobbo. I think your questions about sector by sector and non sector by sector answer is yes in both 2 and 3 however, I have not tested these scenarios in a sector by sector restore to verify. I have done non sector by sector restores to both same and new/different disks and can verify that in such cases the answer is yes to both 2 and 3.
So, in my case, the position of the MSR changed because I restored to a different disk and True Image recreated the partition table?
In the case of the my test restore to a new disk I used diskpart to convert the new disk to GPT which created the MSR partition as the first partition on disk. I then restored a backup image to that disk excluding Track 0 and MBR. This was completely successful so True Image made whatever modifications necessary to the MSR in its original location which logically I think would mean no changes were made to the MSR but changes were certainly made to the Track 0 and MBR as they were recreated by the True Image application. obviously.
I was not aware DiskPart would create the MSR upon conversion to GPT.
If I understand you correctly, your MSR was the first partition before restoration. But what about in your backup image, was the MSR the first partition too?
I have wanted to test the following but simply cannot find the time it seems. I would like to take a new disk, convert it to GPT format, then install Windows 10 clean on the disk just to see what the Windows installer would do with the MSR partition. I am curious how serious Microsoft is about its statement that the MSR MUST immediatly preceed the OS partition. It the Windows installer moves the existing partition then I guess there may be some reason that I am not aware of that exists that makes this so.
On clean installation, Windows 10 will partition non-4K GPT disks on UEFI systems as follows:
Recovery - 450 MiB
EFI System Partition - 99 MiB (may be 260 MiB for 4K drives, since that's what Microsoft recommends, but I have never tested it before)
Microsoft Reserved Partition - 16 MiB
Windows - Remaining space
The abovementioned was the result from a clean installation of Windows 10 on an uninitialised disk.
I don't know where the MSR is located on previous versions of Windows since I have never installed them on GPT disks before, but I believe, to my best knowledge, that if your disk has already been partitioned (by previous versions of Windows or else), Windows may keep the partitioning as it is, even if you are doing a clean installation.
Could you elaborate on this? How was it addressed?
True Image was programmed to make the necessary changes in the partition table that reflect the new locations of partitions written to disk.
So, in my case, the position of the MSR changed because I restored to a different disk and True Image recreated the partition table?
Correct.
If I understand you correctly, your MSR was the first partition before restoration. But what about in your backup image, was the MSR the first partition too?
You understand correctly, the image I restored to the new disk was a clean install of Windows 10 which had a partition layout as you described above.
The GPT format defines the partition layout on disk. The MSR partition is a replacement for the hidden partitions of the older MBR format specification partition scheme. With GPT format hidden partitions are not allowed thus the purpose of the MSR. In general the MSR must be located on disk before any primary partition. The specification for GPT says that the MSR should be located after the EFI partition and any OEM partitions but MUST be located before the OS primary partition. See the Wiki link below:
https://en.wikipedia.org/wiki/Microsoft_Reserved_Partition
I am confident that if you were to test my example of converting a disk to GPT and then performing a clean install on that disk the Windows installer would move the MSR to conform to the specification above. I belive this to be so because that is essentially what occurs when you perform a clean install of Windows 10 anyway. The first step is that the disk is converted to GPT and then the installation is run which then formats the disk first so partitioning is done at that point so the specification should be adhered to.
I really think the crtical part of the location of the MSR is that it comes before the Primary partition. As long as the partition table knows where each partition on disk is loicated then everything works.
Could you elaborate on this? How was it addressed?
True Image was programmed to make the necessary changes in the partition table that reflect the new locations of partitions written to disk.
Is that one reason why True Image is not restoring partition tables "as it is"?
So, in my case, the position of the MSR changed because I restored to a different disk and True Image recreated the partition table?
Correct.
Okay. But the question about sector-by-sector is still unanswered. Anyone from Acronis or anyone else has any ideas?
If I understand you correctly, your MSR was the first partition before restoration. But what about in your backup image, was the MSR the first partition too?
You understand correctly, the image I restored to the new disk was a clean install of Windows 10 which had a partition layout as you described above.
So the MSR was first partition, your backup had it as third partition, and upon restoration with True Image, the MSR became third partition?
You said new disk, so I assume it's a different disk? I don't get how in your case, True Image recreated the partition table correctly, but when I did my tests, also with the MSR as the third partition in the backup, it restored it as the first partition.
[quote=Stubby Tater]
Could you elaborate on this? How was it addressed?
True Image was programmed to make the necessary changes in the partition table that reflect the new locations of partitions written to disk.
Is that one reason why True Image is not restoring partition tables "as it is"?
Yes.
So, in my case, the position of the MSR changed because I restored to a different disk and True Image recreated the partition table?
Correct.
Okay. But the question about sector-by-sector is still unanswered. Anyone from Acronis or anyone else has any ideas?
I cannot confirm because I have not tested a sector by sector restore of a disk image to a new/different disk but I see no reason why a sector by sector restore would not have the same result.
If I understand you correctly, your MSR was the first partition before restoration. But what about in your backup image, was the MSR the first partition too?
You understand correctly, the image I restored to the new disk was a clean install of Windows 10 which had a partition layout as you described above.
So the MSR was first partition, your backup had it as third partition, and upon restoration with True Image, the MSR became third partition?
You said new disk, so I assume it's a different disk? I don't get how in your case, True Image recreated the partition table correctly, but when I did my tests, also with the MSR as the third partition in the backup, it restored it as the first partition.
No, the image used in the restore was that of a clean Win 10 install which by default had placed the MSR partition as the third partition on disk. After restoring to the new disk the MSR partition was placed first on disk the same as in your case.
Yes the disk restored to was a NEW disk and the restore to that disk ended with the same result as you, MSR in the first position on disk.
Okay. But the question about sector-by-sector is still unanswered. Anyone from Acronis or anyone else has any ideas?
I cannot confirm because I have not tested a sector by sector restore of a disk image to a new/different disk but I see no reason why a sector by sector restore would not have the same result.
Will do, I'm just hoping someone from Acronis can step out and comment about this, or someone else who knows the inner workings of the program.
@Stubby
Try contacting Acronis support directly using the link below. To activate the live chat and email options select Presales/Licensing Questions in the first drop down box and I have a question about Acronis product in the next one.
http://www.acronis.com/en-us/support/contact-us.html
I have wanted to test the following but simply cannot find the time it seems. I would like to take a new disk, convert it to GPT format, then install Windows 10 clean on the disk just to see what the Windows installer would do with the MSR partition. I am curious how serious Microsoft is about its statement that the MSR MUST immediatly preceed the OS partition. It the Windows installer moves the existing partition then I guess there may be some reason that I am not aware of that exists that makes this so.
https://forum.acronis.com/system/files/msrpartition1.png
If the disk is initialized to GPT with the MSR partition first on the disk the Windows installer will prompt a warning that the partitions are not in the recommended order. The default and recommended partition order do not generate this prompt. I use the recommended partition order because it eliminates the creation of multiple recovery tools partitions when new builds are installed.
https://forum.acronis.com/system/files/default.png
https://forum.acronis.com/system/files/recommended.png
What are the negatives of having the MSR moved to the 1st partition and size increased from 16mb to 128mb (other than the meager 100mb or so difference)? I have never noticed any issues on recovered systems, so I've never seen this as an issue, but now I'm curious.
Most of the newer systems seem to be more flexible about the partition order. On one of my systems it creates a very annoying boot issue. This system will not recognize that the disk contains a bootable operating system during a normal startup if the MSR partition is first. The boot menu has to be used to select the disk to boot the OS. As long as the partitions are in the standard UEFI GPT order there are no boot issues. Based on this behavior I think that it stops looking for the EFI partition on the disk after it sees the MSR first(indicating that it is a data disk) and moves on to the next device in the boot priority. Placing this partition in the correct location has been simple and straight forward with the other disk imaging programs I have tested.
You may find the issues I encountered with Try&Decide and Acronis Startup Recovery Manager on Windows 10 GPT systems interesting as well.
@Stubby
Try contacting Acronis support directly using the link below. To activate the live chat and email options select Presales/Licensing Questions in the first drop down box and I have a question about Acronis product in the next one.
http://www.acronis.com/en-us/support/contact-us.html
I have wanted to test the following but simply cannot find the time it seems. I would like to take a new disk, convert it to GPT format, then install Windows 10 clean on the disk just to see what the Windows installer would do with the MSR partition. I am curious how serious Microsoft is about its statement that the MSR MUST immediatly preceed the OS partition. It the Windows installer moves the existing partition then I guess there may be some reason that I am not aware of that exists that makes this so.https://forum.acronis.com/system/files/msrpartition1.png
If the disk is initialized to GPT with the MSR partition first on the disk the Windows installer will prompt a warning that the partitions are not in the recommended order. The default and recommended partition order do not generate this prompt. I use the recommended partition order because it eliminates the creation of multiple recovery tools partitions when new builds are installed.
https://forum.acronis.com/system/files/default.png
https://forum.acronis.com/system/files/recommended.png
What are the negatives of having the MSR moved to the 1st partition and size increased from 16mb to 128mb (other than the meager 100mb or so difference)? I have never noticed any issues on recovered systems, so I've never seen this as an issue, but now I'm curious.Most of the newer systems seem to be more flexible about the partition order. On one of my systems it creates a very annoying boot issue. This system will not recognize that the disk contains a bootable operating system during a normal startup if the MSR partition is first. The boot menu has to be used to select the disk to boot the OS. As long as the partitions are in the standard UEFI GPT order there are no boot issues. Based on this behavior I think that it stops looking for the EFI partition on the disk after it sees the MSR first(indicating that it is a data disk) and moves on to the next device in the boot priority. Placing this partition in the correct location has been simple and straight forward with the other disk imaging programs I have tested.
You may find the issues I encountered with Try&Decide and Acronis Startup Recovery Manager on Windows 10 GPT systems interesting as well.
What are the other disk imaging programs that you have tested?
@Stubby
Try contacting Acronis support directly using the link below. To activate the live chat and email options select Presales/Licensing Questions in the first drop down box and I have a question about Acronis product in the next one.
Okay, tried that, and well...
It looks like the MVPs here know better than them...
Anyone else?
Stubby,
I think for now, we're not 100% sure, but all of my testing shows no issue with the change in location. If you absolutely need/want the original order, the work-a-round is documented step-by-step in Mustang's write-up here. Using WinPE you can first set your paritions in Acronis (or use another tool of your liking a head of time). Then push back each parition to the respective partition location and the order will be maintained. If it's any consolation, I've pushed back hundreds of images letting Acronsi do its thing and we are not having any trouble with system performance and no problems using Windows Recovery either. Perhaps it was problematic in earlier versions of ATIH, but I don't see it now.
Here's Mustang's tutorial on the process:
101550: Guide to Restoring a UEFI/GPT Windows System to a New Disk with True Image 2016
Stubby,
I think for now, we're not 100% sure, but all of my testing shows no issue with the change in location. If you absolutely need/want the original order, the work-a-round is documented step-by-step in Mustang's write-up here. Using WinPE you can first set your paritions in Acronis (or use another tool of your liking a head of time). Then push back each parition to the respective partition location and the order will be maintained. If it's any consolation, I've pushed back hundreds of images letting Acronsi do its thing and we are not having any trouble with system performance and no problems using Windows Recovery either. Perhaps it was problematic in earlier versions of ATIH, but I don't see it now.
Here's Mustang's tutorial on the process:
101550: Guide to Restoring a UEFI/GPT Windows System to a New Disk with True Image 2016
Thanks, I'm already doing that (like I mentioned in my earlier posts), just that I want to cut down on the redudancies.
Call me pushing my luck, I just wanted to see if I can reach a proper response from the Acronis folks.
Anyway, in your case, was it a non-sector-by-sector backup or a sector-by-sector?
Mine are alwasy non-sector-by-sector. I haven't found the need to restore the inactive porition of the disks and am too impatient to allow for the extra time (and space) to have it in my backups.
Since the people at Acronis are so incompetent, I have decided to conduct my own tests.
You're welcome, Acronis. I accept cheques or PayPal.
Backup
- Windows 10 installation installed in UEFI mode on a GPT drive (MSR of 16 MiB as third partition)
- 2 backups were made, one non-sector-by-sector, and one sector-by-sector (and unallocated space)
Restore
- Disks were uninitialised (DiskPart clean) before restoration
- Restoring full disk backup (meaning "Disk X" selected) to:
- Disk of same size
- Non-sector-by-sector: Partition layout preserved (MSR of 16 MiB remains third partition)
- Sector-by-sector: Partition layout preserved (MSR of 16 MiB remains third partition)
- Disk of bigger size
- Non-sector-by-sector: Partition layout not preserved (MSR becomes 128 MiB and first partition)
- Sector-by-sector: Partition layout not preserved (MSR becomes 128 MiB and first partition)
- Disk of smaller size
- Non-sector-by-sector: Partition layout not preserved (MSR becomes 128 MiB and first partition)
- Sector-by-sector: Impossible
- Disk of same size
TL;DR: Restoring to a disk of the same size, whether non-sector-by-sector or sector-by-sector, will preserve the partition layout.
Question, was your restore to same size disk performed back to the same disk from which the backup image was created from?
If yes, did you run diskpart clean or clean all command? If clean was used partition and formatting information would remain on the disk, only data would be removed.
Question, was your restore to same size disk performed back to the same disk from which the backup image was created from?
If yes, did you run diskpart clean or clean all command? If clean was used partition and formatting information would remain on the disk, only data would be removed.
Different disk. May be the same make and model but it's a different disk from the Windows 10 installation.
To my knowledge, it's the other way round. Clean removes the partition and formatting information, but data remains. The disk shows "Uninitialized" in Acronis True Image and DiskPart.
Clean all, on the other hand, removes everything by writing zeroes to the entire disk.
Removes any and all partition or volume formatting from the disk with focus. On master boot record (MBR) disks, only the MBR partitioning information and hidden sector information are overwritten. On GUID partition table (GPT) disks, the GPT partitioning information, including the Protective MBR, is overwritten; there is no hidden sector information.
all
Specifies that each and every sector on the disk is zeroed, which completely deletes all data contained on the disk.
Anyway, I only used "clean" for "Disk of bigger size" test, to change between non-sector-by-sector and sector-by-sector. For "Disk of same size", I made the extra effort of restoring to another disk, both non-sector-by-sector and sector-by-sector.
Since the people at Acronis are so incompetent, I have decided to conduct my own tests.
You're welcome, Acronis. I accept cheques or PayPal.
Backup
- Windows 10 installation installed in UEFI mode on a GPT drive (MSR of 16 MiB as third partition)
- 2 backups were made, one non-sector-by-sector, and one sector-by-sector (and unallocated space)
Restore
- Disks were uninitialised (DiskPart clean) before restoration
- Restoring full disk backup (meaning "Disk X" selected) to:
- Disk of same size
- Non-sector-by-sector: Partition layout preserved (MSR of 16 MiB remains third partition)
- Sector-by-sector: Partition layout preserved (MSR of 16 MiB remains third partition)
- Disk of bigger size
- Non-sector-by-sector: Partition layout not preserved (MSR becomes 128 MiB and first partition)
- Sector-by-sector: Partition layout not preserved (MSR becomes 128 MiB and first partition)
- Disk of smaller size
- Non-sector-by-sector: Partition layout not preserved (MSR becomes 128 MiB and first partition)
- Sector-by-sector: Impossible
TL;DR: Restoring to a disk of the same size, whether non-sector-by-sector or sector-by-sector, will preserve the partition layout.
Well done. Thank you for sharing.
Stubby,
You are correct, my apologies, thinking one thing and typing another.
The only reason I asked about what disk you used was because I performed a similar test as you only I used a prior version and got a different result. Obviously the latest version changes make the difference between the two.
As Pat says thanks for your testing an posting your results.
Stubby,
You are correct, my apologies, thinking one thing and typing another.
The only reason I asked about what disk you used was because I performed a similar test as you only I used a prior version and got a different result. Obviously the latest version changes make the difference between the two.
As Pat says thanks for your testing an posting your results.
I am using version 19.0.5634.
I used a VM in my tests, but it shouldn't make much of a difference since I removed the original disk and added a new one before restoring. The make and model may be the same though, as per mentioned in my earlier post, but it was still a different disk.
In any case, the tests serve as a reference only. They are, by no means, definite, and may change, with future versions or otherwise. Please, anyone else who has the resources and the time, do conduct your own tests and share your results here, if you can.
Thank you to the people and the MVPs who chipped in too.
Enchantech,
Even though this is an old post, it the only one I have seen in the MANY I have reviewed concerning the MSR that brings up a question you posed in post#21. What happens to an existing MSR(in the wrong place) when you do a clean install of Windows 10?
In my senario I had a disk that had been through an Acronis clone and ended up with the familiar 128mb MSR as partition 1. I had booted into Disk Director and deleted all the "visible" partitions, then did a clean install of Windows 10. I had already gone most of the way through the clean install when I realized I should have used Diskpart to delete the MSR... oh, well wonder what will happen?
The installation created the new standard parition layout: 1-Recovery, 2-EFI, 3-MSR, 4-Primary.
But I noticed that in Diskpart the parition offset of the old MSR (partition 1) was 17kb, but the new Recovery (partition 1) had an offset of 1024KB.
SO, Windows removed the old, but didn't reclaim all the space? What's a few bytes.....at least it worked!
CC,
Good to hear the clean install worked for you. The offset to 1024kb may be due the fact that you are possibly using an SSD for the Windows disk? 1024 will give you the correct alignment of the drive for the file system to run on thus will maximize the use of SSD memory cells.
As an aside, Microsoft has updated the partition order for installation of Windows 10 and now recommends that the MSR partition is first on the disk but MUST be before the system partition.
Yes, it is a SSD, but was also a SSD before when Acronis put the old MSR there. Guess Windows is smarter about it than Acronis.
I just did a clean install of WIN10 and the MSR is the 3rd partition.
Where have you seen a change in the recommendation?
CC,
Thanks for pointing out an error on my part. I miss spoke a bit there. On an UEFI/GPT OS system disk the MSR partition should be the 2nd partition on disk and follows the EFI partition. On a GPT data disk the MSR should be the first partition. See the link below.
https://msdn.microsoft.com/windows/hardware/commercialize/manufacture/d…