Skip to main content

Daily backup of files have been failing

Thread needs solution

I just noticed that a daily backup task has been failing since Dec 5.  (I obviously should have checked sooner.)

The error message in the log entriy complains about a target file that does not, and should not exist:

Error 0x1e50023: Cannot access the path: F:\Acronis test\Networked Files_inc_b40_s3_v13.tib

My F: drive is my target for local (non-NAS) backups.  It does not have a directory named "Acronis test" (although I may have created one for a test at some point).  The destination for the failing backup should be "F:\My Backups\".  Somehow the backup script's "volume location" list has one line with the "Acronis test" directory.  I could just edit that line, but I have no idea what to use for "volume_id".

Is there anything I can do short of deleting the existing back up task and doing an "Add existing back"?

 

0 Users found this helpful

Patrick, rather than editing the task script file, have you tried just reselecting the destination for the task in the main ATI GUI, and let ATI make any changes to the script?  This looks like another example of corruption creeping into the internal database.

That didn't help.  ATI updated the script but the line with tthe incorrect directory is still present (and the backup failed again).  I tried a Validate, too, but that also failed with the message that same error message

Error 0x1e50023: Cannot access the path: F:\Acronis test\Networked Files_inc_b40_s3_v13.tib

Ok, worth asking.  Next options are to either use 'clone settings' then check that the problem line in the script hasn't been transferred to the new task script, or else as you mentioned above, removing the task and adding back in again?  If cloning the settings cleans up the problem line, then you may be able to copy the change back to the original script file to see if that would resolve the issue?

The cloned task included only the model "F:\My Backups\Networked Files\@task@.tib".  I assume that is the same as any new task prior to taking the first backup.  My best bet is probably to delete the original task and start over with this new one.  I ran into permission problems when trying to mess with the script files so, while copying the new script back into the old one might work, it's probably not worth the effort.

Actually, it's doubly not worth the effort because the the corrupted task has other problems.  The last good backup ran with a Backup scheme specifying "Store no more than 5 recent version chains" but the task now has "Delete version chains older than 31 days".

Hmm.  Maybe I should just try changing that.  I vaguely remember that changing the backup scheme reset previous backup scheme information.  Maybe that will delete the incorrect information.

Nope.  That didn't help.

Update:
I've gone with the cloned task.  It started over with b1_s1 of course, but I can deal with that.

Sounds like a solution here Patrick!