Dale,

Please provide more details of how you attempted to perform the restore from the cloud?  
Was this tried when booted in Windows 10 or by using the Acronis bootable Rescue Media?

Was this any different when you did the successful restore from USB?

Your screenshot indicates that a System Report is being generated.  That is not something that occurs when a backup fails to start, complete, etc.  Generating a System Report has to be initiated by the user.  Are you certain you made the right selection when using the Recovery Media during your restore attempt? 

The screenshot was taken when attempting recovery using the Rescue Media?  You are certain that each failure produced the same screen/result?

Thanks for replying. Failed restore using Acronis in Win10. The restore completed, then rebooted, Windows bsod tried to fix itself, failed.

I opened a support request with Acronis after posting this. I've uploaded some logs and photos.

Be advised that restore of a Windows System (OS) disk from within the Windows Treu Imge application requires that the machine reboot into a Linux based recovery environment (the same environment as the Rescue Media) to complete the recovery.  Often times after the restore completes the PC is not able to close out (end) this Linux session and reboot back into the Windows environment successfully.  Therefore it is recommended that such recoveries be preformed with the machine booted to the rescue media to begin with so as to avoid this issue.

I ran cloud restore from both Windows and then from rescue disc. Both resulted in Windows bsod.

Restore from backup on local USB disk booting to rescue disk succeeded.

Since I can restore with one and crash with the other, I can reproduce and give them all the info they want so they can find it and fix it.

There is really nothing to fix here.  The issue is machine specific.  To be more specific it comes down to the bios level of the motherboard.  On some machines the process works without issue on some like yours however, the process fails.  So the best "fix" as it were is to recommend that users perform OS system disk recovery with their machines booted to the recovery media.

Rescue media restore of local USB backup works. Rescue media restore from cloud fails.

That, detective, is the right question.

If you have a backup of a your Windows system on the Cloud storage you should not attempt to restore it directly from the Cloud.  Such a backup file should be downloaded from the Cloud to local storage medium and recovered from that medium. 

The pure nature of using the internet to transfer files leaves much to be desired in the aspect of error free performance.  Dropped packets, intermittent connections, and other factors make the proposition of recovering a system disk questionable at best.  I understand that no where in the documentation is that pointed out but that in itself does not make it not so.

At the current time there are a limited number of Cloud hosting servers on the Acronis Cloud network.  This means that depending on a user physical location will impact the quality of service one gets.  There are simply to many variables to rely on a restore from the Cloud for this user.  I would only attempt such with data that is non-critical.  To each his own however, if you are comfortable with it then by all means go for it!

Acronis has been doing cloud backup and restore for a number of years. I've been doing internet backups for enterprises longer than that. You're 10 years behind the curve, dude.

Yeah, like I said, to each his own, dude!

Dale,

As a user forum, if I was looking for assistance, I wouldn't be inclined to aggitate those offering help.  Even us MVP's are not employees and have no obligation to assist, but often offer our personal time to try and help others.  When you post a request for assistance and respond negatively to those offering assistance, well, you're just not going to get a lot of response - it's human nature. That said, if you have a Cloud subscription, which includes technical support, you should be working with them first and foremost anyway.  You're paying for the technical support with the subscription so you should use it to your advantage. 

18623: How to get Technical Support: Tips, Tricks and Useful Information  

5.    Recovery issue
- Related to recovery issues with the full version of the product
- Free of charge
- 24x7
- Not limited (Assistance with the recovery issue can be requested any time, even if you’re out of 30 days free support and don’t have PPI)
- Provided with e-mail and chat
Response time:
-  3 business days via e-mail
 - immediate via chat

 You can find the comparison table here

Notes and tips:

•    Forum is not a primary support channel
It’s designed mainly for sharing experience, collecting feedback and joint Community efforts for addressing technical issues
See Acronis Forum Terms of Use.
We’re still doing our best to address as many problems reported as possible. 
We still recommend contacting support directly in case of emergency.

•    How to contact support:
Please find the step-by-step screenshot instructions in this KB article.

I'm working with Acronis support. As usual, a question to the community is customary to be sure something simple or stupid hasn't been overlooked. Your collegue gave advise, then admitted no experience and indeed stated his aversion to cloud storage at length.

Dale,

Just for the record, my comments in no way allude to an aversion to cloud storage nor a lack of experience.  It must be understood that your  statements regarding cloud storage and recovery are experiences that one would expect from an ENTERPRISE GRADE product.  True Image is not a product of that class.  It is Consumer Grade only pure and simple and as such lacks the robustness of an enterprise product meaning as I stated Limited number of servers in limited areas for the consumer.  Bottom line, compare apples to apples not apples to oranges.

