Aller au contenu principal

Status is "Operation has succeeded" when it actually failed

Thread needs solution

I have a number of backups that are listed as "Operation has succeeded", when in fact they are failed. I have TI setup to backup every weekend to a remote NAS and some weekends my laptop doesn't have access to the NAS. However, even when TI has no access to the NAS, the regularly scheduled backup is listed as "successful".

In the cases where the backup failed (but is listed as success), the log file contains a long list of:
- Error occured while writing the file
- Reattempting the operation.

After a number of those messages, the log file ends with:
- Cannot perform this operation in quiet mode. (0x103F1) Tag= 0x1D8EAB676A3F6B6F
- The following backups have been successfully created: "\\{my NAS system path}"
- Operation has succeeded

On weekends where my laptop has access to the NAS, everything is normal.

It's quite frustrating to not be sure when my last successful backup occurred. Also, it's unclear if my incremental backups are junk if TI thinks that failed backups were actually successful.

My build is 5551.

Thanks for the help,
Jason

0 Users found this helpful

Jason,

The notification message can be misleading sometimes, is it possible you have your tasks set up to email you after an operation? This will often result in an 'operation succeeded' message and a log file entry of task failure, the success being it completed the task by successfully emailing you.

That certainly happens with ABR products, so it may well do so with TI as well.

Colin,
I don't have TI set to email me afterwards, so I don't think that is the problem.

A further search of other forum topics yield the following entries (for previous versions of TI):
http://forum.acronis.com/forum/24743

This is a dead thread with no resolution, however it appears to have been the exact same problem.

Last night to check on the integrity of my backups, I ran the validation step. After taking 6 hours, it reports everything is ok. However, when I try to restore, the "Version" list box in the "Disk Recovery" dialog window has no pulldown versions to select (see attached screenshot). Now I'm *really* worried that the last 6 months of backup are junk.

thanks,
Jason

Fichier attaché Taille
122545-105928.jpg 173.3 Ko

Alright, I think I figured it out. If, in the middle of a backup, you have bad communications to the destination disk, TI will flag an error in the logfile but it will still complete with "Operation Succeeded". Additionally, if you are doing incremental backups and you have this issue, it can do nasty things to your ability to recover the data.

That's the simple summary. Here are the gory details:
- My NAS currently has some timeout issues when accessed via wireless. I haven't been able to resolve them yet, but the net effect is that if you try to access the NAS for a long period of time via wireless communication, it will drop the connection. If you access with a wired tether, no problem.
- Being aware of this problem, I try really hard to remember to tether my laptop every Saturday night so that my backup goes thru okay.
- The weekend just after Christmas, I forgot to tether my laptop and left it connected via wireless. The incremental backup log file has a ton of "Error occurred while writing the file", and it wrote 10 separate {inc}.tib files to the NAS (usually only writes one). However, the final conclusion of the log file is that "Operation succeeded"
- The following weekend, I again forgot to tether my laptop (holiday hangover, I think). TI2013 tried to do a "full" backup (despite my settings being for incremental). I *believe* this was because the previous weekend's incremental backup was junk (even tho the final conclusion of the log file was success). However, because I was still wireless, it again had a ton of "Error occurred while writing the file", and it wrote 5 separate {full}.tib files. Again, the final conclusion of the log file is that "Operation succeeded"
- The following weekend, I finally remembered to tether my laptop. Again, TI2013 did a "full" backup--because the previous weekend's backup was still junk. This time everything was fine (no errors writing the file, only a single file was created).
- The following weekend, TI2013 did an incremental backup (since the previous weekend's run was okay). I again forgot to tether, so that run was junk, but we already know that will happen when untethered.
- Yesterday, I tethered the laptop and manally requested a backup. This time it did another full backup, because the previous incremental was junk.
- On recovery attempts, here is the problem: the files that were created during the weekends when my laptop was untethered are junk. If you use the TI2013 "Recovery" dialog window, it will get stuck on those corrupted files and not report any versions available for backup. The only way I've found to recover is to go to a .tib file that is known to be good, and right-clicking into the recovery option under TrueImage. I believe that that I can somehow manually delete the bad files from my backup area and get TI2013 to recognize everything--but I haven't had the chance yet to play with that.

So I'd guess that there are two fairly sizable bugs in TI:
- If communications with the destination disk is lost/flakey during the backup, the backup file may be corrupted and fail but the final status of the backup session will be listed as "successful"
- If one of the files in a string of backups is corrupted, it will prevent the recovery dialog window from seeing *any* of the backup versions (even successful backups)

If anyone has any suggestions on the procedure to clean up/remove corrupted files in a chain of backups, I'd love to hear them. I'll probably get around to trying to clean this up tonight or tomorrow and it'd be great to have an idea of how to do it ahead of time.

If the damaged archives show up after a 'search' for images has occured, use True Image to delete them by right clicking on the selected image list and selecting delete. If TI ignores them, you can delete them manually by hand via your file manager.

I believe that the log file summary line indicating success when operations have failed is an issue that Acronis is aware of and is looking into. It's not unique to the situation/condition that you have reported.