Macrium repeatedly failing verification, out of ideas

klepp0906 · 16 Apr 2019

Correct. I am on the exact driver your showing above. Its the newest 16.x. Why the 17.2.x.x fail /shrug. So do the newest 15.x.

The above do not.

Unfortunately having my suite of drives not spin down isnt an option. If it were - i'd be free and clear of this stressor :P

Testing a few things like AHCI between HIPM/DIPM and pcie link state settings, but im nearly certain its gonna be a bust and im just going to end up having to use M$ driver

Ultimately its all the same in everything but name, bar the fact the M$ one is the only one ive found thus far that presents none of the aforementioned issues.

f14tomcat · 16 Apr 2019

klepp0906 said:

Correct. I am on the exact driver your showing above. Its the newest 16.x. Why the 17.2.x.x fail /shrug. So do the newest 15.x.

The above do not.

Unfortunately having my suite of drives not spin down isnt an option. If it were - i'd be free and clear of this stressor :P

Testing a few things like AHCI between HIPM/DIPM and pcie link state settings, but im nearly certain its gonna be a bust and im just going to end up having to use M$ driver

Ultimately its all the same in everything but name, bar the fact the M$ one is the only one ive found thus far that presents none of the aforementioned issues.

Well, good luck with the final experiments, hope you find it.

mmortal03 · 11 Mar 2020

I might've found a workaround for this. Under Backup->Disk Write Performance, you have the option of editing the backup write method for each of the drives that you backup to. My internal backup drive's method was set to File System Cache (which *is* faster on my system), but I tried changing it to Direct Disk I/O, and I was then successfully able to make a full image that verified. It *was* slower, and I'll have to do some further testing to confirm that it continues to work, but it's worth trying it as a workaround if you haven't.

f14tomcat · 11 Mar 2020

mmortal03 said:

I might've found a workaround for this. Under Backup->Disk Write Performance, you have the option of editing the backup write method for each of the drives that you backup to. My internal backup drive's method was set to File System Cache (which *is* faster on my system), but I tried changing it to Direct Disk I/O, and I was then successfully able to make a full image that verified. It *was* slower, and I'll have to do some further testing to confirm that it continues to work, but it's worth trying it as a workaround if you haven't.

That usually holds true for an externally connected USB HDD, but not for internals on a SATA port. Just verify you have this set correctly for your internal drive. MR File System Cache is self-defeating if the device itself does not have it's controller set for caching. What you would likely see is a fairly rapid transfer rate that would slow down considerably around the 50% point, then seem to crawl to the end.

Macrium repeatedly failing verification, out of ideas-2020-03-11_08h40_48.png

mmortal03 · 12 Mar 2020

Right, but this internal drive *does* have write-caching enabled, so that's not the issue. The issue requiring the workaround is just that MR's File System Cache option (but not it's Direct Disk I/O option) is causing (or revealing) buggy behavior, causing image verification to fail. It might even be a bug in the controller drivers, like what is discussed above -- I don't really know.

SoFine409 · 12 Mar 2020

I just started using an external USB 3 enclosure with two HDs set up as Raid 0 using Windows Storage Pool for Macrium backups. The first time I ran a back up it hung during the verification phase and eventually failed. I immediately ran verification again and it passed. I then deleted the storage pool, reseated the two drives and recreate the pool. Since then I’ve run several more Macrium backups and had no issues. This may or may not have bern the cause.