system partition backup file does not include windows update history

David, this is not an issue that I have noticed myself personally but suspect it is how recovery may work to allow for the system to do a fresh check for updates.

Make a comparison of the contents of the C:\Windows\SoftwareDistribution folders on your restored system and in the backup .tib file contents to see if they match or not?  In particular, check the DataStore folder at that location as this contains the encoded logs data for Windows Update history information.

ATI does not exclude these folder locations or file types by default, so would expect the files to be present in the .tib image file.

Hi Steve,

This simple query may be opening a bit of pandora's box.

First a brief explanation of my backup system/method.

- I have a desktop with 4 disk drives (1 ssd, 3 hdd) installed, total about 2Tb capacity. Other hdd are connected via usb as needed, and there are 3 networked stores on the local LAN. The desktop ssd is the C drive only.  The other 3 hdd are partitioned into a series of logical drives and used by data type;  eg, programs, email, data in the form of pictures, video etc, downloads and so on.  I set it up this way to improve performance by minimising the disk access delays when apps, the OS and data are interacting.

- I backup each drive individually, manually, to a removable hdd using usb3, and then copy the entire backup set to a network store on my local LAN.  I also copy the 3 drives most likely to change between backup cycles to a local drive in the desktop tower.  The locally attached hdd with all the files is removed between cycles and stored as far away from the desktop as is reasonable.  The on-PC backup files function as ready recovery items should I or the local PC fixit store need them (just taking the tower has it it all in the latter case).  Screenshot of the local backup files attached.

- the cycle is entire PC every 3 months - on 2 Feb 2020, total of 492gb.  Every other 2 months - just the 3 drives with most likely changing data (2 Feb total - 65Gb).  All of these are custom/full backups; each individually usable.

- recovery is normally using a bootable recovery disk - for C but also the other drives on the odd occasion I need them.

To answer your question

- because the on-PC backup copy of C isn't in the TI backup list, I cannot get the windows-TI copy to open it for comparison. Without the off-PC backup store attached,  In recovery mode even with an extsive list of backup's in the LH pane, TI says I need to do a backup because - since it cannot find the items in the list - I haven't done  Is there a way to browse for a backup file in recovery mode in the windows version??

- the contents of the folder you mention (came from a backup before the latest attempt at win10 upgrade on 31 Jan20) has data in it but it's clearly formatted in some way since whilst it seems 'english' the data is scattered in the file: unreadable by me.  OTOH, the local copy of that C drive backup file is certainly accessible to the bootable recovery disk, because that's what I used, but it's just the file, not a breakdown contents list.

Pandora's box

TI Backup may also NOT include the System Volume Information folder in the backup file, and I suspect that is where the windows update history is stored.  I say that because it's become apparent over several system volume recoveries that the restore point space is wiped in a recovery: after recovery, there are none, start over and the windows space allocation is 100%.  I found that out the hard way after installing the ssd and recovering a backup image to it;  9 months later the C drive was full instead of  about 49%.  Microsoft pointed these little details when I complained, and suggested a tool to determine a state of play.  A screenshot of the system volume information today using that tool is attached.

And the same thing has happened with this recovery - no restore points, allocation for them 100%.  I generally set this marker to 5% of available storage, and again have done so, including creating a new system restore point.  And now no update history after recovery of C - cannot be a coincidence.

So perhaps the answer to the original question is in 2 parts:

1. does TI backup the system volume information folder?

2. if not (suspected), how can TI be configured to do that?

Can you answer - or get an answer - to these?

Thanks

David, thank you for the comprehensive information about your systems and backup strategy etc.

ATI by default does exclude the System Volume Information hidden folder structure - you can see this in the Exclusions page for any backup task in the ATI GUI, along with other default exclusions that are set.

As far as I understand, no Windows Update information is stored in the SVI folders - this is used primarily for System Protection / Restore point data, and may also be used by the Microsoft VSS snapshot service when backing up.

You can add or remove entries from the Exclusions list for your tasks.

Note: in Windows 10, Microsoft turn off System Protection by default when installing all recent builds of the OS - this has been the case for at least the past 2 years.

See KB 62304: Acronis True Image: Windows system restore points disappear after backup, recovery or disk cloning

Provided you have ATI installed on your computer(s) then as part of the install, it integrates with the Windows Shell to enable functions from with Windows Explorer.  You can double-click on any .tib file and it should open in Explorer and allow you to browse / navigate through the contents, using Copy & Paste as needed.

