Backup Failed. Event code: 0x0004000D+0x0004000D
My email report says the backup task failed. The ATI message says that the file is corrupted, and that the possible reason is that the media is corrupted. My backup drive shows no errors when I check it in properties->tools->Error Checking->Check. ATI Event code is 0x0004000D+0x0004000D. The Win10 event manager shows no disk errors, and the log is empty. ATI keeps trying to do the backup and keeps producing the same error report email. I have rebooted the PC with no change in behavior.
Anyone know what's going on? How to diagnose? How to fix?
Thanks for the reply, Steve.
Fixed signature. Using ATI 2020. Thanks for the heads up.
Backing up the whole computer except those items on the default exclude list. Backup files go to a USB drive. I've been backing up daily now for a long time with no issues of significance. The backup drive is nowhere near close to full. Not sure about your 'or' question.
Downloaded and ran the MVP Assistant tool OK. The backup creates .tib files so looking at the Demon logs.
Most recent log ends with the following:
10/7/2020 12:52:31:886 AM -07:00 23480 I0004000D: Error 0x4000d: The file is corrupted.
10/7/2020 09:55:52:442 PM -07:00 23480 E000101F6: Error 0x101f6: Operation is canceled.
10/7/2020 09:55:52:643 PM -07:00 23480 E013C0005: Error 0x13c0005: Operation has completed with errors.
What next?
Dave, can you post the whole original ti_demon log as a zipped file via the File Upload option so that I can see the context for the error message you are seeing please?
I would suggest creating an Acronis System Report zip file then extracting the disks.txt from that and posting that disks.txt file here too, as this will show if Acronis is seeing any file system issues with any of your drives?
Problem:
The server does not support the requested update rate.
Solution:
The server will use the closest available update rate. This message is simply a report back to the client application of the update rate that will be used. For example, the fastest update rate that is allowed by OPC is 10 milliseconds. If the update rate is set in the group to 5 milliseconds, it will change to 10 milliseconds and this will be reported back by the server.
Sorry but there is no server involved with the reported error message - the backup is to an external USB drive!
Here are the requested files:
Looks like I have to upload them within the 3 MB limit, so first one first, the complete ti_demon_...zip, then the disks.txt.
The SystemReport.zip is 21.195 MB.
Now I'll try the SystemReport.zip by itself to see if it will load.
Nope. It doesn't go. Any suggestions?
Never mind. I see that the only one you requested from this report is the disks.txt. So, done.
Dave, thanks for the ti_demon log and disks report. The log only shows the same as you have already reported, that the backup file is corrupted. The disks report shows no errors for any of your disks, so this isn't a filesystem type issue here.
Some further questions?
Has this same backup GRANDPAS-PC been running without issue for a while?
How many files are on the backup drive for this backup?
Is it an Incremental or Differential backup?
Have any files been deleted recently for this backup?
Is the backup drive connected to the same USB port as is normally used?
Have you tried making a new backup task of the same source data to the same target drive?
Q: Has this same backup GRANDPAS-PC been running without issue for a while?
A: Yes. But the issue has been the same for several days now.
Q: How many files are on the backup drive for this backup?
A: Not sure. When the issue showed up first, the BU drive still ha about 1.5TB of free space out of a total of 6TB. The rest of it was filled with BU files. I deleted two or three of the oldest BU sets just to see if it made a difference in the error response. It did not. Currently there are approximately 8 BU sets of about 15 files each for a total of about 120 files. Current free space is about 2.4TB.
Q: Is it an Incremental or Differential backup?
A: Incremental.
Q: Have any files been deleted recently for this backup?
A: Only as above described.
Q: Is the backup drive connected to the same USB port as is normally used?
A: Yes.
Q: Have you tried making a new backup task of the same source data to the same target drive?
A: Just now tried Single Version Scheme. Worked OK.
What do you make of that? What to do now?
I set it back to the original incremental to see what happens tonight at my regular BU time.
When the issue showed up first, the BU drive still ha about 1.5TB of free space out of a total of 6TB. The rest of it was filled with BU files. I deleted two or three of the oldest BU sets just to see if it made a difference in the error response. It did not. Currently there are approximately 8 BU sets of about 15 files each for a total of about 120 files. Current free space is about 2.4TB.
Dave, what method did you use to delete the oldest BU sets per above?
Did you use the Clean up versions tool for the backup task, or did you delete these via Explorer? The latter is not recommended as does not update the internal tracking database used by ATI whereas the former tool does.
Q: Dave, what method did you use to delete the oldest BU sets per above?
A: File Explorer. I've used that many times before without any issues. Also, keep in mind that I deleted the oldest BU sets after the issue showed up.
Steve: Did you use the Clean up versions tool for the backup task, or did you delete these via Explorer? The latter is not recommended as does not update the internal tracking database used by ATI whereas the former tool does.
Dave: Didn't know this. Thanks. My BU jobs are set to limit the number of BU sets to something that is, hopefully, less than the max capacity of the BU drive. Over the months, I've increased this parameter (currently set at 10) to gradually work up to the capacity of the drive. So, I was at the limit of 10 sets, maybe more, when the issue showed up.
Dave, if using automatic cleanup rules, then you always need to have enough free space to be able to create a further new full backup image successfully before the oldest backup chain will be deleted and give back more space.
Steve: Dave, if using automatic cleanup rules, then you always need to have enough free space to be able to create a further new full backup image successfully before the oldest backup chain will be deleted and give back more space.
Dave: ATI figures this out doesn't it?
Status on my BU functionality: Successful incremental backup this evening. Only issue was that I had to start it manually. It didn't start when I powered up the USB BU drive. I've seen that before. Don't know the cause. Typically, it kicks in correctly at power up on the second day. So, we'll see tomorrow evening.
Any clues as to the cause of the issue? Thanks for the suggestions, BTW.
Dave, the user has to ensure that there will be sufficient free space on the backup drive to allow automatic cleanup to run correctly.
For the backup to run when connecting a backup drive, you need to have configured that in the Schedule page settings.
Steve Smith wrote:Dave, the user has to ensure that there will be sufficient free space on the backup drive to allow automatic cleanup to run correctly.
For the backup to run when connecting a backup drive, you need to have configured that in the Schedule page settings.
Is there a tool that would help out to figure out how much free space to allow? Seems like it should be sufficient to leave enough for the last increment to store, and that can only be determined after ATI assembles the information to know just what to do.
Re the second comment, my scheduling page is configured to run when the BU drive connects. It was running successfully that way for many months before the problem came up.
Is there a tool that would help out to figure out how much free space to allow? Seems like it should be sufficient to leave enough for the last increment to store, and that can only be determined after ATI assembles the information to know just what to do.
Sorry, no tool! You need to run the task and see what the size of backup file(s) are at the point when you get to start the next new backup chain, then use that size to calculate how many such chains could be stored on your backup drive and set the value to one less! This assumes that you only have one backup task using that drive! If using it for multiple backups, then the calculation needs to accomodate all the files from all the tasks.
Re the second comment, my scheduling page is configured to run when the BU drive connects. It was running successfully that way for many months before the problem came up.
Difficult to say why anything should have changed in this respect if it was working correctly previously and the settings haven't changed? This might be a case of needing to delete the backup task and create a new task to replace it.
BU ran normally this evening. Turned on the USB drive, and ATI did the incremental, as it is supposed to do. I marked the thread as solved now.
What I'm seeing when I look at the BU sets and sizes is that my USB 6TB BU drive can support probably 11 sets. It's current set at 10, so I'm going to leave it at that and see what happens.
Now, the question is, if the number of BU sets is set too high, will ATI give me an intelligent diagnosis when it runs out of space? It should refuse to do the BU, and tell me that there's not enough space.
Steve re cause of original issue: This might be a case of needing to delete the backup task and create a new task to replace it.
Dave: Will going from the Single Version back to the stored incremental custom BU program/script be sufficient to do this?
Also, could the deletion of files using Explorer and the consequent error in the ATI tracking database still be there, or will the error self correct? Especially since the BU program has been changed twice now. Seems like the internal database should be regenerated each time maybe.
Now, the question is, if the number of BU sets is set too high, will ATI give me an intelligent diagnosis when it runs out of space? It should refuse to do the BU, and tell me that there's not enough space.
Quick answer is no! It will give an error when trying to write the next backup file because of insufficient free space!
Changing the type of backup scheme from Single version to Incremental shouldn't cause any issues as in essence all backups have to have a full backup to start with, but if you see any indication of issues, then would still suggest starting a new task with the new settings / scheme.
The only way to fully clean the database of any error entries related to files deleted outside of ATI is to force it to be rebuilt as per KB 60915: Acronis True Image: repairing program settings
It will give an error when trying to write the next backup file because of insufficient free space!
That's exactly the kind of response I would expect. That would tell me that I have to use the tool to delete one of the BU sets before attempting to backup again. After using the tool, and decrementing the number of sets (for the store no more than...) in the job definition, then it should work OK from then on. If not, then that indicates that I should clean the database as below.
The only way to fully clean the database of any error entries related to files deleted outside of ATI is to force it to be rebuilt as per KB 60915: Acronis True Image: repairing program settings
So, this is at least a plan. I looked over the methods above in KB 60915, and don't see any obvious one to be preferred. They are in order, pretty much, of the amount of work to do and amount of disruption of my system related work habits.
Thanks again for hanging in with me on this. Really appreciate it.