Skip to main content

Validation query

Thread needs solution

Windows 10 64 bit. MBR system. ATI build 6571 (current)

I use recovery boot flash for image since I can't stand how it works in Windows. (ATI v10 and 11 were so much simpler and better!)

I think I see a pattern but would like someone to confirm:

When I make an image and select all of my four partition (System_drv which is 1.4gig booting thing, Windows 7, Windows 10, and a data partition), validation succeeds.

But when I make an image of just three partitions, skipping the data partition, validation fails but the screen says it's "corrupted but you can still recover data from it".

I had no problem recovering Win10 from the 3-partition image. So I'm thinking the info on that system_drv or MBR or something might be playing a role in the funny validation result.

Any comments?

 

0 Users found this helpful

256egd, when booting from the flash media with the Acronis Rescue software you will still get an option to look at the Logs for the task that is giving you this message and there should also be an option to save the log file too.

The log should be able to give more information on what Acronis is seeing that generates the 'corrupted' message.

Would perhaps be interesting to compare the logs from the two scenarios, i.e. with 4 partitions selected which validates OK, and with 3 partitions when it reports corrupted?

I'm retracting my theory. I had a all partition image fail validation recently. Might be because I used a hub. Failed to save the log which really told me nothing.
Here's one log from just 2 partition image which failed. Perhaps it clarifies something but not to me.

Attachment Size
395247-134206.log 2.04 KB

Thanks for the log file, unfortunately as I am sure you have already seen, it doesn't really add any value to understanding why ATIH considers that the backup archive is corrupted.

Perhaps a stray thought but have you tried using a very simple backup file name without extra / special characters included, i.e. instead of First1607-2016-09-24(sysDrv+w10)_full_b1_s1_v1-2.tib you could try using Backup1 and see if it makes any difference?

Further thought, seeing _full_b1_s1_v1-2.tib in the file name suggests that you already had an existing file with the same name in the target folder, hence the v1-2 convention in the file name.  See the ATIH 2016 User Guide: Backup file naming where it states:

If you are creating a new backup, and there is already a file with the same name, the program does not delete the old file, but adds to the new file the "-number" suffix, for example, my_documents_inc_b2_s2_v1-2.tib.

Steve,
Re: name them simpler - well, for years I've used this sort of naming, and hate to change my ways. And since validation is so flaky it'll be hard to be sure why it worked or why it didn't. Might do it in my spare time.
Re: "-2" in the filename - don't laugh too hard please - it was my error of sorts. I intended to make differential, but didn't check "Add". So when I clicked Options after selecting the full image path, Acronis warned that it'll erase that image. Ooops! Not being sure what was going on, and go back wasn't available, I added "-2" after deciding Acronis was wrong. I said go ahead, do whatever you want. What resulted was a second full image slightly larger than the first. And the original stayed behind, hurray!. So that's my long story.