Backup Fails Intermittently with | error 0x4000d: The file is corrupted.

Windows 10 Pro, ATI 20202 Build 25700
I recently installed a new Sysnology DS218+ NAS with twin mirrored Seagate IronWolf 6TB drives. The NAS is working flawlessly throughout all types of disk activity.
Given my past history with ATI, rather than try to reconfigure my existing backup tasks to now reference the NAS, I deleted all my ATI tasks and archives and completely redefined them. All tasks are defined using the Single Version scheme
Unfortunately, intermittently, the backups fail with ATI claiming the backups are corrupted.
This backup task completed normally the prior 3 nights but failed last night.
Here are last night's backup archive files
Here is the opened archive showing the successful backup from the prior cycle
It appears to have successfully accessed the disk last night but failed when starting to write.
Here is the log-
2020-07-08T01:30:00:670-07:00 9320 I00000000: -----
2020-07-08T01:30:00:671-07:00 9320 I00000000: ATI Demon started. Version: 24.6.1.25700.
2020-07-08T01:30:01:014-07:00 9320 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
2020-07-08T01:30:01:018-07:00 9320 I00640002: Operation SPChris-BakC started by schedule.
2020-07-08T01:30:01:154-07:00 9320 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
2020-07-08T01:30:01:160-07:00 9320 I013C0000: Operation: Backup
2020-07-08T01:30:01:171-07:00 9320 I0064000B: Priority changed to High.
2020-07-08T01:30:14:554-07:00 9320 E02160015: Error 0x2160015: A backup error.
| trace level: error
| line: 0xa340ffd3416335cf
| file: c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\da_api\backup.cpp:353
| function: da_backup::Commit
| line: 0xa340ffd3416335cf, c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\da_api\backup.cpp:353, da_backup::Commit
| $module: disk_backup_vs_650
|
| error 0x4000d: The file is corrupted.
| line: 0x8af64b2c0920f7ed
| file: c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\resizer\archive3\archive3_error.cpp:175
| function: `anonymous-namespace'::ConvertArchive3Error
| line: 0x8af64b2c0920f7ed, c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\resizer\archive3\archive3_error.cpp:175, `anonymous-namespace'::ConvertArchive3Error
| $module: disk_backup_vs_650
|
| error 0x29b138b: Data is corrupted: CRC mismatch or internal data structures mismatch
| line: 0x1c981e20c1c9f17f
| file: c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\resizer\archive3\backup.cpp:473
| function: resizer::Archive3ImageBuilder::CommitBackup::::operator ()
| line: 0x1c981e20c1c9f17f, c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\resizer\archive3\backup.cpp:473, resizer::Archive3ImageBuilder::CommitBackup::::operator ()
| function: archive_slice_start_chain
| path: \\?\UNC\192.168.2.193\Backup\Vault\Acronis\SPChris\BakC\/SPChris-BakC.tibx
| $module: disk_backup_vs_650
2020-07-08T01:30:14:863-07:00 9320 E013C0005: Error 0x13c0005: Operation has completed with errors.
| trace level: error
| line: 0x9f2c53c72e8bced8
| file: c:\bs_hudson\workspace\123\products\imager\demon\main.cpp:738
| function: main
| line: 0x9f2c53c72e8bced8, c:\bs_hudson\workspace\123\products\imager\demon\main.cpp:738, main
| $module: ti_demon_vs_25700


- Se connecter pour poster des commentaires