For Disks & Partitions .tib files, you can right-click on the files in Explorer and then choose the Acronis True Image option followed by options to either Mount or Validate the backup image.  Mount is only possible for backup files containing a partition structure.

See KB 60169: Acronis True Image 2018: how to restore files from a backup (Windows) - for more information & screen shots of the above.

Hi Steve,

Thanks for the prompt detailed reply.  I'll work on what folder the history is in with MS, and get back here with the details.  Since it's missing in every system drive recovery I've done over the last year it's obviously in one of the default excluded files.....

To follow up my point about recovery using a copied (from the removable backup drive to an on-system folder) system partition backup, I attach a screenshot of the ATI UI at that stage:  marked up with relevant comment.  The screenshot of the on-system folder with the file was included with my prior post.  A 'search for backup file' button would make this method much more usable.

I also tried out your suggested approach - opening the file from within windows explorer.  Whilst it is attractive if you know what folder or file is corrupted, and it's not the system drive (basic caution here) recovering the whole partition using this method does not look to be practical unless one is prepared to tediously do every folder in turn.  Generally I use the recovery disk for whole partition recoveries, and it hasn't failed yet.

David, the 'no data to recover yet' is an indication that the task is not linked to the backup file, so to resolve this you can use the option to 'Add existing backup' found to the right of the usual 'Add backup' behind the caret (v) menu, or else try doing a Validation for the task and select the file if told it is missing.

You should never attempt to recover anything other than user files and folders from any backup of a Disks & Partitions type, and definitely not attempt to recover the OS partition in this way.

Using the rescue media to boot the PC is the safest option for any OS recovery.

Hi Steve,

Thanks for that info.

It seems my practice of using the recovery disk - it was always the easiest at hand - has been the right one.

And thanks for the pointer to selecting an existing backup file - hidden it is.  But it works.

Haven't had an intelligible response from MS yet re the folder the update histories are in.

Hi Steve,

I've had a response - actually, an extended dialogue - from MS about the update history location.  The history is stored here

C:\Windows\SoftwareDistribution\DataStore\DataStore.edb

which is included in the backup file scan, and thus restored with everything else.  However, windows apparently detects a restore somehow ??? and clicking "view update history" gets the missing update history response in the screenshot attached. New updates after the recovery - display OK, but old updates as at the time of backup - zeroed.  The MS community doesn't know why it is done like this.

Further, this missing update history after recovery has been going on for over 10 years and multiple OS versions - part of the dialogue I mentioned involved reference to complaints about it involving windows 7 dated 2011, and according to the MS community agent, it's still going on with windows 10.

Part of the dialogue mentioned also speculated about a recovery parameter - a switch - that controls this.  I think that the update history is still there, in that datastore, waiting for the switch.  Reason - 2 days after the latest recovery which generated this topic the datastore folder dates to July 2015 (last time I completely rebuilt my PC after a motherboard failure: from 32bit old to 64 bit new) and currently has a content of 1.5Gb.  See screenshot re datastore properties.  The logs sub-folder shown in that image has a number of .txt files whose content includes text that is displayed on the update pages.

Can you/Acronis throw any light at all on how the update history in the backup goes 'missing' after recovery, and possibly how to get the history back????

David, thanks for sharing your research into this puzzling issue.  It seems from what you have found via the Microsoft community that this is an issue caused by the OS design rather than by the tools involved in performing any recovery.

Acronis is capable of making and recovering the OS drive by using sector-by-sector methods which may allow for the drive to be returned back to the exact state it held when the backup was created, but this would need to be tested to determine if the update history issue is resolved or still remains?

Sector-by-sector mode will create a much larger backup image and take longer, especially if including unused sectors.

Steve,

At the moment, no update history on restore is where it's at.  Given the accuracy of MS assertion about where it's stored, I am personally convinced that the recovery restored the update information.  But since the last 4 windows versions (7, 8, 8.1, 10) all have the same issue, I know of no way to either test that or to intelligibly get at the information that's clearly in the referenced data store.  I thought that Acronis as a major software vendor may have some clout with MS to that effect.

David, unfortunately the MVP's have no direct access to the Acronis developers to be able to raise these issues, so your only route would be to raise this as a Support Case / ticket with them and point them to this discussion in the forums.

Hi Steve,

