Acronis True Image 2017 Restore Problem

oliverjia,

I've just checked backup\restore of System GPT SSD Samsung Evo 850 with UEFI Win 10 x64 ver.1607 under Acronis Linux Media 2017 b.5534 on PC with MB Asus Z170-A with active Secure Boot:
1) MEDIA (USB-Flash) booted in UEFI- mode -> backup\restore passed -> System is bootable.
2) MEDIA (USB-Flash) booted in MBR- mode -> backup\restore passed -> System is bootable.

Therefore, guys, we need system report, collected after restore, if You have issues with system bootability.

 

Well, a couple of things:

I am quite certain you have checked the "Restore MBR and Track 0" checkbox, and was performing a whole disk restore, but would you confirm it? Also, if you checked whole disk restore, you don't have to select the location for each partition on your GPT disk?

My OS is the same version of Windows 10, but with a much older mother board and CPU on the desktop I tested. MB: msi p67a-c43, cpu: 2500K. Also, how many partitions were restored during your test? A typical GPT partition should have 4 partitions. But somehow, the MSR wasn't recognized by ATI, but was recognized by IFL, Macrium and Drive Snapshot.

 

1) Yes, I've marked "Whole disk" check box for backup and for restore.
2) My partition layout on SSD is here : https://snag.gy/mjIF4p.jpg
3) About MB on P67 cheapset, we have PC with MB MSI Z77A-G45 and my home PC is on MB MSI P67A-GD53 + Intel SSD. I will try to check the same case.

 

Yes the MSR is also not shown up in Disk Management, same here.
It appears your Windows 10 is a typical GPT/UEFI system install. Yes please do test your home pc with the P67A MB. I've already deleted my old .tib backup files and the current OS is encrypted with BitLocker. Maybe other users could also chime in and share their experience on GPT/UEFI systems.

 

UEFI system
I downloaded the trial Acronis TI and made an Entire Drive image.
Diskpart was used to "clean" the HD0 SSD which contained Win10..
Booted the Linux Acronis UFD and chose the Recover Whole Disks and Partitions option
I saw...

NTFS (Win10) (C: )
MBR and Track 0
Recovery Partition
EFI System Partition

I also saw "Disk Not Initialized" and "Warning! After operation completion, operating systems will not boot from the destination disk in BIOS".

The restore completed and I was surprised to see Win10 boot normally. The "Warning" was incorrect.

 

Thank you Brian. Yes these 4 items/patitions were also what I saw.
In my case, before I attempted the whole disk restore, I did not clean the disk, so the original disk partition structure was still intact before the restore. Maybe that made some difference?

Edit: now that I read your post again, it occurred to me that I might also have seen the warning in red font "Warning! After operation completion, operating systems will not boot from the destination disk in BIOS", but I was clicking next fast, so did not really go back and change any settings. Again in my case, the system indeed would not boot after restore.

 

oliverjia,

I just did a restore to the same SSD without doing a "clean".

The same "Warning" was present. But the "Initialize" message was absent. I was then asked to delete all partitions. The restore continued...

Win10 booted normally.

 

Thanks again Brian for your test. Now that you and Igor both reported a working restore even with the Restore MBR and Track 0 option selected, it may be that my specific motherboard has this problem with Acronis. Hope more Acronis users could share their restore experience here.
But still, we both saw the Warning message, which means Acronis is aware of some system structure about MBR/UEFI GPT. So still, it's better to remove that the Restore MBR option for GPT/UEFI systems.

 

oliverjia,

I'm just about to do a "clean" and restore the image with the MBR choice deselected.

 

It wouldn't let me do it. It requested a partition restore.

Restoring MBR and First Track is essential for a MBR or UEFI entire drive restore. The TeraByte apps do it by default without asking. Back in the CHS geometry days the First Track was LBA 0 to LBA 62. Its meaning has blurred since then and I think the TeraByte apps now include the first 128 sectors. 128 sectors are needed for a Linux restore if Grub is in the First Track. With a GPT disk restore the first 34 sectors are needed.

 

So it appears that Terabyte IFL could correctly identify the original length of the Track 0, while Acronis could not, on my computer. But why wouldn't Acronis just restore the original partition structure, including the exact position of original Track 0, if it were restore to the same computer? Isn't this what a decent disk imager supposed to behave? I cannot imagine developers at Acronis actually think it's a good idea to mess around with the restore of Track 0. Drive Snapshot has such function as "restore disk partition structure" for whole disk restore, which is very convenient and risk-free. Terabyte has always worked on all my computers over ~10 years, so they might have a better understanding of disk image handling.

 