Had to set this aside and now returning as the error above continues to present.
In response to Steve's question above, the disk.txt file shows no errors.
More info-
- My backup scheme is set to "Single Version"
- My backups run every night via 3 backup Tasks
- They are set to run 3 times a week as follows
- BakA: Tues-Thurs-Sat
- BakB: Wed-Sun
- BakC: Mon-Fri
- Each write to a separate folder
After successfully creating the first backup, it will fail trying to create the next backup and render the first backup corrupted.
*
Another problem that may be related-
I have another machine backing up to the same NAS drive but at a different time. It has the same settings and login credentials and usually completes successfully, but occasionally fails with the same error.
However, despite a single version scheme, it never deletes the old backups
*
A different backup task failed last night with the same Demon Log error as shown above. Below is the related Volume Tracker log. Note the error when trying to create the file. (why the Chinese characters?)
8/4/2020 12:30:15 AM: [VolumeTracker][T] build: 2279, process: 8564, 'C:\Program Files (x86)\Common Files\Acronis\Home\backup_worker.exe'
8/4/2020 12:30:15 AM: [VolumeTracker][T] 2020.08.04 07:30:15 UTC
8/4/2020 12:30:15 AM: [VolumeTracker][T] 2020.08.04 00:30:15 LOCAL
8/4/2020 12:30:15 AM: [VolumeTracker][T] Control device '\\.\Global\VolumeTrackerControl2279' handle=7308
8/4/2020 12:30:15 AM: [VolumeTracker][T] Passed ...
8/4/2020 12:30:15 AM: [VolumeTracker][T] session=\Device\HarddiskVolume3 volume=C: granularity=65536
8/4/2020 12:30:15 AM: [VolumeTracker][E] : Error 0xfff0: Cannot create a file when that file already exists
| line: 0x23ddb6f9e25d0e52
| file: k:\2279\kernel\win\volume_tracker\dll\driver_api.cpp:228
| function: Kernel::VolumeTracker::Dll::DefaultDriverApi::CreateSession
| code: 0x800700b7
| $module: volume_tracker_driver_api_vs_s_2279
8/4/2020 12:30:15 AM: [VolumeTracker][T] session=\Device\HarddiskVolume3
8/4/2020 12:30:15 AM: [VolumeTracker][T] state=1
8/4/2020 12:30:15 AM: [VolumeTracker][T] session=\Device\HarddiskVolume3 checkpoint=C映敲穥佥䱮捯k氠湩呫偯潲散獳
8/4/2020 12:30:15 AM: [VolumeTracker][T] session=\Device\HarddiskVolume4 volume=\\?\Volume{bf24f3e1-f853-4740-86d4-38beab488d3c}\ granularity=65536
8/4/2020 12:30:15 AM: [VolumeTracker][E] : Error 0xfff0: Cannot create a file when that file already exists
| line: 0x23ddb6f9e25d0e52
| file: k:\2279\kernel\win\volume_tracker\dll\driver_api.cpp:228
| function: Kernel::VolumeTracker::Dll::DefaultDriverApi::CreateSession
| code: 0x800700b7
| $module: volume_tracker_driver_api_vs_s_2279
8/4/2020 12:30:15 AM: [VolumeTracker][T] session=\Device\HarddiskVolume4
8/4/2020 12:30:15 AM: [VolumeTracker][T] state=1
8/4/2020 12:30:15 AM: [VolumeTracker][T] session=\Device\HarddiskVolume4 checkpoint=A䬀牥敮㩬嘺汯浵呥慲正牥㨺汄㩬䐺晥畡瑬牄癩牥灁㩩縺敄慦汵䑴楲敶䅲楰欀尺㈲㤷歜牥敮屬楷屮潶畬敭瑟慲正牥摜汬摜楲敶彲灡灣p氠湩呫偯潲散獳
8/4/2020 12:30:16 AM: [VolumeTracker][T] session=\Device\HarddiskVolume4 checkpoint=AD4AE5A5-DC1D-4907-A58D-2EA575BFA28D
8/4/2020 12:30:22 AM: [VolumeTracker][T] session=\Device\HarddiskVolume3 checkpoint=CF54D7B1-66D2-456D-8870-DD6A00BC25D6
8/4/2020 12:31:50 AM: [VolumeTracker][T] session=\Device\HarddiskVolume3 checkpoint=CF54D7B1-66D2-456D-8870-DD6A00BC25D6
8/4/2020 12:31:50 AM: [VolumeTracker][T] session=\Device\HarddiskVolume4 checkpoint=AD4AE5A5-DC1D-4907-A58D-2EA575BFA28D
Start: 8/4/2020 12:30:15 AM
Stop: 8/4/2020 12:31:50 AM
Total Time: 00:01:35
- Se connecter pour poster des commentaires

The log above looks to be a volume tracker log not either ti_demon or backup_worker and these logs do show strange characters.
Ideally, looking at the system report covering this issue would be best so that all logs can be seen in context to try to understand what is happening.
In the interim, can you test the same backup task but to a local / external backup drive to see if the issue only occurs when using the NAS as the destination or is common to any backup location? Please use a new task rather than change the existing one for the testing.
- Se connecter pour poster des commentaires