I am also having difficulties restoring from cloud.  To date, I've tried 3 times before.  2 of them involved MSFT Surface Pros.  Never got it work off the WiFi - I guess there are no WiFi capabilities in the Acronis.  No problem, switched to USB3 LAN dongle.  Can connect to Acronis cloud, but with great difficulty.  I've just tried from a Dell desktop (purchased new, earlier this year).  I was able to recover C: partition using v6569 on a USB HDD.  It all looked good until it booted up.  Worthless!!!  The PC ran like crap.  Tried repairing the Windows 10 installation to no avail.

Just tried doing the cloud restore again believing a v6571 burned to CD would make a difference.  Who was I kidding?  Would detect the ethernet NIC, but would not get an IP address from DHCP.  Ok, so let me use a static IP.  No, because now begins the trade-offs.  If you manually input IP info, you cannot enter your username and password, but it gives you a nice jolted error beep every time you try.  Ok, so I used my trusty USB3 LAN dongle (also from Dell), now I can get IP via DHCP.  Last tiem I tried to restore this PC from cloud, I only restored the C: partition.  I recall a 3rd party app where you had to restore the entire disk in order for the restore to work.

Now I'm restoring the entire HDD.  Let's see if that works.  I can't believe I wasted 3 days on this!  Why offer cloud backups with abilities to restore from cloud that don't work?  You tell me I need to download the partitions and piece together the restore process?  Are you ******* for real?  Please tell me it's all just a joke on everybody and that there is a secret to easy restore from cloud (not easy restore from top quality media that you have on hand)?!?

Michael,

So it sounds like the restore actually did work as after the recovery, the PC actually booted.  What was the cause of it running like crap?  Had the restore not completed, it would have never booted.

The recommednation to download the image files first is a good practice.  A constant connection to the Internet for a large recovery can result in a bad download, just with any file downloaded from the Internet.  By downloading first and then restoring, you limit some of the possible issues with download and restore at the same time.  Also, the recovery enviornment is pretty limited as an OS so there isn't much you can do to troubleshoot from within it.

There are no home-user backup solutions, that I'm aware of that support wifi natively.  All other backup products I have tested use WinPE, which does not have wireless support either - it's not part of WinPE (natively, there are ways though, but that's beyond the scope of these applications).

YOu can use the Cloud however you feel best.  Persoanlly though, I would recommend you use it as a secondary offsite location and not rely on it as a primary means for backup.  It's slower, depends on your Internet Service and depends on Acronis servers being up.  A 1TB exernal drive is roughly $50 these days and will result in much faster backup and recovery.  Should you have no other choice (drive fails, disaster, theft) then you have the Cloud as offsite backup to fall back on.

I know why you purchased the cloud subscription and apparently how you want to use it, but can only offer a suggestion to how to improve your experience.  I've tried other backup cloud programs like CrashPlan as well, and the Cloud restore times were not any better and never was able to get a full system image to restore from it, whereas you did with Acronis, but have no idea why it would run like crap if you restored an image of the data that originally lived you your system.  

OP here. For my testing of cloud restore, it only worked after I deleted the original cloud back and created a new one, but I don't know what was wrong with the original bsckup. Then, I found that wiping the disk (in my case booting to Acronis Disk Directory 12, deleting and re-initializing the disk) was needed to prep for the restore in which I booted to Acronis TIH 2016 CD, logged onto the clound, and restoree the disk.

On this test system, it's Windows 10 on a Samsung EVO 840 SSD, 256GB, divided into C: for OS and F: for data. My backup was only of C: and the boot partitions. I had to delete F: also during the disk clean-up prior to a successful restore from the cloud.

I'll continue with my local USB disk backups and continue with testing the TIH cloud backups and restores until I'm either satisfied with the cloud, or wait for another year to try cloud again.

PS, I'm doing the same conservative approach for my F: data files backups: I've have local USB backups (Syncbackfree) on multiple disks. This is my base backup. I'm now trying TIH cloud backup of F: data drive, and periodically testing it by picking a few files to restore.

I think my pragmatic goal is continuing with local USB disk backups, and augment them (ie, optional) with could backups. Until cloud proves robust and reliable, I'm fine with local USB as my primary backups.

Sure, it restored...on a technicality.  Yes files are there, but it left the OS and apps corrupted.

This PC happens to belong to the COO.  At first I used a 1TB drive for backups.  But, the boss wanted daily backups & he has a lot of files - 1TB wasn't going to cut it.  So I mentioned using the cloud.  Now I have egg on my face & my director chewing me out to get the COO's desktop fixed!

I'm going to try 2 things: first, I'm downloading the C partition; 2nd, while downloading, I'm going to try deleting the partition and try another restore from the cloud.  If I manage to get his PC back to a good state, I'm going double up and set a weekly local backup.

I'm also testing with version 6571 on a brand new Dell Laptop running Windows 10 - Version 1607.  This system is UEFI booting a GPT disk with a total of 4 partitions containing some 49GB of data and the EFI system partition.

The initial backup took a very long time (more than 12 hours - even with upload speed not limited), but that is a natural limitation of my internet connections upload speed.  Subsequent backups completed in very reasonable times (minutes depending on the amount of locally changed info).

So far so good.

I did a backup to local storage USB attached storage and then wiped the disk and restored from local.  The restore went fine and the system booted cleanly.  My user isn't going to have local attached storage (or they'll never manage to have it connected), so the cloud backup is really what matters.