I can't seem to find a means to do that. At the bottom of my previous case lists there's a link for submit new case, but that just takes me to the technical support page where the only mechanism seems to be to ask the community - which I've done.  I must be missing something.

Can you point me to the correct link?

David, sorry I spend so much time in the 2020 forum that I forget that all the earlier versions are out of support, so the only way to be able to submit a new case would be to demonstrate that the issue still occurs when using ATI 2020 which is in support.

You could take out a 30-day trial version of 2020 if you feel strongly enough to want to do this?  Trial support includes access to full support during the period of the trial.

Hi Steve,

I found a way.

On the support page for the 2018 product, there's a tick-box "I have a recovery issue".  Selected that and I got a ticket page.  Filled it in with reference to this community thread.

The ticket number is 04313238

and the title line from the confirming email is:

"[04313238] Windows update history missing from system partition recovery [ref:_00D30Zcb._5001T1K3Y3E:ref]".

David, that is great to know - it was always stated that support was available for recovery issues so thanks for sharing the process about the 'tick box'.  Hope Acronis can throw more light on what is going on with the Windows update history on recovery.

David, I'm chiming in a bit late here so maybe you've figured it out.

I did some google searching and found that this is not a problem unique to Acronis backups. Others have reported lost Update History after a disk restore (including with Windows own backup). Here is a link that may shed some light...
https://www.sevenforums.com/backup-restore/200578-windows-update-history-empty-after-windowsimagebackup-restored.html

Although the update history is missing, others say that when viewing Installed Updates it seems to be OK.

I believe it is a result of this registry key:

HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot

The entry WUA on the right tells the backup not to include the folder %windir%\softwaredistribution\*.* /s.

Try deleting the WUA entry.
 

Paul, it looks like there is more than one place where the WUA entry would need to be deleted in the registry.

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup also has the same WUA entry.

Bruno, Mustang, Steve,

The state of the ticket I raised

[04313238] Windows update history missing from system partition recovery    [ ref:_00D30Zcb._5001T1K3Y3E:ref ]

is that the Acronis support desk has advised that

"As per your request, I have forwarded your request team 
concern and get back to you once I receive an update from them."

So far, that's only 3 days old and I've had no further advice.

As to the "hint" in that team 7 webpage Bruno mentioned, to view installed updates - it is indeed all there:  as I expected.  The installed updates displays by program name/category, and can take quite a few seconds (more than 10) to fully display.  I caught this image on the PC about which this post recovery complaint is about during the display for windows - it shows 93-odd lines, but the full list is over 230 - attached screenshot "installed updates win7 after recovery".

I found the HKLM items mustang and steve mentioned, and was about to try it out, but first tried to make a copy of the registry (export???) - but the only result I got in the save location was a file that's only 6kb big - which seems way to small so I abandoned this test there.  Related queries:

- possibly what I got was only the folder I was in.  How do you export the whole registry?

- maybe I can guage it better if I could see the size of the whole operating registry file - which is located where??????

As the not backing it up and not snapshotting it, effectively by changing the WUA keys, I have doubts.

Without changing any of these from the existing (assumed default) values, what is happening is

- a backup includes the software delivery folder where MS says the history data is

- the recovery from that backup includes that software delivery folder, and without any subsequent updates there was 1.5Gb of data in that folder.

So (theorising on the basis of observation) something in the start of windows tells it that a recovery of the system partition has occurred and on that basis the view history display is disabled and a user gets that 'you have not tried to update the PC' message.

Updates which occur after the recovery - for example, this month after what is normally patch tuesday, - updates applied will be listed, and 2 items trickled thru last week, even tho the win7 support ceased on 20 Jan: see attached screenshot update history Feb 2020 patch cycle.

Why keep pushing this?  as you know,  MS updates have the habit of specifying requisite conditions (only apply this KB if KBxxxxx is installed), for which the history is the only source.  And occasionally - it's happened to me - an installed KB has to rolled back because of issues it caused.  There was one such several years ago that screwed the windows licence number and made it appear as an illegal copy.  That was found in 3 days but needed a roll back of the relevant KB's (several impacted) if you had updated on patch night.  Ever since then I've been careful to update a few days after the patch release date to minimise the chance of this sort of thing re-curring.

Steve,

The FilesNotToSnapshot is the key that controls full disk backups using VSS.

The FilesNotToBackup key is used for other types of backup. I don't fully understand its use.

