Verify/MRVerify questions


Author
Message
alank2
alank2
New Member
New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)
Group: Forum Members
Posts: 7, Visits: 18
I've see KB entries that reference two executables, one named verify.exe and the other named mrverify.exe.  One is 7.1.3141 and the other is 7.0.2182.

Question #1 - is there an official release for this tool?  Where?

Question #2 - will it be integrated into the main installation at some point?

Question #3 - it seemed like the one named verify.exe was the newer version.  verify.exe clashes with the built in verify command, so mrverify.exe is much better.

My goal is to eliminate the network bandwidth used by the autoverify option when backing up machines to a remote share.  I'd rather run a scheduled task on the machine with the images locally so it can verify them much faster.  I did this previously with a competitors backup solution by using the archive bit to detect if an image has been verified or not previously.  The plan goes like this:  Macrium creates an image, but does not auto verify it.  That image will then have the archive bit set.  I have a tool that recurses directories looking for mrimg files with the archive bit set.  It then calls mrverify to test the image and if it is good, it clears the archive bit so it will not need to be tested again.  If it is bad, it deletes the image.  I have a tool that does this, but it would be cool if this functionality could be added or built into the regular mrverify.exe tool.  Options for my tool are "vertool path [/s] [/a]".  The /s is recurse subdirs and the /a means ignore the archive bit and verify all images.  If /s if not specified, it only does "path" and no subdirs, if /a is not specified it only verifies images with the archive bit set.


jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (6.1K reputation)Macrium Evangelist (6.1K reputation)Macrium Evangelist (6.1K reputation)Macrium Evangelist (6.1K reputation)Macrium Evangelist (6.1K reputation)Macrium Evangelist (6.1K reputation)Macrium Evangelist (6.1K reputation)Macrium Evangelist (6.1K reputation)Macrium Evangelist (6.1K reputation)
Group: Forum Members
Posts: 4.2K, Visits: 30K
Can't answer your main questions, but fyi if you want to allow your script to delete images, you won't be able to use Macrium Image Guardian, so if you decide you're willing to give that up in order to maintain your existing setup, make sure you permanently disable that (or don't install it in the first place). 

You might also be interested in some of the discussions that have occurred around here recently about verification.  In short, if you're initially capturing the image locally, you would be especially unlikely to ever see a verification failure; the (relatively) greater risk is actually copying the file to a remote location, which is why it would actually make more sense to verify the image from its permanent location, even if that's slower.  But "more sense" is to the extent that verification makes any sense at all, which again has been discussed quite a bit, thanks in part to insight from Macrium themselves.  The only scenario I've seen suggested where verification can add value would be as an early warning system for a destination storage device (or its cable) that has gone bad -- but in that case, chances are you'd see corruption in any other files you tried to store there, and obviously you're not verifying all of your regular file copies.  Other than that, in case you're unaware, verification does NOT check the image contents against the original source data to confirm that everything was backed up accurately; it simply confirms that the image file itself is completely readable and does not have any internal corruption that would render it unusable.  But of course a successful verification immediately after a file is created is absolutely no guarantee that the image will still be intact whenever you need to restore something from it.  Additionally, if you're verifying an Inc or Diff backup, the verification routine also only verifies that one image file, NOT all of the parent backups in the chain that would also have to be intact in order to restore it.  This is why I skip verification in favor of frequent backups to a daily disk rotation, the latter of which brings other benefits.  I personally believe that even Macrium doesn't see much value in verification.  Their KB article about it says they estimate less than 1 in 1000 systems (not backups) will ever see a verification failure, and the verification option wasn't even added until Reflect V6, which suggests to me that it was added only due to satisfy customer demand and eliminate a perceived competitive disadvantage, and NOT because it was actually considered technologically important.  Sometimes it's easier to appease the masses rather than educate them.

Just some food for thought.

Edited 29 September 2018 12:51 AM by jphughan
alank2
alank2
New Member
New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)
Group: Forum Members
Posts: 7, Visits: 18
Thanks for the very technical and excellent/informative reply!  I was not aware of Guaradian, but was aware of the other things.  I know it doesn't check against the source data again, but is merely making sure the image is usable.  I actually like that when verifying an incremental/differential that is only does that image and not all that it is based on (though i did see an option in their verify tool that does this).  I do see your point about how valuable a verification is, but I've got a server storing the data that has CPU cycles it can throw at it so it won't hurt!  Obviously periodic testing by mounting/restoring images never hurts either!

A funny thing is I had an older notebook that wouldn't verify images when i was first evaluating Macrium.  It only happened in the PE environment, not with the OS up and running.  It turned out to be bad memory in the notebook!  Oddly, the notebook was running very stable under the OS (x86, 4G, 3G usable) and I can only assume that the OS didn't use the part of memory that was bad and the PE did.  memtest showed the error right off and replacing the stick of memory fixed the problem in PE/Macrium.

alank2
alank2
New Member
New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)
Group: Forum Members
Posts: 7, Visits: 18
While I am at it; I do have to commend the guys who wrote Macrium, it has a much smaller footprint than the imaging solution I've used for years that has bloated substantially.  I like that Macrium gets the job done with the least amount of complication.

Edited 7 June 2018 4:24 PM by alank2
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search