Unable to add ATI 2020 tibx file to backup
I upgraded Acronis True Image Home to 2020 on Windows 10 PC in November 2019. It runs a differential backup to a Synology NAS where it has created nearly 300 tibx files. It recently sent me an email saying, "Backup failed" and "The specified file does not exist." The details confirmed that, but do not say what file does not exist. The MVP log viewer confirmed "File not found", but did not specify the file.
When I try to add the most recent tibx file to the backup, I get:
Failed to add the backup to the backup list. The backup may be locked or corrupted. Also, make sure the folder contains the last volume of the backup, and does not contain a renamed copy of the same backup.
Right-clicking the same tibx file and choosing Acronis, Validate has the same result. This usually worked with ATI 2019.
I rebuilt the database folder using the steps from the KB article 60195. Same result.
I rebuilt all of the settings as outlined in the article. Same result.
I repaired the ATI 2020 installation - no difference.
Before I rebuilt everything, the activity log reported validation failures after every backup since Jan 10, 2020. The backups ran successfully, the tibx files are there, but I have not found a way to access them from ATI 2020
Has anyone else encountered this problem and solved it? Please let me know. Thanks!
Richard,
Have you tried to reconfigure the backup destination in the backup task? You can do that by selecting the task in the application GUI then click on the destination icon. Navigate to your NAS location where the backups are and select it if necessary. Click the Ok button. You will get a message stating that "Previously versions of the file will not be shown in the Recovery tab of this backup. To recover them, first add them as an existing backup."
You will have the option to Cancel this action. I would do that at this point and see if your actions have changed the behavior. If nothing has changed then I would do this again and confirm the decision to change the backup destination. Once that is done then use the Add existing backup option to add back the differential versions. Select the top (most recent) file in the list. The message that you were seeing at this point saying No data to recover yet will disappear. Navigate to another tab such as Activity or Backup then back to the Recovery tab. You should now see options to recover Disk, Partitions, or Files. Below those options you will see Versions with the most recent file displayed in a drop down box. Clicking on the down arrow of this box will show all 300 of your differential files.
This action should update the metadata used to track you backup files for this task which should result in getting things working again.
Thanks Steve and Echantech, for the quick intervention.
I ran a backup this morning with the clean configuration. Two unusual incidents occurred:
- The backup ran six times, creating four differential backups, a full backup and another differential backup. Then the backup validation failed. See the attached screenshot ATI2020__Backup_Activities_20200219.png.
- When I click on the destination folder for the task, I get "Failed to open information about backup NOTEBOOK3.tibx. The backup might be incomplete or corrupted." The event code is 0x000B0080+0x00040011. See the attached screenshot ATI2020__Dest_Select_Failure_20200219.png.
I configured the task to run a daily differential scheme, with six differential files after every full backup. Starting January 11, 2020, it created six files each night and continues to do so. I don't recall changing the options then, or how I could even set it up to to that. I want it to create one tibx file each night. When I tried to check the options, I get the error shown in the screenshot ATI2020__Dest_Select_Failure_20200219.png.
I generated an Acronis System Information file - it's about 16 MB, so I can't attach it here. Let me know if you need it. Thanks!
Richard, the activity log shows that an error is probably causing the backup to repeat multiple times.
If you can share a link for the System Report zip file, that would let us investigate further.
Richard, thanks for the system report, the core issue here is with the file on your NAS.
The snippet from the backup_worker log for a recent validation attempt shows the error which has been present in all the logs in the report.
19/02/2020 09:51:45:811 AM -08:00 4832 I00000000: type=log; level=err; message=io: failed to open '\\?\UNC\DiskStation1\Backup2\Notebook3\NOTEBOOK3.tibx' (win_err=-2);
19/02/2020 09:51:45:811 AM -08:00 4832 I00000000: type=log; level=err; message=io#1: failed to open "\\?\UNC\DiskStation1\Backup2\Notebook3\/NOTEBOOK3.tibx" (pcs_err=-8);
19/02/2020 09:51:45:811 AM -08:00 4832 I00000000: type=log; level=inf; message=io#1: reopen: read 6000:400000 failed with err -5022;
19/02/2020 09:51:45:811 AM -08:00 4832 I00000000: type=log; level=err; message=io#1: reopen: no progress since last error;
19/02/2020 09:51:45:811 AM -08:00 4832 I00000000: type=log; level=err; message=io#1: read 0x400000 err -5022, offs 0x6000;
19/02/2020 09:51:45:811 AM -08:00 4832 I00000000: type=log; level=err; message=ar#1: failed to read segment 6 0x6:0x3 (err=-5022);
19/02/2020 09:51:45:811 AM -08:00 4832 I00000000: type=log; level=err; message=ar#1: failed to read segment 7 0x9:0x1 (err=-5022);
19/02/2020 09:51:45:811 AM -08:00 4832 I00000000: type=log; level=err; message=ar#1: failed to read segment 8 0xa:0x3 (err=-5022);
19/02/2020 09:51:45:811 AM -08:00 4832 I00000000: type=log; level=err; message=ar#1: failed to read segment 9 0xd:0x1 (err=-5022);
19/02/2020 09:51:45:811 AM -08:00 4832 I00000000: type=log; level=err; message=ar#1: failed to read segment 10 0xe:0x1 (err=-5022);
19/02/2020 09:51:45:811 AM -08:00 4832 I00000000: type=log; level=err; message=ar#1: failed to read segment 11 0xf:0x3 (err=-5022);
My best advice at this point would be to try creating a completely new backup task with a new / unique name and see if that will succeed or not?
The current notebook3.tibx looks to be corrupted from the messages shown in the logs but the question here is whether this is down to this single file, or a wider issue with the disk or file system in the NAS?
Follow Steve's suggestion. If a new task also fails you should start troubleshooting your hardware. Simple things first like replace the network cable to the NAS. If you use a switch and have unused ports, try using them. Disconnect all HDD data cables on both ends in the NAS and re-seat them This last one will often errors.
The Storage Manager part of Synology DSM might show if you are having drive problems on your NAS. (I can't give any details because mine have not shown any problems.)
I tried Steve's suggestion, creating a new task with the backup destination set to the NAS folder containing the previous tibx files. I got the same result - six backups and a validation failure. I think this is because the folder does not have NOTEBOOK3.tibx, presumably the first tibx file the task created. I could not find NOTEBOOK3.tibx in the #recycle folder. I suspect the NAS removed it when cleaning up the volume.
I created another new backup task with an empty folder as its destination. That task created a NOTEBOOK3.tibx file. It created only NOTEBOOK3.tibx in the new folder and it successfully validated.
Now I have a clean baseline, but my previous backups are in a different folder. I suppose I could add them to the new backup task, which has the same name. Does anyone have any comments about that?
Thanks again for all your support. I prefer it to Acronis support!
Richard, personally I would recommend sticking with your new clean backup / baseline and forgetting about the previous backups.
Users now need to be much more careful when dealing with .tibx files, especially when deleting such files as there are now dependencies involved that did not exist in previous versions of ATI.
See the following KB documents published by Acronis with regards to .tibx files.
KB 63518: Acronis True Image 2020: do not delete first tibx file
KB 63227: Acronis True Image: Do not delete .TIB or .TIBX files outside of Acronis True Image
KB 63498: Acronis True Image 2020: new tibx backup format FAQ
KB 63425: Acronis True Image 2020: Limitations of tibx backups
KB 63445: Acronis True Image 2020: how to view and manage backup versions in new backup format
KB 63444: Acronis True Image 2020: tibx backups in local destinations
I agree with Steve. I've been testing some today and finding some interesting things with .tibx files using rescue media.
1) If you have a consolidated 12Kb .tibx at the beginning of your chains, you will always need to have it to recover.
2) you need to have the correct 12Kb .tibx file for the backups in your chain. It references the known backups at the time of creation so if you manually move files around and the consolidated file doesn't know about later ones, they will not be recoverable.
3) When using rescue media, once you've selected a backup chain, it references the consolidated .tibx file to determine what should be recoverable. If you start the rescue media and it can't find files, but you have them to put back, you will want to move them first, restart the rescue media (reboot it completely) and try again. Once you've started to recover, whatever it found and compared the first time is "locked" in. REbooting seems to be the best option if you added missing files later.
Essentially, yup, all backups chains /types (I was testing with just full backups) are tied to the meta data in the first backup or the first consolidated backup file at this time. I recently saw that a request case was opened to make each chain completely separate (like it has been in 2019 and earlier). Until then, it's really important to not mess with moving backup files in explorer at all if you want to be able to recover. Instead, use the cleanup option in the True Image application
Steve, @Enchantech and @Bobbo_3C0X1,
Thanks for all of the great information and support - it's better than what I pay for.
I checked my Synology logs to see when I deleted the notebook3.tibx file (first in the series) from the recycle bin. It has no record of that file's deletion.
I noticed something else, though. This problem started to occur on Jan 11, 2020. On Jan 10, I deleted several tib (not tibx) files from a different destination folder. I suppose I could have deleted notebook3.tibx at the same time and Synology's DSM didn't log it. That seems unlikely though, as unlikely as deleting tib files from one destination folder could cause problems with tibx files in another. I have to accept that all my old tibx backups are useless because of mysterious file deletion.
I'm disappointed that Acronis has made their backups so fragile. I think it's the wrong direction for a company selling data security. The only bright spot I see is this community. Thanks again!
Richard Cunningham wrote:I'm disappointed that Acronis has made their backups so fragile. I think it's the wrong direction for a company selling data security. The only bright spot I see is this community. Thanks again!
Acronis seems to be aware that they made a mistake and is noticing user comments. I suggest you use the ATI Feedback function to make your feelings known. I doubt that Acronis is going to give up on the .tibx format, but they may make it less fragile if enough people complain.