I did a test to prove you only need to worry about the FilesNotToSnapshot key. I created a Test.txt file and added registry values for that file to both keys. I ran a full disk backup and the file was not backed up. Then I deleted the file from only the FilesNotToSnapshot key leaving it in the FilesNotToBackup key. I ran another full disk backup and the files was backed up.

David,

I'm quite sure the update history is hidden in the softwaredistribution folder.

Sorry, I forget that users are reluctant to modify the registry. It's second nature to me. I don't like your plan to manually "backup" the registry and then attempt to restore it later. That is very dangerous. I would suggest two much safer alternatives:

1. Export the FilesNotToSnapshot key from the registry before deleting it. Then you can simply import the key from the file you save later if you want it back. You do this by highlighting the FilesNotToSnapshot key in the left pane. Then select Files/Export from the menu. Give it a name such as WUA.reg and save it to known location. To get it back, highlight HKLM and select Files/Import and navigate to the saved location of the WUA.reg file.

2. Modify the WUA value of the location of the folder. For example, place an X in front of the folder name. Do this by highlighting FilesNotToSnapshot/WUA key in the right pane. Select Edit/Modify. Click in the highlighted path to place the cursor in front of softwaredistribution and enter an X. Then save the change. You can return to normal by simply removing the X from the path name later.  

Thanks for the replies guys, and you are right about reservations re fiddling with the registry.  Everyone I've read advocating a change there has emphasised saving it first, and I've forgotten how to do that.  Nothing in the reply fills that query.

Several thoughts on them.

1.  What is VSS?  I cannot find anything in the windows help about it.

2.  It isn't whether to backup something (not just a file, but one that is the whole the history database) per mustang's test that is the issue, but whether to display it as an updates page after a valid system partition restore (it booted!!) puts it back on the C drive.

So, it seems the thinking is that these 2 registry values in combination (?) are the switch that the OS uses to determine whether to display an complete update history.  The registry seems like the place such a control would be, given that it is only used figuratively "once in a blue moon".  But I don't understand how they could work after a normal start or re-start, and display the history list on that updates page, yet not work (no history display) for a normal start after a restore.

David, just to play devil's advocate a little on this issue, Microsoft have set these restrictions for files not to be snapshot for a reason and this has been the case for a very long time, so they must have done this for good reason!

Microsoft VSS (Volume Shadow Storage service) is used by all the main backup applications including the older Windows 7 Backup tool still present in Windows 10.

One thing that I have found myself doing many times over the years is to blow away the Software Distribution folders to resolve Windows Update issues, and the net result is that when update runs, it quickly discovers all installed items and identifies any new updates needed, rebuilding the folder structure again easily.

If your main concern here is the need to roll back an update that causes a problem on your computer, then rather than trying to recover the Update History information, ensure that you make regular backups using ATI, ideally before any major Windows Update activity, so that you can revert back to the 'before' state if needed.

Finally, one other option that is available (with cautions!) is to not use Microsoft VSS for your backup, but instead to choose to use the older Acronis Snapshot process as was used by default in ATI 2014 and earlier versions.

See KB 59440: Acronis True Image: 'Snapshot for backup' option overview - for more information on the last option.

PPS. The safer option for the final option is to boot from the Acronis Rescue Media and make the backup outside of Windows where no snapshot method at all is used, so no exclusions are applied by default unless manually configured.

I agree with Steve's comments above.

Just to expand on the backup done by the recovery media. There is a snapshot taken. It is done using Acronis' snapman service instead of Microsoft's VSS (Volume Shadow Copy) service. There is one exception. This is where Bitlocker is involved. In the most recent version of TI 2020 (build 22150), Acronis added the volsnap upper filter to the WinPE media. I have been told by the Development Team at Acronis that this causes TI to use VSS only for Bitlocker volumes that have been unlocked. Now there is still a FilesNotToSnapshot key in the WinPE registry. I looked at the WinPE version I'm using and found that WUA is not mentioned in that key.

David, that means using the recovery media to do your backups would include the software distribution folder because the snapman driver does not pay any attention to the FilesNotToSnapshot key. 

David, I don't know if this will work but from the Command Prompt, wmic qfe list gives update history. Just wondering if it will show any more information.

Hi Guys,

A load of detail.  To address some of it . .