I wipe the disk again and restore from the cloud.  The process took some 3+ hours, but it completed successfully.  However, the system won't boot!  Acronis Chat support suggested many things, none of which produced useful results.  They suggest that I wipe the disk again and attempt the cloud restore again.  They don't explain why this would be expected to produce different results, but they insist that this is necessary.  I once again wipe the disk and do the cloud restore again and it again says "Restor completed Successfully", and once again the system will not boot.

I tried downloading the "Entire PC Backup" which came down as a ZIP file that contained each of the data partition's files as separate directories.  This would be fine for file recovery, but it certainly isn't useful to rebuild a system with a failed disk.

Note:  All of the above was done with a WinPE based Acronis Recovery Media.  I'm now trying AGAIN with a Linux based recovery media, and after 3.5 hours this one fails just like the WinPE case.

It feels like I'm doing Acronis' basic QA here since I have a very vanilla system which they certainly should have tested.  I guess I'm ahead of the curve by actually confirming the details of how a restore will work BEFORE a crisis occurs and I'm under the gun to get a system working.  The documentation seems to clearly cover the recovery scenarios for a MBR structured disk, but the GPT and UEFI are clearly more tricky and it seems, untested.

If I was restoring to different hardware I would expect some headaches and probably a number of hoops to be jumping through, but what I'm trying here should work out of the box.

Hi Mark,

I haven't personally had to restore a full disk image from the cloud - time consuming to do as a test on a personal computer and have not been in that situation yet, so am not familiar with the process myself.  I will try to get around to this in the near future to see if I can offer some additional user assistance though as I am curious too.

A couple of questions that might help identify the non-boot issue...

1) when you launch the acronis recovery media, are you booting it in UEFI mode or legacy mode?  How you boot the recovery enviornment determines how the disk parition scheme will be created as a result.  For instance, if you have an OS that is installed in UEFI/GPT mode, but boot the recovery media in legacy mode, the resulting disk type will be MBR/legacy instead of UEFI/GPT and the OS won't boot.  You can never go from UEFI/GPT to legacy/MBR.  Sometimes it works converting from MBR/Legacy to UEFI, but ideally, you want them to be the same to rule out other issues.

Here's a thread with more details and pictures to show the boot methods and screens

2) What happens if you run a Windows installer disk or drive and attempt to repair the bootloader?  If the image was restored in the correct manner, but the bootloader is somehow corrupted in the process, this should make it bootable again.  However, if the image is restored in the wrong manner (booting to the wrong type with the recovery media), then that could be the break-point.

3) If you grab the free version of mintool parition wizard and boot to it, it will show you the paritition layout of the recovered disk.  You could take a cell phone pic and post it for reference.  It might at least show if the disk layout is correct.  This web page shows an example between what a legacy OS install and a UEFI OS look like in disk management. Your restored image should look similar to one.  

http://www.partitionwizard.com/download-free-from-cnet.html?r=partition…

http://www.partitionwizard.com/download-free-from-cnet.html?r=partition…

Hello Mark,

Like Bobbo I have no personal experience with performing a Cloud recovery of a system backup to a PC.  I have not tried it for much of the same reasons as Bobbo and quite frankly, I just do not see how such a recovery could ever work reliably.  I have seen posts here that claim it does and those like yours that are failures.  I will follow this thread because I am curious too!  Best of luck to you in getting it working. 

I bit the bullet and gave it a shot.  First, I did a full offline image to a local USB drive (just in case)... glad I did.  I then ran a cloud backup to get things up to date - took about 15 minutes.

After that, I booted into my 2016 v6571 Linux media and started recovery, cloud and a full disk scenario with the date showing the backup that I had just taken.  Restore was fairly slow... my local backup took about 8 minutes to complete (and usually takes about 10 minutes to restore).  I let it run for about 1 1/2 hours and it was only about 1/4 done when I turned in for the night.  Restore was complete when I woke up, but system failed to boot - Windows 10 BSOD.  

I booted up my WinPE and ran diskpart - all paritions are there in the order as expected.  I double checked with Partition wizard mini free as well.  I tried the default repair with no luck.  I then tried a repair using my newly created Win10 installer USB - no luck either.  I then booted back into the WinPE RE and did the full BCD edit/repair, even going as far as mounting the EFI parition and copying the bootloader from the recovery disk to the OS, but still no joy - couldn't get it repaired, couldn't get it to boot.  I even tried the down and dirty way using the "repair windows boot" options in a couple competing products, but nothing worked.  

