What started this was when I saw a thread on the Terabyte forum discussing the use of the metadata. It left my eyeballs spinning. Since I always beat on new features before committing to them and having just figured out a conflict that was causing failures in IFW. By coincidence I was looking at the Drive Snapshot webpage, and what caught my was when they said if you had created a "Hash" file (checksum file) you could set aside the full image as only the hash file was needed for differential creation. WHOA. There is a good discussion here =http://www.drivesnapshot.de/en/differential.htm= Next up my setup for test. Standard Macrium set up. For restoring IFW, I use a Win10PE Se USB key and on it I have Image64.exe ifw.ini and ifw.log. This allows running IFW just as if in windows. Now the test. All images and restores in IFW were using metadata and were fast.. First I run chkdsk to make sure the disk is good. Then I took and incremental image in Macrium and then in IFW. Booted to RE and did a metadata restore. Fast. Next I booted from there right into the Macrium Recovery. First did a chkdsk to be sure disk was okay. It was. Then I did a macrium restore of the incremental. Since Macrium normally only restores changed sectors, the restore time is a function of how many sectors have changed. Based on my system I would expect if IFW restore was good, then macrium should see a minimum number of changed sectors, and based on my experience doing this the macrium restore time should be a mnute or less. It ran the restores in about 45 seconds. So from that I can conclude the IFW restore was good. I ran this test after each hourly macrium incremental. All were sucessful. This is a pretty good indication I can use the metadata restore in IFW. But I will continue to test. Then one other test I did and this I went into the VM for a slightly different environment. ( I have also done this on the real hardware) I set up A macrium full and incremental and same for IFW. What I wanted to see was how IFW would behave if I did a metadata restore on a wiped disk. So I booted into the Win10PESE usb key and using a couple of utilities, wiped the drive clean. As I expected IFW did a perfect restore. Next I wanted to look at VSS since terabyte is now advocating it's use. Reading about VSS, there are a lot of words used but what happens to your data, so I tested. I created a new speadsheet and put a series of 1111's in the first cell, and took an IFW incremental Image 1. Then I opened the spreadsheet, and added a 2nd cell of 2222's. I left Excell open and took Image 2. Then I closed and saved the spreadsheet, and took Image 3. Restored image 1 and found the spread sheet had the cell of 1111's . Restored Image 3 and again as expected found the spreadsheet with the 2 cells 1111's and 2222's. Then I restored image 2, which was taken with excel open with the 2 cells. All it had was the 1 cell with the 1111's Excel should a recovery option, but all it had was the 1 cell. So the conclusion is when an image taken with data files open is what you will get on restore is the state of the file on the disk and work updated will be lost. Moral: before imaging close data files. BTW, I've done the same VSS test with Macrium and result was the same.
Unless an application declares itself to Windows as a "VSS Writer" (when done, it's done at application startup), it's purely up to the application to determine when its DATA gets flushed to the storage element (or it's left up to Windows to determine when the flush occurs)... its a crapshoot depending on how the application works. When a VSS FileSystem LOCK is requested, the first thing Windows does is inform those "registered" VSS Writers that a lock is about to be made on the FileSystem. It then waits to hear back from the registered "writers" that they have made their own FileSystem "consistent" by flushing necessary cached DATA on to the storage element. If it hears back from all the registered writers (if not, it waits a specific period of time), it then initiates the LOCK on the FileSystem and informs the task requesting the LOCK (in this case IFW) that its good to go. This allows databases and the such time to make themselves consistent in the FileSystem... the whole thing works pretty well. Your eXcel (as well as tons of other applications) is not VSS aware and as a result never declares itself as a VSS Writer... that's why its DATA never gets flushed before the LOCK is issued. I believe the only OFFICE application that's VSS aware is the ACCESS database component.
I don't think Access 2010 is, maybe later versions. But the simple solution is quickly just shut them down and restart them. Then you are good to go.