It seems "logical" that a full-disk restore should include the first track, whichever its length is.

But I think this can cause non-bootable restores to a different disk, because the identification of the disk, which I suppose is included somewhere in the first track, corresponds to the old and not to the new disk. Or is the identification changed automatically?

 

Robin,

I think you are referring to a failed HD situation. You replace the failed HD with a new HD and restore the image. Restore MBR and First Track is included in the restore. The OS on the new HD will boot with the same Disk ID and GUIDs that were on the failed HD.

TeraByte has an option to Change Disk ID and GUIDs but this is only needed with Copy/Restore when both HDs are to be left in the computer for the first boot.

 

Hello Igor,

I was wondering have you got a chance to test whole disk backup/restore on your home PC with MSI p67a motherboard?

 

Hi oliverjia.
I can check backup/restore on my home PC with MSI p67a on near weekend. I will try to do it.

But I checked that case today on work test PC with MB MSI Z77A-G45.
Unfortunatly, our MB has buggy BIOS-UEFI, but I activated Secure boot and booted Media 5534 in UEFI-mode with tambourines and dances
Finally, I created Whole DIsk Backup of System SSD Crucial MX100 with 10 x64 UEFI.
Then I cleaned up SSD and restored from created backup, selecting check box Whole DIsk.
After that System was not bootable and no any boot entry was in boot options.
Then I restored BIOS settings to default state, acivated Secure boot again and system became bootable.
But as I said, our MB is too buggy.

 

Thank you Igor for your update on the MSI Z77A. Both my desktop computers are MSI MB, one is p67a-c43, the other at home is Z77A-GD55. So it appears ATI built 5534 probably does have a restore issue with the MSI MB. Yes it's true some UEFI firmware could be buggy for the earlier generations of UEFI MBs, but Terabyte IFL has no problem restoring the OS disk image that boots without any problem on the same hardware setups.
Also, it sounds like your OS on this Z77A-G45 was installed with secure boot turned off. For all my OS secure boot was on when the OS was installed. But either way, it appears there is some room for Acronis to improve in terms of dealing with situations like this (MB with buggy UEFI), since MSI is one of the major MB vendors. And still, GUI wise, talking about "Restore MBR and Track 0" is confusing for many users.
May I ask the developers one more question? Why not just faithfully clone the disk partition structure (including Track 0) and restore original everything to the same/new HDD, if the whole disk image is to be restored to the same computer? I mean, like an mirror image. Playing with Track 0 could be very dangerous and lead to un-bootable OS after restore. IMHO, a disk imaging software should only work on the hard drive/SSD level without changing/modifying the BCD store or UEFI firmware.

 

Igor,

In the restore process I saw...

NTFS (Win10) (C: )
MBR and Track 0
Recovery Partition
EFI System Partition

This suggests "MBR and Track 0" is a partition. But it isn't a partition.

Of the 3 partitions in this list, they aren't in the same order as the partitions on HD0. I subsequently found the partitions were restored in the correct order to HD0 but the above list should be representative of what is actually on the drive.

 

Agreed with Brian.

The other thing about the regular GPT partitions is that in Acronis the Microsoft Reserved Partition, MSR is not visible during backup/restore. Although this partition can be re-created afterwards, it's best practice to keep the original disk partition structure including faithfully backup the partition layout of the original OS disk, including Recovery, EFI, MSR and C: partitions. Also include MSR in the backup/restore wizard, so that people know all 4 essential partitions of the GPT/UEFI OS install are backed up.

 

@ifilin

I was wondering have you got a chance to test the msi p67a board that you have?

 

Hello oliverjia.

Yesterday I've checked backup\restore of UEFI-GPT Win 10 x64 v.1607 (SSD Intel) on my home PC (MB MSI P67A-GD53).
Backup\restore works fine under Media 2017 b.5534.
Unfortunately, there is no Secure Boot item in UEFI-BIOS (I updated to the last available BIOS).

 

About MSR, I don't see it in Manage Disk console, but Diskpart sees it - https://snag.gy/rwQbyt.jpg .
I've sent already that info about MSR to our developers.

 

Agreed, Brian K.
Track 0 (MBR) should be shown on 1st place and Partitions should be shown in correct order. I will submit this gui issue in our bug tracker.

 

Thank you Igor for the update. Anyway, if you guys at Acronis QC department could find more computers with MSI UEFI board with secure boot option on, and test ATI 2017, I am pretty sure you'll find something related to boot problem after restore.