...
Unfortunately we have just become aware that since release v71 v7.1.3147 on 17th April 2018 it was possible that Macrium Reflect could create corrupt and irreparable Incremental or Differential Image files. The problem occurs if the Macrium Changed Block Tracker (CBT) driver participates in the backup. By default, the CBT driver will participate in the second and subsequent Incremental or Differential Images Image of a backup set after a Windows *full system reboot. For Differential Images, CBT will participate if the Full Image, in the same backup set, was created in the same Windows session, i.e, no Windows *full system reboots between the Full & Diff (see Fast Start-Up note below). If an image is affected then it is unlikely that it can be mounted and browsed successfully and restore will result in a corrupt file system.
Info | |||||
---|---|---|---|---|---|
*Note: Windows 10 includes a default option called 'Fast Start-up'. If this is enabled then CBT may persist over a Windows normal Shutdown or Restart.
|
Technically, the problem arose from a misaligned data structure in the code and our testing prior to release didn't trigger this error. We have since introduced more stringent tests that will prevent this type of error from occurring in the future.
...
What Images are affected?
Info | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||
|
Images that may be affected include Incremental and*Differential Images , File and Folder was not affected. that use the CBT driver to participate in the backup.
*Differential images will only use CBT if the image being appended to, the Full image, was created in the same Windows session.
i.e, there have been no Windows full system reboots since the Full image was created. (see Fast Start-Up note above).
The words 'CBT init Success' and 'Searching for NTFS meta data' will be seen in the Image log:
The build number of Macrium Reflect will also be shown in the footer of the log.
The affected build numbers are: v7.1.3147, v7.1.3159 & v7.1.3169. No other build numbers are affected.
If you have any doubt, then you can mount the image file and run chkdsk from and elevated command prompt. Use the mounted drive letter as the chkdsk target as shown below:
If no errors are returned then your image is OK.
The above example shows typical corruption of the NTFS file system.
If you see errors then confirm by running chkdsk on the source file system
It's possible that non-critical file system errors have been carried over from the source file system. In this case your image is fine
Info | |||||
---|---|---|---|---|---|
Note: It's possible for good images to report minor and innocuous errors when using 'chkdsk'. These errors will have been transferred from the live file system but don't cause a problem with the image. If you see only the following error then there is no problem:
This is nothing to worry about. |
Info |
---|
Note: Corrupt Image files will verify successfully using the Macrium Reflect verification function. The nature of this error is that key data was omitted from the image, the data that was backed up is not itself corrupt.. |
...
Info |
---|
Note: The backup set chain is not broken. This means that non CBT Incrementals and Differentials created after corrupt files will be OK to browse and restore. |
...
Anchor | ||||
---|---|---|---|---|
|
These image files should not be restored and may be deleted by using the Delete functionality in Reflect. Deleting Incremental Images will also delete dependant Images created after the corrupt file and this may not be desirable.
After updating to v7.1.3196 or later, leaving the corrupt images in the backup set will not affect the integrity of later Incremental or Differential images in the same backup set whether using CBT or not.
...