Is there a resolution for this? The workarounds are not acceptable.
You shouldn't have to re-install your product every time the backup fails with this error.
I created a new backup plan last time. It worked for about 2 months then I get the same error on the backup.
Shouldn't have to re-create a new backup plan every time it fails.
There are no virtual machines to exclude.
The source and target drive are less than 6 months old. Backing up to a NAS box over a simple workgroup network. One machine. The PC Windows 10 and NAS box are brand new. Please advise the solution.
2021-02-24T14:00:00:225+11:00 612 I00000000: -----
2021-02-24T14:00:00:225+11:00 612 I00000000: ATI Demon started. Version: 25.6.1.35860.
2021-02-24T14:00:00:281+11:00 612 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
2021-02-24T14:00:00:281+11:00 612 I00640002: Operation OFFICE-PC2 started by schedule.
2021-02-24T14:00:03:730+11:00 612 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
2021-02-24T14:00:03:737+11:00 612 I013C0000: Operation: Backup
2021-02-24T14:00:03:750+11:00 612 I0064000B: Priority changed to Low.
2021-02-24T14:00:23:908+11:00 612 E00000000: Error 0x40007: Error occurred while opening the file.
| line: 0xf35f747b3b21fad4
| file: c:\jenkins_agent\workspace\ati-main-win\1173\core\file\windows\winnt_dir.cpp:971
| function: winnt_dir::OpenWin32Dir
| line: 0xf35f747b3b21fad4, c:\jenkins_agent\workspace\ati-main-win\1173\core\file\windows\winnt_dir.cpp:971, winnt_dir::OpenWin32Dir
| $module: ti_demon_vs_35860
2021-02-24T14:00:24:663+11:00 612 E0004000D: Error 0x4000d: The file is corrupted.
| trace level: error
| line: 0xaa33a143c434a602
| file: c:\jenkins_agent\workspace\ati-main-win\1173\home\backup_worker\impl\backup_worker.cpp:180
| function: `anonymous-namespace'::ReturnCodeToError
| line: 0xaa33a143c434a602, c:\jenkins_agent\workspace\ati-main-win\1173\home\backup_worker\impl\backup_worker.cpp:180, `anonymous-namespace'::ReturnCodeToError
| $module: ti_demon_vs_35860
|
| error 0x4000d: The file is corrupted.
| line: 0xc8d8731ce106f9ce
| file: c:\jenkins_agent\workspace\ati-main-win\1173\archive\ver3\adapter\error.cpp:64
| function: `anonymous-namespace'::ConvertArchive3Error
| line: 0xc8d8731ce106f9ce, c:\jenkins_agent\workspace\ati-main-win\1173\archive\ver3\adapter\error.cpp:64, `anonymous-namespace'::ConvertArchive3Error
| $module: archive3_adapter_vs_35860
2021-02-24T14:00:26:995+11:00 612 W00000000: Error 0x40007: Error occurred while opening the file.
| line: 0xf35f747b3b21fad4
| file: c:\jenkins_agent\workspace\ati-main-win\1173\core\file\windows\winnt_dir.cpp:971
| function: winnt_dir::OpenWin32Dir
| line: 0xf35f747b3b21fad4, c:\jenkins_agent\workspace\ati-main-win\1173\core\file\windows\winnt_dir.cpp:971, winnt_dir::OpenWin32Dir
| $module: ti_demon_vs_35860
2021-02-24T14:00:27:111+11:00 612 E013C0005: Error 0x13c0005: Operation has completed with errors.
| trace level: error
| line: 0x9f2c53c72e8bcedb
| file: c:\jenkins_agent\workspace\ati-main-win\1173\products\imager\demon\main.cpp:741
| function: main
| line: 0x9f2c53c72e8bcedb, c:\jenkins_agent\workspace\ati-main-win\1173\products\imager\demon\main.cpp:741, main
| $module: ti_demon_vs_35860
- Se connecter pour poster des commentaires