1.  The security suite.  I use AVG (for years: began when there were small download limits - 1 or 2 Gb per month - on ISP service and AVG was the only one with a small daily footprint - less than 50kb virus pattern update, rather than 6+mb that the previous suite did, which over a month was huge - probably because it only downloaded the relevant language [english], not all of them.  And that's just continued because there was no reason to change), so bitlocker things are not an issue.

2.  My backup cycle gets a custom/full backup of the C:\drive/system partition as a separate file set (2 files limit of 25Gb) once a month using ATI (outlined in one of my early posts here).  Every 3 months, the entire PC is similarly backed up.

3.  The bootable media I use now is the download .iso version.  I was involved in an extensive debug of the BartPE approach 10 years ago, but that got pretty old with all the variations windows can throw at you and after the iso version became generally available I switched to using it, for restore, mainly.  [Also the bootable iso media file for DD12].

Altho I use the system ATI for backup, because when I need it it's normally a partition/drive recovery I use the bootable ATI  recovery disk.  I daresay individual files can be restored if one is certain only that file is involved, but generally that isn't the case so I restore the entire partition/logical drive.

The most recent use of this and cause of this topic thread was another (3rd) attempt to upgrade to windows 10 that broke essential things and needed recovery from a windows7 backup image (outlined earlier), and not for the 1st time I noted the update history wipe after the system partition restore, and decided to do something about it;  at least find out why, and maybe how to make that history display good again.

4.  VSS.  Handy to know.  And I gather it's used in part by many 3rd party backup/restore programs,  Apparently ATI was /maybe still is? one of them.

5.  Use of history data.  Now that formal free extended support for windows 7 has ended, perhaps of limited usefulness to me.  But possibly not completely - The Feb20 patch tuesday supplied an update for "2020-01 Preview of Monthly Quality Rollup for Windows 7 for x64-based Systems (KB4539601)" and the monthly malware check "Windows Malicious Software Removal Tool x64 - February 2020 (KB890830)".  Paid windows 7 support is still available and a lagging publication of any updates from that may happen.

But for windows 8, 8.1 and 10 - the same wiped update history page exists after a system partition recovery.  Sooner or later everyone will be using win10: fixing that display will be good.

And altho the update history has been "wiped" as a display, that same information is available when a user chooses to select the "installed updates" link you pointed out several posts back.  That list is still available, moreover, it's sorted by application type and then by date:  newest at the top, oldest at the bottom of the list (mine go all the way back to July 2015 when the desktop was last completely rebuilt: 64bit platform to start), and each entry includes the update name, KB number and the program affected, and extends over any number of partition recoveries in the multi-year time frame.  The fact that a KB is listed means the update install was successful - failed ones clearly are not in the list, so the purpose of wiping the update history after a system partition recovery is not clear.

6.  Snapshots.  I am assuming that this means a snapshot of the folders/files at a time when the system is running and files may change.  If so, I cannot see any backup from within a running computer doing anything else.  To avoid that, backup using the bootable ATI disk would be the only method I know of.

But since the backup/recovery from within a running system works - other than this display of update history the topic is about - I am pretty certain using a bootable disk for the backup would not change anything - the software dist folder is still included in either method, and likewise a recovery puts it back.  It's what windows does then - as compared to normally - that's the issue.

I guess I'm being dense and we are talkiing around the problem, but the why is not apparent and without that a means of negating it and causing a correct history display after recovery as a normal event seems elusive.

Hi Guys,

I have in fact found a way to get the history data, and apparently I've been remiss in not posting it here.  So, the details, from the top;

1.  After a system partition recovery, including the datastore folder, a user attempting to view update history will use the control panel windows update page - screenshot

2.  In the windows update page, clicking on the 'view update history' item, top LH pane list displays that 'the PC has never been updates' message - screenshot

3.  But in the same windows update page, at the bottom of the LH pane there is a "See all installed updates" item.  Select that, and windows sorts and extracts the data from the datastore and displays it - screenshot.

It takes about 10 seconds to do the sort, and the result is by category and alpha, not by date, but everything back to the last time the system was wholly rebuilt from ground zero is there. In my case, the last screenshot, 230 items back to July 2015. The utility of the most recent update(s) at the top of the list is not available, but the list includes all the knowledgebase numbers that would be needed to confirm (or refute) that articular update had been applied.

The ticket I also lodged with Acronis about why this done (by MS), using their corporate clout, has come to nothing:  either Acronis has not enough clout, or the company does not want to push it.

Thanks for all the help.

David