Pretty bummed - I would have thought a repair install would have fixed things since all of the paritions and data appeared to be in tact.  In the end, I gave up and restored my locally created imag without any issues and in only about 10 minutes.  I have taken a system report and will submit feedback along with this post to see if it helps identify the issue.  I don't have any issues restoring files/folders from the Cloud, not sure I'd rely on it for a full disk/OS reocvery unless I absolutely had to.  If it wasnt' so time consuming, I'd like to test more, but since I rely on much speedier local backups (and take several different versions of them), cloud is primarily my offsite and last option for recovery too.  

If/when I get some response back on the system report, I'll post back. 

Hi Bobbo,

Thanks for your comments.  

I understand the UEFI boot process and have indeed booted the Acronis Recovery Media (both WinPE and Linux) in UEFI mode when I perfomed each operation.

As I said, restoring from a local (USB attached) Acronis backup produced a working disk which booted correctly.  Booting from the same media, the same way, and restoring from the Acronis Cloud completed "successfully" as resported by the Acronis App, but the resulting disk isn't bootable.

I have a tool which is runnable in a WinPE environmant and can copy a disk image to a VHD.  It also can display the precise details of the partiton structure on a disk.

There are 3 cases here:

1) The original disk

2) The disk after using Acronis Restore from a Local USB connected backup.

3) The disk after using Acronis Restore from the Acronis Cloud.

The partition structure of EACH of of these are identical including the offsets, sizes and partition types (partition GUIDs which should be different in each of the 3 cases are indeed different).  

Since case 1 and 2 are bootable where they are the same but different for case 3 are probably related to the problem.

The EFI System Partition for each of these 3 cases contains a FAT32 file system.

Case 1 & 2 (working) have FAT structure that contains:

OEMId:                      MSDOS5.0
BytesPerSector:             0200 (512)
SectorsPerCluster:          08 (4K)
CopiesOfFAT:                02
MediaType:                  F8 (Fixed)
SectorsPerTrack:            003F
Heads:                      00FF
HiddenSectors:              00000800
ReservedSectors:            183E
RootDirEntries:             0000
RootDirSectors:             00000000
RootStartCluster:           00000002
PartitionSize:              000FA000 (512000K)
ClusterCount:               0001F000 (126976)
FirstDataSector:            00002000
TotalDataSectors:           000F8000
FATSize:                    000003E1
VolumeName:                 NO NAME    
FATName:                    FAT32   
VolumeSerialNumber:         D04ADB2E
Signature:                  AA55

Case 3 (failing) has:

OEMId:                      MSDOS5.0
BytesPerSector:             0200 (512)
SectorsPerCluster:          08 (4K)
CopiesOfFAT:                02
MediaType:                  F8 (Fixed)
SectorsPerTrack:            003F
Heads:                      00FF
HiddenSectors:              00000800
ReservedSectors:            0022
RootDirEntries:             0000
RootDirSectors:             00000000
RootStartCluster:           00000002
FirstDataSector:            000007F0
TotalDataSectors:           000F9810
FATSize:                    000003E7
VolumeName:                 ESP        
FATName:                    FAT32   
VolumeSerialNumber:         33081FBC
Signature:                  AA55

Differences:

Case 1 & 2 which boot successfully:
ReservedSectors:            183E
ClusterCount:               0001F000 (126976)
FirstDataSector:            00002000
TotalDataSectors:           000F8000
FATSize:                    000003E1
VolumeName:                 NO NAME    
VolumeSerialNumber:         D04ADB2E

Case 3 which fail to boot:
ReservedSectors:            0022
ClusterCount:               0001F302 (127746)
FirstDataSector:            000007F0
TotalDataSectors:           000F9810
FATSize:                    000003E7
VolumeName:                 ESP        
VolumeSerialNumber:         33081FBC
 

It seems pretty clear that the restore for a local Acronis Backup restores details that existed in the original disk, while the restore from the Adronis Cloud doesn't.  This is most likely not the only relevant difference, but it seems to at least be part of the problem.

You seem to be on to something.  If/when you try a cloud restore again, you can save the log file to the USB drive (I missed the opportunity as I had enabled the check box to restart the computer automatically when complete).  Assuming it doesn't boot, which is the likely outcome again, I then took a system report with the offline bootable recovery media and that's what I submitted to Acronis to review.  

When I get the time, I may try to download the image first in Windows and then restore locally.  Seems like it should be possible, but I have to figure out how since I haven't tried yet, so am not sure.  I'd like to give it a shot though, if the full .zip download includes a useable .tib file. 