Sean, some initial comments:
First, ATI 2020 has been out of any support from Acronis since last September, 30 days after they released ATI 2021 to the general public, this despite the fact that they release a new build #35860 last week to fix some identified vulnerabilities.
The above means that there is very unlikely to be any fix for this issue coming from Acronis unless it could be proven to occur on ATI 2021 and further be proven to be caused by ATI and not by other factors happening within the backup environment.
Any solution here is therefore going to be in the realm of a work-around.
I and many other users, including the other MVP's are not seeing this type of issue - I do regular backups to my own Synology NAS across my home network using both wired & wireless connections and have not seen this.
There are several checks that you need to do for this issue:
- Check whether the backup files stored on your NAS are corrupt or not?
- Check the settings on your NAS for whether there are any maintenance tasks that run intermittently that could 'touch' the ATI backup files?
For check 1. you should be able to access the NAS storage location using Explorer then right click on one of the backup image files and take the option to Validate the backup file / chain from the Acronis menu offered.
For check 2. you need to work through your NAS settings. The reason I mention this check is simply because another user reported problems that eventually were proven to be cause by such NAS maintenance tasks that had me checking my own NAS looking in case I had enabled such options! I cannot remember exactly what was happening on the NAS other than it was some form of scheduled task that ran infrequently!
- Se connecter pour poster des commentaires

Thanks Steve,
I can confirm version is ATI 2021.
I can confirm the backup file is corrupt. Unable to validate file as it is corrupt.
I was unable to access the NAS network location for the backup from within Acronis but can access via explorer.
Cloned original backup settings and I can access the NAS backup location from within Acronis.
Will get back to you about the NAS settings but I am sure there is nothing running in the background that would interfere or touch the backup.
- Se connecter pour poster des commentaires

I can confirm, as suggested by @Steve Smith, that I have never had this problem with my Synology NAS.
Ian
- Se connecter pour poster des commentaires

Thanks Ian, I agree I an certain it's not the NAS as all previous backups have worked fine form months since initial setup. I am suspecting user error behind it. Let you know tomorrow after I get back from clients office.
- Se connecter pour poster des commentaires

Hello all,
I have a similar problem with my QNAP NAS. I have had this problem with ATI 2020 and 2021. After testing many options, I noticed that all backups become corrupt when the connection between my laptop and NAS suddenly is disrupted. I have tested this with two laptops, and very consistently, everything goes well until I turn off the router suddenly during a backup. I assume that when other causes for a disruption occur, the same problem develops.
I have True Image 2021 set up to create one full backup and 12 incremental backups. The program stores 6 sets of these on a NAS. The backups are stored in parts of 25 Gb. After 2 or more sets, all data becomes corrupt in the described event. Not just the last one but all sets. I once had 1 Tb of 5 or 6 backup sets completely useless after such an event. The data could not be restored, validated, and so forth.
I assume that the tibx format causes this. The tibx format places all backups in one file (until it has reached the selected capacity and then creates another). The tib file format uses one file per backup. Also, I assume that the tibx file format uses a kind of index file. At least it must be that this index file becomes corrupt beyond repair.
On the same hardware, I installed True image 2019 and did the same testing. Noting became corrupt. Even deleting the last backup file of the chain resulted in no problems. The program just created a new file. In my experience, the tib file format is much more robust and convenient than tibx.
Another thing you have to keep in mind is that the tibx file format requires all data sets to be copied in case you want to restore from a different hard disk. That is not required in the tib file format. You can copy just the set you need. For example, in my situation, I needed to copy 1 Tb of data when I used the tibx file format but only 150 Gb in the case of the tib file format. When you want to restore a backup, copy all files, not just the last ones or the set you need.
My question is if you can test if suddenly disconnecting the NAS and laptop results in corruption of the data? That would explain a lot.
Kindest regards,
Rob
- Se connecter pour poster des commentaires

Hi Rob,
Thanks for the input. Worryingly that sounds like the issue. I am certain the NAS was shutdown during a full backup process which resulted in the entire chain becoming corrupt.
- Se connecter pour poster des commentaires

There is a remote possibility that the problem can be resolved by attempting a cleanup; if you do not get an error when selecting clean up, delete the last backup, then try validating the last backup.
Ian
- Se connecter pour poster des commentaires

Remote possibility is right. It came to the point Acronis became unresponsive, frozen. I had to open task manager to end the App. Had to uninstall, delete all the backups and reinstall, start over.
- Se connecter pour poster des commentaires

