cancel
Showing results for 
Search instead for 
Did you mean: 

Windows 10 System State restore fails

rlittletht
Level 3

I'm trying to simulate a disaster recovery on a windows 10 system. The only changes to the system beyond a bare Win10 installation were: Skype installed with credentials saved and a registry entry created.

I successfully backed up the system two ways:
• System state and the c:\ drive with all components saved (Simplified Disaster Recovery enabled was checked)
• System state and the c:\drive selected with the c:\temp directory unselected (which prevents SDR from being checked)

I restored the system from both backups on top of a bare windows 10 installation.

First restore: using the "Complete online restore" + "fully selected backup/disaster recovery". The restore failed with a ton of errors about ProgramFiles\WindowsApps failing due to access denied. This was documented elsewhere as expected because of Win10 permission problems. After restore, both the registry key and Skype were correctly restored. (YAY!)

Second restore: using the "Complete online restore" + "System State" I was able to select the c:\ and system state from the 2nd backup (which didn't include c:\temp). The c:\ restore failed with the same access denied issues. The system state restore completed with no errors. After the restore, the file system was properly restore, but the registry WAS NOT restored, and skype would not run properly (because it was not installed). This indicates to me that the System State (at least the registry) DID NOT restore.

Any insights? I've run an insane number of simulations and I always get the same results. I've confirmed the group policy for the backup operators is setup properly, I've tried with both "overwrite all files" and "skip if existing files are newer", restoring just the registry separately on top of the other restores, restoring just the registry from the SDR, etc.

This is driving me crazy.

1 ACCEPTED SOLUTION

Accepted Solutions

rlittletht
Level 3

Sigh. Got it.

Quick summary: My original restore simulation didn't "overwrite existing files" even if the existing file is newer. All subsequent tests restored System State, and the portion of the registry in question is not part of the System State. So if I had just checked "overwrite existing files" everything would have worked.

Long story (for anyone wanting to learn from my mistake).

Simplified Disastry Recovery (SDR) automatically selects everything you need (and a whole lot more) in order to restore the system completely.

If you manually select items, you better know what you are doing. There are many parts to the Windows registry. MOST of it is backed up with System State (the SYSTEM, DEVICES, SOFTWARE, etc., hives). However, HKEY_CURRENT_USER (for each user) is stored in NTUSER.DAT in the users profile directory. This is NOT backed up as part of the System State backup.

In order to successfully restore a complete system (or as complete as you backed up), here are some tips:

First, make sure you have backed up the right things. In my case, I was backing up the entire C:\ drive except for a single subdirectory (__nobackup), so I was fairly confident I had all the raw data backed up.

Now you have at least 2 things to restore: The System State for the machine and the Files/Folders that you backed up. BOTH of these backups must specify "overwrite existing files" (don't let it skip files that already exist. For the registry, these files will always exist on the restore target machine, and they will always have a newer timestamp than the backup. You must always overwrite).

For Windows 8 and later machines, you will run into a ton of Access Denied errors due to the new app model with Windows (TrustedInstaller owns files in the Program Files/WindowsApps folder, and even Backup Operators can't write into those folders). These Access Denied errors will ultimately cause the restore to report an overall FAILURE (I wish Backup Exec would list those as exclusions instead of an overall restore failure!).

After you reboot the target machine, you should have the entire registry as well as files/folders restored.

 

View solution in original post

3 REPLIES 3

rlittletht
Level 3

Sigh. Got it.

Quick summary: My original restore simulation didn't "overwrite existing files" even if the existing file is newer. All subsequent tests restored System State, and the portion of the registry in question is not part of the System State. So if I had just checked "overwrite existing files" everything would have worked.

Long story (for anyone wanting to learn from my mistake).

Simplified Disastry Recovery (SDR) automatically selects everything you need (and a whole lot more) in order to restore the system completely.

If you manually select items, you better know what you are doing. There are many parts to the Windows registry. MOST of it is backed up with System State (the SYSTEM, DEVICES, SOFTWARE, etc., hives). However, HKEY_CURRENT_USER (for each user) is stored in NTUSER.DAT in the users profile directory. This is NOT backed up as part of the System State backup.

In order to successfully restore a complete system (or as complete as you backed up), here are some tips:

First, make sure you have backed up the right things. In my case, I was backing up the entire C:\ drive except for a single subdirectory (__nobackup), so I was fairly confident I had all the raw data backed up.

Now you have at least 2 things to restore: The System State for the machine and the Files/Folders that you backed up. BOTH of these backups must specify "overwrite existing files" (don't let it skip files that already exist. For the registry, these files will always exist on the restore target machine, and they will always have a newer timestamp than the backup. You must always overwrite).

For Windows 8 and later machines, you will run into a ton of Access Denied errors due to the new app model with Windows (TrustedInstaller owns files in the Program Files/WindowsApps folder, and even Backup Operators can't write into those folders). These Access Denied errors will ultimately cause the restore to report an overall FAILURE (I wish Backup Exec would list those as exclusions instead of an overall restore failure!).

After you reboot the target machine, you should have the entire registry as well as files/folders restored.

 

View solution in original post

@rlittletht,

Great you were able to find on your own the issues with SDR backup and recovery. Please do include here your suggestions on how we can make it better for others to discover solutions faster for such problems.

 

Thanks,

Amrish

GPT1
Level 2
Employee

SDR restore would be a better alternative in such scenarios. 

The WindowsApps folder related issues are known issues and will be taken care of in future FPs.