Well, there seems to be something strange about the new Dell Laptop that I'm working with.

I say this due to the fact that last night and today I tried two separate experiments:

1) I installed Win 10 Home Version 1511 on a VirtualBox VM with EFI enabled.  I backed this system up to the Acronis Cloud.  I turned the system off and replaced the original disk image with a newly created disk image.  I booted the Acronis Recovery ISO media (Linux based) on this system and from the UEFI boot menu I ran the Acronis application.  I selected the just backed up version this system's disk to be restored to the empty disk.  After the restore the system booted!!!

2) I installed Win 10 Home Version 1607 on a Hyper-V Generation 2 VM (EFI enabled capable).  I backed this system up to the Acronis Cloud.  I turned the system off and replaced the original disk image with a newly created disk image.  I booted the Acronis Recovery ISO media (Linux based) on this system and from the UEFI boot menu I ran the Acronis application.  I selected the just backed up version this system's disk to be restored to the empty disk.  After the restore the system booted!!!

So, the failure I'm consistently seeing on the only system I really care to have backed up may be related to how ever Dell is structuring the EFI partition....

I've just received another Dell Laptop which I'll perform the same steps on again and see what happens.

As for saving the Log File.  It seems that there is no choice to actually save the LogFile itself when booting from Linux based Acronis recovery media.  I did have that choice when I ran a restore from a WinPE based media.

In the above Virtual Machine cases, I was able to capture screen shots of the log file text displayed in the Acronis application.  This info wasn't so useful to describe the details of a failure since neither of these cases actually failed.  As I recall, the info displayed in the logs was essentially the same as the info displayed in the case on the original Dell laptop which didn't boot after the restore.

Interesting indeed.  I can test with some VM's too.  My test system was an ASUS Transformer T200 and I'm wondering if the eMMC flash hard drive or locked down bios has anything to do with it.  I have secure boot disabled, but this system can be pretty picky with even getting USB flash drives to detect for boot.  Normally, I don't mind testing restores and backups since they happen so quickly from local backups.  I'm just impatient for the cloud ones, but using VM's wouldnt' be so bad with a barebones Windows install. 

Do you have secure boot enabled on the Dell?  If so, I'd turn it off during the image and restore - probably not the problem, but at least we can rule it out.

Secure Boot has been disabled on the Dell.

I had to disable Secure Boot on the Hyper-V VM in order to even get the Acronis ISO Recovery Media to boot.

Will be interesting to see your outcome on the new Dell laptop.  Interesting idea about the EFI on the stock Dell machine, may I ask if when you performed the cloud backup on the original system disk, not the VM, did you inclide the Dell Recovery partition in that backup?  The default backup I believe would be to NOT include that partition in the backup.  Possibly without that partition restored to the disk the boot fails because that partition cannot be found?  The partition, missinng from the bakcup, has changed the partition order causing boot failure?  I would not think this possible as the restore to disk should make adjustment for this I believe but who knows!

No Dell recovery partition was created on any of the systems I've tested this process on (Dell, VirtualBox, Hyper-V).

I meant no Acronis Recovery partition.

All backups were Complete PC backups (of the entire disk).

Reading once again.  You really meant the Dell Recovery partition.  That clearly wasn't on either of the VM backups, but the whole disk was backed up for each of these cases, and the restore included the Dell Recovery partition.  There may have been details in the EFI partition which referenced the Dell Recovery Partition.

I've built up 2 base Win 10 x64 VM's - one bios and one EFI.  Nothing installed but Acronis 2017 beta 2 (3070)  Backing up the bios test to the cloud now - 14.5Gb estimates 6.5 hours.  I'll backup the EFI after that and then get around to some restore testing - probably not until Friday (maybe Saturday).  

I already took local images and plan to do some additional testing with ASRM with these as well as I'm trying to repeat if there is still an issue with the recovery partition mounting as a volume after starting ASRM and doing a full recovery.  

I don't think the Dell recovery is the issue.  I just have the standard recovery partitoin on my ASUS T200 that is created with Windows 10.  Regardless, the local restores are working in all cases, it's just the cloud restore of the same full disk images that is not bootable at the moment.  If both of my VM's are successful like Mark's, I might try the ASUS again (I was using 2016 6571 linux media but will try with the 2017 3070 media instead).  

When logged into the webrowser and the cloud, I can download what appears to only be the C:drive so doesn't look like one could grab a full .tib backup to download first and then attempt to restore locally.  If there is a way, and someone knows how, let me know.  These seem to suggest it can only be done via the recovery media and on the fly. 

Recovering data from online backups

Disk recovery from Cloud

Recovering your system from Acronis Cloud

OK, here are my results with the 2 new Acronis cloud full disk restores.

-----------------------------------------------------------------------------------------------------------------------------

