please add INDEX check to Validate to actually validate the backup
There are very many posts here about "index corrupted" errors when trying to restore a complete backup over many years and many version.
This happened to me last week where ALL my backups were corrupt. None could be used for a full DISK restore, so I had to reinstall Windows and all my software, losing HOURS of work time, still not fully working machine. We need to be able to do a disk restore and walk away. Validate doesn't seem to validate much.
FEATURE REQUEST:
Here's a seemingly obvious fix by the developers in the right direction for the validate:
Only when I tried TI 2019, did I get an immediate "index corrupted" error when I tried to restore, before being able to select a destination drive. Older versions just tried to restore disk, failed or said it completed, but the disk was empty.
SO... please add whatever check is done in 2019 version, that gives the "index corrupted" message... WHEN WE RUN VALIDATE! It ought to be in the "verify" after backup as well. At least as a check option.
Done. Fixed. At least we know soon if we've been making corrupted backups for months or years.
Thank you!!!!
Thanks @Enchantech
Seems like an obvious & quick programming addition. Use the same code. What a disaster to find every backup is corrupt & not be able to restore anything.
Sometimes things that seem obvious to users are missed by designers and developers. That's why the Feedback is so valuable. Mentioning something on this forum and having it recognized by MVPs is also very valuable, but it doesn't count as feedback - it doesn't get the issue on the official list of requests.
I tried to post to feedback but Google's captcha is horribly broken and I can 't leave the comment.
it is a good way to keep feedback from being submitted.
Erol, if you use the Feedback app within the installed ATI program on your computer, there is no Captcha involved.
Click on the (?) icon in the lower left corner to get to the Feedback tool.
Hello Erol,
I'm very sorry to know that you've faced such issues during recovery. Discussed the topic with the product team: according to me colleagues, the message Index is corrupted refers to the issues with NTFS either on the source or on the target drive. Technically, we can add a respective check to the validation job, but this will cause significant increase in times. The product team will consider this based on the results of their research. As the workaround to avoid such situations, we suggest regularly checking source and target for errors.
Ekaterina,
Everything I say below assumes the "index corrupted" error refers to the drive/partition containing the .tib files. If it refers to the target of a restore then there is no problem for Acronis to fix (except perhaps an unclear error message). But assuming this error refers to the backup medium, ...
I think the argument given by your colleagues doesn't correspond well to the problem reported by Erol. They said.
we can add a respective check to the validation job, but this will cause significant increase in times
But Erol said
I get an immediate "index corrupted" error when I tried to restore, before being able to select a destination drive
Assuming his description is correct, either the corruption he experienced was right at the beginning or the check needed to test for this corruption does not take much time.
But more importantly, the current validation process is inaccurate (and very misleading) if it declares a backup good when, in fact, the backup cannot be used by the restore process. Perhaps there needs to be two user-selectable levels of validation: the current one and a more in-depth one that checks for index errors.
we suggest regularly checking source and target for errors
This is, of course, a wise suggestion but I know I don't do this and I suspect very few ATI users do. I suspect very few ATI users would have any idea how to do it. I don't. (Does CHKDSK check for NTFS index errors? I don't know. Is there some other disk-checking utility? I don't know.)
One comment from me on this issue. CHKDSK is only good for partitions already allocated a drive letter, so this cannot be used for hidden/system partitions included in the ATI backup source, thus making this task more difficult for users who don't have some knowledge of how to assign drive letters etc.
Thank you very much for the reply Ekaterina!
Yes, I get that there may have been some NTSF error on the drive that was backed up and thus all backups made of the drive we're corrupt. The point then is... we must have some way of knowing as running a disk restore is the only way to truly test this.
This is a massive undertaking in time! Imagine pluggin in a same-size hard drive & manually running a disk restore on every machine, maybe every week? We're talking hours lost, not minutes.
More specifically: significant increase?
The current validation process is not instantaneous. Are we talking about doubling the time to do this new integrity check? So maybe we check a box and every evening this extra check is done automatically while we eat dinner, with no cost to us in time? (I already have the validate done and it costs me no time.)
Thanks again and please do pass this on to management. :) I used to be a programmer and know programmers tend to push back while management gets the value to customers and can put features in the budget.
Ekaterina Surkova wrote:Hello Erol,
I'm very sorry to know that you've faced such issues during recovery. Discussed the topic with the product team: according to me colleagues, the message Index is corrupted refers to the issues with NTFS either on the source or on the target drive. Technically, we can add a respective check to the validation job, but this will cause significant increase in times. The product team will consider this based on the results of their research. As the workaround to avoid such situations, we suggest regularly checking source and target for errors.
Apparently this is still not fixed in 2020. ATI happily makes backups that can't be restored and if I check with Validate it says they are fine. If I try to mount the backup it fails so I can't use Chkdsk. Essentially what Acronis is providing is a backup system that only works with an error free disk and doesn't tell me when it is writing into a black hole from which I can never restore. Why is it that every time I need to restore I find another reason why I can't.
Last time it was that if I didn't have the full chain of differential backups it won't restore the most recent differential. Now with the tibx format changes I've lost the ability to copy files off the backup.
Really, the only time in over a year that I have been able to recover a bootable disk was in the testing I did before I bought the product.
Hello Everyone,
I've registered your feedback as votes for the feature request (internal ID for ref TI-201473 Implement "Check file system before backup" option), so that the product management can consider future changes.