Macrium Reflect

I don't know why this is happening, hopefully jphughan will chime in. I personally don't bother with verifications as I think they can never guarantee a perfect restore, however I've noticed that when something is not right it shows during the backup, in other words a backup is usually never produced as successful if there is a problem. Every now and then I test a restore with a recent image just for my peace of mind, they have always worked perfectly for many years.

 

@Tinstaafl
https://www.wilderssecurity.com/threads/macrium-reflect.356309/page-315#post-2880060
Try disabling HitmanPro Alert for the duration of the backup.

 

I uninstalled HitmanPro Alert yesterday, and the backup ran clean last night. Will keep an eye on it for the next week or so.

Be interesting if that was the cause of the issue. I have gone down many rabbit holes recently chasing this, and ruling out hardware and drivers.

Even had a BSOD for MEMORY_MANAGEMENT last week during image verification that directly implicated hmpalert.sys. But that was a one-time event.

Have had a few other random BSOD's during backups, that vaguely pointed to memory issues, but were mostly ntoskrnl.exe related. So I isolated each memory stick, and ran Memtest86 for a dozen passes with zero errors. PC is not overclocked.

 

I'm hoping JP will share his thoughts on this.

Here is my take on this so far: The image file is written to the target disk block by block. A checksum is calculated for each block as it is copied from the source disk, and then stored with the image file.

When a verification is run on an image file, each block from the image file is read into memory and compared with the previously written checksum in the image file. No comparison is done with the source disk.

So if a verification fails on first pass, then succeeds on a retry, that would imply that a spurious error has occurred to the data somewhere along the path between the backup image file and system memory. If the same image file eventually passes verification, that implies the data written is good, but that something (what?) has interfered with the checksum comparison on the first verification run. Weird!

 

Now, of course, that's not the only reason. Any type of "soft" read errors coming from those external USB drives, or the docks they may be mounted in, WILL cause a problem during verification... it's not just a writing issue. Even a flakey memory path can cause those types of issues.

You need to check that System out pretty well...

 

How did you eliminate drives, and which drives, meaning source or destination?

Did you swap USB ports and cables for your external drive?

I remember a thread on the Macrium forums where somebody actually traced their verification failures down to their CPU.

 

At this point, I could only think it may be the target drive controller itself. No dock here, as it is a sealed WD Elements 1TB USB 3.0 drive. Already have swapped USB ports, cables, & USB controllers (have 2 USB controllers, Intel USB 3.1 onboard my ASUS Z-390-A Prime, and a Renesas USB 3.0 on PCIe.

Have also done the 'SFC /scannow' and DISM procedures, as well as an in-place Windows 10 repair install.

 

Swapped the target USB drive to another port/cable, then to another USB controller (different brand, different driver). Details in my previous post that I typed as you were posting this question. Source disk is my boot drive on C, a Samsung SSD 860 EVO 500GB.

I also have another USB drive, a WD Passport 2TB Ultra, that I use to take weekly and monthly full images of the same source SSD drive, and have never had a failure using that! So I think my source drive, memory, and CPU are OK.

The only thing that I haven't done yet is to replace the target USB drive used for my daily full images with a new unit. But I have re-formatted it and run the full WD Data Lifeguard diagnostics on it, passed with no errors. All S.M.A.R.T. data is clean.

 

Follow up on removal of HitmaPro Alert...

Had another verification failure on my daily image last night, followed by a successful retry. So that pretty much rules out HMPA. No other real-time AV protection here at the moment besides Microsoft Defender.

 

Tried Macrium ISO 8.0.6562 on my old laptop - as a result the "advanced options" picture slides down, so there is no "OK" button... I took an old ISO from the 7th version (Macrium 7.3.5672), - everything is in order, the buttons are in place ...
My Laptop "Acer Aspire One AO532h" (1024x600 resolution) and "ASUS T200TA"(1366x768 resolution)

 

When I try to access that picture I get alert from ESET:

 

Same here : JS/Packed.Agent.N suspicious application

 

How do I prevent consolidating please with incremental images when creating a schedule ?

 

https://knowledgebase.macrium.com/display/KNOW80/Disabling Incremental Consolidation

 

Or just uncheck the Incremental retention policy in your definition file, in which case Incremental purges will only occur when their parent Diff or Full is purged. The method in the above linked KB article requires a registry tweak and was added by Macrium for cases where users wanted Incrementals to be purged only as entire chains even when a parent Diff/Full was NOT going to be purged. That’s a relatively rare use case — which is likely why it’s only achievable via registry tweak.

 

Does anybody know if there is an option in MR to only show desktop notification if error or warning occurs during scheduled backups?
I know that I can disable notifications for MR entirely, but I would like to get desktop notification if there was a problem. I also wouldn't like to use email notifications for such situations.

 

I don’t think so, but that mentality of only wanting notifications when there are problems can and does cause people to fall into a false sense of security and then not be aware of problems that are preventing anything from happening at all. People make this same mistake with how they set up email notifications too, and then assume that lack of any email means everything is working fine. Then they stop checking the logs because “I haven’t seen any problem report emails,” only to later find out that they were having one of several possible problems that can prevent both their backups from completing successfully and alert emails from getting to their mailbox.

There’s a lot to be said for receiving positive confirmation that a job was started or that it completed successfully.

 

Thank you for your confirmation. I was hoping that there is such option but I didn't know about it.
Of course notifications can give you false sense of security that's why I regularly check out that backups are created and from time to time restore one to see that's everything's OK.
I decided to hide notifications for MR since they are more annoyance to me than anything else.
If they ever decide to add granularity to them I will reenable them.

 

...and this statement is exactly why there should be options. If it's all or nothing, some folks are going to choose the nothing.

 

+1, the notifications are useless. You start a backup yourself, then you get a pop up in the notification center backup has started? and you're even looking at the screen that it started! really?

 

So far MR is been producing uninterrupted backup images on this end and occasionally i use Verify Option more lately but is it common for the Verify Image feature to take some time? I was curious since i assume every backup solution including MR do image backup checking fairly much the same or differently then others.

In my routine when backing up i almost always backup a "Live" system but once in a while i use the UFD to make full backups offline and/or manual incremental (s)

 

thanks, stapp.

 

Verify takes about the same amount of time here that it takes to write the image.

The verification task processes the target image file and compares it block-by-block with the checksums written to the image file when the image was created. So yes, takes some time.