TEST 1:  VM (built on VMWARE workstation 12 current version).  EFI install of Windows 10 x64 anniversary edition - clean install.

Installed Acronis 2017 beta 2 (3070) in trial mode.  Logged into my Acronis Account and took a full disk cloud backup to my Acronis account last night.  This morning, I booted into Windows, ran some Windows updates to make some changes to the system, rebooted, logged in and then shutdown.  I then booted into the Acronis 2017 beta 2 (3070) Linux recovery media (licensed version from the one created with my logged in account as part of the beta testing).  I connected to the Cloud and did a restore - the disk was not wiped so the restore did not take too long - couple of hours I think, didn't time it as I was doing other things while this was going on.  Successful Restore operation reported.  Boot to the OS and get a BSOD as I did with my iniital physical laptop test - RESULT = FAIL.  

Booted into my Windows installer USB drive >>> system repair >>> and attempted a system repair, which reports that system repair was not successful. Windows System Repair = FAIL.

Reboot and test OS load (just to be sure), same BSOD.  Boot back into my Windows installer USB drive >>> system repair >>> advanced options >>> cmd prompt.  

Run the following commands:

• bootrec /RebuildBcd
• bootrec /fixMbr
• bootrec /fixboot      
• total indentified Windows installations: 1 
• the operation completed successfuly
• Exit

Boot back into Windows.  This time success.  Log into Windows and poke around a bit - all seems to be well.

RESULT = PASS 

TEST 2:  VM (built on VMWARE workstation 12 current version).  Legacy/MBR install of Windows 10 x64 anniversary edition - clean install.

Installed Acronis 2017 beta 2 (3070) in trial mode.  Logged into my Acronis Account and took a full disk cloud backup to my Acronis account last night.  This morning, I booted into Windows, ran some Windows updates to make some changes to the system, rebooted, logged in and then shutdown.  I then booted into the Acronis 2017 beta 2 (3070) WinPE recovery media (licensed version from the one created with my logged in account as part of the beta testing).  I connected to the Cloud and did a restore - the disk was not wiped so the restore did not take too long - couple of hours I think, didn't time it as I was doing other things while this was going on.  Successful Restore operation reported.  Boot to the OS and get a BSOD

RESULT = FAIL.  

Booted into my Windows installer USB drive >>> system repair >>> and attempted a system repair, which reports that system repair was not successful. 

Windows System Repair = FAIL.

Reboot and test OS load (just to be sure), same BSOD.  Boot back into my Windows installer USB drive >>> system repair >>> advanced options >>> cmd prompt.  

Run the following commands:

• bootrec /RebuildBcd
• bootrec /fixMbr
• bootrec /fixboot      
• total indentified Windows installations: 0 
• the operation completed successfuly
• Exit

Boot back into Windows.  Still BSOD (as expected by total identified Windows Installations: 0 above)

RESULT = FAIL.

Scower the Internet for solution - been here many times before.  Found something new and less whacky than I've tried in the past.  

https://www.cult-of-tech.net/2015/07/rebuilding-the-windows-system-reserved-partition/

In a nutshell, it has you use diskpart to format the System Reserve Partition, then use your Windows installer to do a system repair.  I had to run system repair twice (it mentions that some people have to do it 3 times).  

Boot into Windows - success!

RESULT = PASS

Clearly, with both tests, the bootloader is not being properly restored from a full Cloud backup.  Why this is successful for some and not others, I have no idea.  If Windows System Repair can fix this on its own, then it's not so terrible.  If it can't repair on it's own, using the 3 BCDEDIT commands isn't too bad either.  If that doesnt' work and you have to format the system parition first, then do the system repair, that's a bit more advanced and might be scary for some.  If you follow the directions to the letter it's not difficult, but if you format the wrong partition, then, you're going to have problems.  This is by far the best bootrepair page I've found when no detected OS are identified with BOOTREC /fixboot.  It will stay in my favorites for now on

**EDIT - sorry, dont' know what I was thinking - almost deleted this post as a duplicate so have added it back!**

Bobbo_3C0X1 Ten Thousand Upvotes to your thorough tests, recovery and reporting!

Good work Bobbo.

Glad you added the documentation links to the post.  The Disk recovery from Cloud link eludes to the fact that such recovery has possibility for failure. 

We know that the Cloud works on a Delta basis with backups and the documentation leads one to believe that recovery works in much the same way.  I take note that the documentation says it will only restore changed data on disk when the target disk is the same disk as the source backup was generated from.  In your examples above this is I think what you performed.  So the only changes on disk then should have been the Windows updates you applied.  Do you have any idea how large those updates you applied were?  You say that the restore took a couple of hours, what was the process doing for that long?  If the only thing restored to your disk were the changes made to that disk from the updates you applied, why would the Reserve Partiton become corrupted as a result?