Good evening,
Sean: I checked the NAS and I am sure it stayed up and running when the whole dataset became corrupt. Immediately when I did the test I looked at the NAS and opened shares that were mapped. Besides that, it is not a robust situation if all data becomes corrupt when the NAS suddenly is shut down like in a power outage. I would stress that not only the last backup is destroyed but all six previous sets also.
Allen: I did everything I could think of. The files cannot be validated whichever file in the chain you select to add. I once tried to copy all data to an external hard drive and manually tried to add the backups. Also, the program tells me that the file location cannot be accessed anymore (although it can in windows explorer). Deleting the last version I did not try but support sent men a message that I could get rid of the data because they also did not know how to resurrect it.
Have a great evening.
Kindest regards,
Rob
- Se connecter pour poster des commentaires

I also have the same problem for the backup and I don't know what to do here is the log. If anyone can help me to solve the problem.
2022-11-28T17:06:56:156+01:00 940 I00000000: -----
2022-11-28T17:06:56:156+01:00 940 I00000000: Acronis Cyber Protect Home Office Demon started. Version: 26.1.1.39703.
2022-11-28T17:06:56:199+01:00 940 I00640000: Attributs de la copie de réserve de la sauvegarde : format tib; need_reserve_backup_copy false;
2022-11-28T17:06:56:199+01:00 940 I00640002: Opération WI-BOI-D06 démarrée conformément à la planification.
2022-11-28T17:06:56:214+01:00 940 I00640000: Attributs de la copie de réserve de la sauvegarde : format tib; need_reserve_backup_copy false;
2022-11-28T17:06:56:214+01:00 940 I013C0000: Opération : Sauvegarde
2022-11-28T17:06:56:230+01:00 940 I0064000B: Priorité changée en Basse.
2022-11-28T17:07:21:908+01:00 940 E0004000D: Error 0x4000d: Le fichier est endommagé.
| niveau de suivi: erreur
| line: 0xaa33a143c434a607
| fichier:
| c:\jenkins_agent\workspace\ati-main-win-ati\417\home\backup_worker\imp
| l\backup_worker.cpp:185
| fonctionnalite: `anonymous-namespace'::ReturnCodeToError
| line: 0xaa33a143c434a607,
| c:\jenkins_agent\workspace\ati-main-win-ati\417\home\backup_worker\imp
| l\backup_worker.cpp:185, `anonymous-namespace'::ReturnCodeToError
| $module: ti_demon_vs_39703
|
| error 0x4000d: Le fichier est endommagé.
| line: 0xc8d8731ce106f9ce
| fichier:
| c:\jenkins_agent\workspace\ati-main-win-ati\417\archive\ver3\adapter\e
| rror.cpp:64
| fonctionnalite: `anonymous-namespace'::ConvertArchive3Error
| line: 0xc8d8731ce106f9ce,
| c:\jenkins_agent\workspace\ati-main-win-ati\417\archive\ver3\adapter\e
| rror.cpp:64, `anonymous-namespace'::ConvertArchive3Error
| $module: archive3_adapter_vs_39703
2022-11-28T17:07:21:987+01:00 940 E013C0005: Error 0x13c0005: Opération réalisée avec des erreurs.
| niveau de suivi: erreur
| line: 0x9f2c53c72e8bcedb
| fichier:
| c:\jenkins_agent\workspace\ati-main-win-ati\417\products\imager\demon\
| main.cpp:741
| fonctionnalite: main
| line: 0x9f2c53c72e8bcedb,
| c:\jenkins_agent\workspace\ati-main-win-ati\417\products\imager\demon\
| main.cpp:741, main
| $module: ti_demon_vs_39703
- Se connecter pour poster des commentaires

Hello Alain,
To be honest: for months, I have been trying to solve this error. I was supposed to get help for the best customer service had to offer, but they could not solve this. The problem is the new file system. When there is an error in the index, all backup sets became corrupt and unusable. Not only the latest set, but all backups created. This is an issue I encountered a few times per month and I could reproduce. Support told me that the problem was my hardware, but this turned out to be nonsense.
The solution was to go back to Acronis 2019. Since I use the tib file format, I have never encountered this problem any more (btw: with exactly the same hardware). I am using Acronis 2019 for almost a year now and not concerns at all.
So, this is the only solution I can offer that actually works.
Kindest regards,
Rob
- Se connecter pour poster des commentaires