Validate Following Backup?

I think there's room for improvement on validation processes or methods by softs makers according Peter's findings/experience.

 

Macrium has added the viBOOT feature in v7 (W10pro and above) that allows the user to BOOT an image into a virtual System to check it out for integrity... of some use to some, I'm sure.

 

Great! I use Image for Linux, dunno if they have anything similar or they're in process of developing something.

 

I still don't get the reasons for not validating a backup.
It does not take your time, just CPU time, as it can be done automatically. If validation fails, you are given a chance to make a new backup.

True, you also validate a backup when you restore it or mount it in a virtual machine.
But--unless you check that *manually* immediately after each and every backup, and that would take your time not just CPU's--if you restore the backup later (usually done when you really need it) it might be too late.

 

Even if validation doesn't find any problem it doesn't mean that backup is OK and that there will be no problem while restoring.
Personally I let Macrium to verify images but to be sure I sometimes restore image to VHD and mount it in VM to see if system works OK.

 

Agreed, automatic validation should not give a false sense of security and should not prevent you from taking extra steps.
But, like you said, you check restores "sometimes", while automatic validation does it *always*.

 

Again, an opportunity for vendors to offer a better validation method which not takes your time, just machine's time.

 

Folks talk of images that VERIFY but do not work. Many of these are caused by a faulty FileSystem on the machine being imaged. To my knowledge, Reflect is the only imaging application that actually performs a kind of mini (optional) FileSystem CHECK (ie ChkDsk) prior to imaging to insure that at least that part of the image is solid before actually wasting the time to do the image.

 

I have actually experienced the above Reflect FileSystem Check failure twice since January 2015. In both cases the image was aborted automatically by Reflect, followed by my running of "ChkDsk /f" which in both cases detected an anomaly in the FileSystem and repaired such. I have no idea what caused the anomalies but was pleasantly surprised to see REFLECT take an active role in checking my FileSystem. Either one of those FileSystem failures may have resulted in an unBOOTable System if I had chosen to use those snapshots.

 

@TheRollbackFrog
If unattended backups are created daily and Macrium finds problem when verifying, how does a user know that problem occurred while he was away? Do you get any message or notification?

 

I never validate backups for the sake of validation. The restores I do just work, as they should with a good quality imaging software. The day a restore fails I´ll loose confidence in the imaging software and will shift.
But I guess every restore I do is a validation.
I restore my hard drive maybe once a month when something goes wrong, or I just feel something maybe have gone wrong.

 

The LOG file for that image will be marked in error and the error will be documented in that LOG. The user needs to check those LOGs to determine if the images taken are error free.

 

Thanks.
Another job - check Macrium log files for errors

 

You can set an email address in Macrium Reflect's settings to be notified in case of a failed backup.

 

Quite drastic in my opinion. What if Terabyte Unlimited or Paramount Software with long success backgrounds induce an unfortunate regression?
Certainly I would not ditch one or both.

 

Yep, @Peter2150 = "folks"

Actually, Peter brings up a good point. His experience with "verification" was with another imaging application and turned out to be a programming error. Since each product's "offered" VERIFICATION option may differ drastically in how they're actually verifying the operation, the term VERIFICATION has many different meanings. It's good to ask the question exactly how the verification is being done for any product offering that option, just so you understand any limitations involved.

 

Thanks guys all of you. This thread is enlightening me as I had current validation operation for granted.

 

What would you actually do... continue with a known anomaly in one of your most important System applications, possibly producing bogus backup images which you rely very heavily on?

Vendors in this arena must be consistent in their product evolution, especially once they've arrived at that nirvana. Mistakes are not easily excused, especially if they are in the image structure itself. The product testing better be up to snuff to insure this or the Development Group may lose the support of the product's users.

Sure, you can love a company and forgive them if you feel it's necessary... but that damn imaging product better work and work well. Reliability is the only basis I have to insure that "love" remains.

 

A backup can wrong for a number of reasons not depending on the imaging software quality.

As to "validating" the image "when something goes wrong" in your hard drive, it's like checking if your spare wheel is OK *after* getting a flat tire!

 

No I wouldn't yet I can go step back to previous version. Inform the company and wait for a new fixed version. That's definitely what I'do. If they "consistently" keep failing every major version or few intermediate minor version, that's another story and yes I'd ditch that product. /end-offtopic

 

Personally I always validate. It helps not so much in verify that the archive/image is intact (imaging programs have matured enough since the late 90s) as it helps to identify bad ram modules or problematic disks.
I've seen bad ram modules that would always pass successfully test apps like MemTest86, but randomly failed with image's validations.

Panagiotis