Another question, how long did it take for Windows to download and apply the Windows update changes to your VM install?  I bet it wasn't a couple of hours!  So why then would Acronis Cloud recovery take so long to essentially do the same thing?  Have you checked the Windows Updates that you applied for details on what they were for?  If any were Security updates I suppose the possibility of there being some change in the Reserve partition is possible but doesn't seem likely to me.

When you selected the disk for recovery from the Cloud, did you also select the Reserve partition or only the C: partition?  If by chance the Windows updates applied modified the reserve partition in some way and you did select it for recovery then it makes sense that BSOD could result I suppose, even though the process is only suppose to restore changes on disk I wonder if that applies to all partitions?  If you had not or maybe you did not select the reserve partition for recovery I'm not sure but, I wonder if only the C; partition were selected for recovery if your results would have been different?

These are the questions that make me think that System disk backup and recovery via the Cloud is a nice idea but prone to failure thus has no or little reliability.  It would be much more reliable if a Cloud backup created a tib file of the entire disk and that tib file were then downloaded to a temp folder for restore purposes.  Yes this increases download totals which would effect users with limited data plans but in order to be reliable I think it is a must. 

Hi Enchantech,

You're right, the changes are only supposed to be Delta.  I don't remember teh exact size of the Windows updates, but it wasn't much - couldn't have been more than a couple hundred Mb and only took a few minutes to download, install and reboot.

My guess is that it takes some time for Acronis Cloud to scan the existing system contents to search for the changed data and is probably where the bulk of the restore time was spent on, but it doesn't really tell you what it's doing along the way (it does show the contents that are being written when that starts to kick in, but it's just the name of a file that passes quickly).

With only Delta's being changed, I can't imagine why there would be any variation in the system parition as that should be remaining constant - at least in these tests where there shouldn't have been any.

When I configured the backup, it is a full disk backup with all paritions selected - same as I do for local backups. When I do the restore, I select the entire disk with all paritions again as well (also the same that I do for local backups).  Ideally, this is the scenario I wanted to test, because if you have a drive failure and want to recover the entire disk and make it bootable, that would be the process there as well. 

Even if the recovery failed because of an Internet connection problem, because it is supposed to scan for Delta's it is supposed to pick up where it left off and just make the necessary changes. In my case though, I didn't notice any connectivity problems and all recoveries reported "success" when complete as well. 

Personally, I wouldn't use the Cloud as an initial or only backup location anyway.  When I can backup an entire machine locally in 8 minutes and recover that same image in another 8 minutes, but it takes nearly 12 hours to back up to the Cloud and a few hours to recover with only minor changes, I much prefer the speed of local backups.  The Cloud backup appeals to me for the offsite redundancy and seems to work well for data recovery, but I'd be less inclined to rely on it for a full system recovery after theses tests. Ultimately, it was repairable, but not the easy, automated solution that it should be (at least not for me).  

One Cloud backup feature that might solve this type of issue, is if we could set the "make a reserve copy" to the Cloud.  That way, we could download the backup.tib in one shot and restore it locally. 

Bobbo,

I am pretty sure I understand your test method and resoning behind it.  I am wondering however if when you chose to restore the backup had you only selected the C: partition if the result would have different?  Would it be possible for you to run the retore again but this time only restore the C: partition? 

I get your reasoning in doing full disk, this is the long standing way to bring back to life a corrupted disk.  It is the way I have always done it too.  If a disk fails to boot then it would definately be necessary to bring along the Reserve partition with the recovery but, if the disk will boot but Windows will not run then only C; drive recovery could fix the problem. 

True Image has always had the ability to restore individual partitions.  It is up to the user to determine which partitions require a restore when a failure occurs.  When unsure the entire disk is the best solution.  Most users will just do that and that is fine, it works, and so it should from a cloud backup.  My thought here is simply to try to narrow it down to a degree.  Is it simply that a Cloud recovery has issue with restoring the Reserve Partition?  Were there factors that contributed to the Reserve partition corruption beyond the restore process?  Since in your scenario you likely only made changes to C: partition if that partition were the only one restored would the boot problem still be there? 

Just curious why you got the results you did?  If a restore of C: only proved successful how about a restore of the Reserve partition only?  If no change was made to the Reserve partition and you restore it ideally the restore would change nothing and the disk should boot. 

I will test each one until it fails - starting with C: drive restore only, then system partition only, then recovery parition only, then all paritions again (if it works for each one individually). It's a VM so it's nice that I can keep the main PC running while it's going.  

This time, I won't select the option to reboot when complete either so I can try to see how long it actually takes to restore. 

First test didn't go too well, but I'm going to repeat again - just in case - this may have been a VM issue.  

I started the recovery from within Windows.  I restore C from the cloud, only took about 6 minutes - reported success.  Much faster than before with all paritions selected.   However, upon reoboot, I see the Windows spinning ring then it disappears and goes black - nothing.  Rebooted a few times and it stayed that way.

I then restored C from a local backup and it boots fine now.  

I ran Windows update to make some changes, ran a local backup again and am running a cloud backup now.

I will repeat again by starting from Windows and see how it goes.  If the problem remains, I will resore from the local backup and then attempt the cloud restore of C from the Linux bootable media instead and compare. 

2nd test of C: drive completed fine - this one only took about 4 minutes.  3rd test starting from within Acronis again, just to be sure :) 

