"Cannot read the log file" error in email notification

Andrew, welcome to these public User Forums.

Have you tried making a new small backup task, i.e. of a small folder, to test if that shows the same error about not reading the log files?

Steve, thanks for the welcome and for the suggestion.

I created a new small backup and ran it and the email contained the log with no error.

So it's just the tweaked backup that has the problem. The tweaked backup just seemed to forget its passwords (both for the NAS and for the log file) after the tweak.

Any more suggestions?

Andrew, difficult to say why the one backup task has an issue but others don't but it won't be the first time users have hit a corrupted task script.

You could take the option to just delete the problem task settings from the ATI GUI, leaving the backup files alone.  Take the Delete option but do not click on 'delete everything'.

Once the task has been removed, use the option to the right of the 'Add backup' behind the caret to 'Add existing backup' and navigate to your backup destination then select the most recent backup file to add.

The backup will be added back to the GUI using the file name of the .tib you selected, so you can then edit that name to take off the extra _inc_ etc characters.  You will need to click on the Reconfigure button which is in place of the normal Backup now button.  Set your backup source, destination and all other options, including the change you were wanting to make at the start of this saga.  Hopefully, when this new / reconfigured backup task runs, the error for the log will be a distant memory!

Steve, thanks for the further advice. I understand the logic of your approach of deleting and recreating the task.

Is using the "Save as default" checkbox at the bottom of most of the option screens a reliable way of speeding up the recreation of the backup task? Also will there be an issue recreating the backup task given that the current task (and options) are protected/encrypted with AES256/password?

As you can probably tell I'm just a little nervous about deleting the existing (mostly working) task and not being able to recreate it successfully. Is it possible to create the new task first, temporarily de-schedule the existing task and see if the new one runs successfully before deleting the existing one? Or is there a problem with two tasks pointing to the same backup files?

Is using the "Save as default" checkbox at the bottom of most of the option screens a reliable way of speeding up the recreation of the backup task? Also will there be an issue recreating the backup task given that the current task (and options) are protected/encrypted with AES256/password?

'Save as default' only seems to apply to new backup tasks of the exact same type, and the saved default settings are lost if you create a new backup task of a different type (backup scheme).

With regards to the password encryption, there should be no issue provided you know what that password key is.  There is no recovery for lost passwords used to encrypt backup files.

Is it possible to create the new task first, temporarily de-schedule the existing task and see if the new one runs successfully before deleting the existing one? Or is there a problem with two tasks pointing to the same backup files?

No, if you attempt to use the option to 'Add existing backup' when the original task still exists in the ATI GUI, it will just keep the current task association with those files, not create a new task.

Steve, thanks again for you clear and precise advice. I was about to undertake the transition to a new backup task, but had a quick look in my emails this morning for the results of last night's backup. I've made no changes to the configuration but it was able to find and display the log in the email - very strange. So everything appears to be back to normal, the job runs, the email shows the log and the post-processing command that I added to the job executes.

I can't explain why it suddenly started working again given that I've made no changes to any part of the configuration. The only thing that I can see as a clue is that it's been not working for exactly one week so maybe something just kicked back in after a week - but that's more than a little tenuous.

So all seems to be fine now, but your advice I'm sure will be useful for me in the future or for others with similar problems.

Thanks

Hmmm. I think I was a little premature with my "so all seems to be fine now". Last night's backup was back to "Description : Cannot read the log file". I'll keep an eye on this and see if it sorts its self out or whether I need to replace the backup task.

Things got worse. So I followed Steve's advice and completely recreated the backup job. But this job soon forgot passwords and other things. So as a last resort I upgraded to ATI2020. This didn't cure the problem.

A little more forum searching revealed the problem to be a known bug:

https://forum.acronis.com/comment/518472#thread-top

Bug number TI-180184.

The clue was that the original problem I had started on 23 October 2019 which is when this bug started.

I'm awaiting a workaround and a fix from Acronis for the bug.

I'm obviously not happy given the seriousness of the bug and the breadth of users impacted that two weeks later there is not even a workaround from Acronis let alone a fix. And also no communication from them to users who they must know are significantly impacted.

Andrew, your encounter with this known bug is slightly different to other users including myself who have hit it.  I haven't seen any other reports of the password for an encrypted backup being lost but this may simply be that most users do not use that protection feature.  That certainly applies to my own local / NAS backups where I do not encrypt them, but I do encrypt for backups to the Acronis Cloud and didn't see any password loss for those tasks?

The latest updates in the linked ATI 2020 Forum topic for this bug looks to suggest that Acronis know that this was caused by an update on their side in the Cloud servers handling the Dashboard feature, so now we need assurance that they have fixed this and will take measures to ensure it never happens again!