I will keep am eye on your result posts as I can this evening, off to do my real job now!

All remaining tests were a success.  3rd C: drive worked.  Did 2 System parition only recoveries - both a success.  Did 2 recovery patition recoveries only - both a success - I'd like to note that no reboot was required for the recovery parition only recovery.  Then I did 1 parition recovery with C and System parition together - also a success.

I then went back and did 2 full disk recoveries will all a paritions selected - and both were a success!

I then did another "full disk" restore, but this time with the WinPE offline recovery media since all tests were started from Windows before - success!

I then did another "full disk" restore, but this time with default Linux offline recovery media - success!

So now I'm scratching my head because it's working.  Some differences to note:  1) restore time is way quicker now, that may have something to do with it, perhaps the slow speed from the first recoveries is what caused the problems?

2) I've already recovered from this machine and "repaired" the bootloader manually so maybe that's the reason it's working fine now?

Even though I don't want to, since speeds are good now, I'm going to build a new VM from scratch, back it up to the cloud and restore a full disk image starting in Windows and see what happens. 

Well, different results for certain.  I must say that I don't think the issue is with the True Image application.  I  would say that the problem rather is with the network connection during the restore process.  In your first examples the long time involved in recovery leads me to think that total time to live was exceeded for data packets which resulted in that data never making it to your machine.  So if there is fault at all with True Image then it would be that the application did not or does not recognize this loss and produced a corrupted recovery as a result.  The documentation seems to indicate that this may occur so the question is again how reliable is it?

I guess if it works for you great!  If not then don't use it!  Do not rely solely on backups to the cloud!  Nothing beats multiple backup copies with at least one of those on unattached disk, kept in a secure location except when needed and then accessed solely by boot media!

I think I've found the culprit:  don't do a full disk recovery where the entire disk has the checkbox up top and all paritions are selected below it.  Instead, remove the top box next to the disk and select all partitions except for "mbr track 0".  

I guess, if it works when you do seelct a full disk recovery - great!  However, based on this testing, in the future, if I ever have to do a full disk recovery from the cloud (which, hopefully I won't since I have 1 local backup going to another internal drive, another backup to a local NAS device, and another set of offline backups to a USB 3.0 drive), I will be sure to not include "mbr and track 0".  

Here's how I narrowed it down...

I went back to the first VM I tested with (the one that wouldn't boot until I found the solution to to delete the system volume in disk management and then running startup repair 2-3 times posted up above). I went back and recovered it with one of my local backups which resulted in a bootable system.   I then did some additional local backups and cloud backups with this VM to freshen things up with some newer data.  With this VM, all local backups restore just fine when doing a full disk recovery.  However, not one Cloud restore when a full disk recovery was selected resulted in a bootable system - not even those I did with the "fresh cloud backups".  I had even run the Cloud backup right after the local backup and the local backup right after a cloud backup and then tested local restores which all worked.  It just doesn't seem to matter with the cloud restore when selecting the entire disk on this particular build - it just won't boot aftewards.  

**BUT** Here's where it got weird.  Using that same cloud backup, I restored just the bootloader - that works.  I restored just the recovery parition - that works.  I restored just the C: parition - that works too! I then restore the "mbr and track 0" and this gives me the first sign of a problem (one that is not provided when I do the full disk recovery... "recover operation failed".  I tried again 2 more times and received the same results.

I then rebooted to make sure the OS boots - which it does.  

I then did one more full disk cloud recovery (mind you, each individual partition recovery was done with the same backup already and booted up just fine each time), fully expecting it to not boot again.  But, it did boot up!  Huh?????  I don't know, I give up.  All I know is that if I leave off "MBR and track 0", then I can complete the full cloud restore without any issues, every single time. 2 of my VM's work every time with full disk cloud recovery, 2 of my VM's don't and one of my physical laptops don't.  2 out of 5 ain't great so if I can avoid the non-boot issue by leaving off MBR track 0, then that's what I'll do in the future.  

I've spent too much time testing this out.  I'm satisfied with the thoroughness and findings.  Mic drop, I'm out :) 

Bobbo,

You did some great work here!  You are to be commended for your efforts!  I concur with your findings totally, 2 out of 5 success, not good odds!