Skip to main content

How to get TI to do a missed differential backup instead of starting over?

Thread needs solution
Beginner
Posts: 5
Comments: 19

Hello, I have True Image 2017. I do a full backup followed by 6 differential backups followed by a full backup.  The backups occur once a week.  Every once in a while, for various reasons that are not the program's fault, TI2017 cannot reach the drive it is supposed to back up onto, and the backup fails.  A red "x" appears to note this if you open the main interface.  

When this happens and I discover it, I would like to fix the problem and then perform the missed differential backup. But I can't figure out how to make it do a differential backup.  Invariably, on the next backup after a fail, it starts over and does a full backup.  This happens if I manually say "back up now".  It also happens if I just wait until next week.  It also happens if I change the schedule so that the next backup is, say, an hour from now.  No matter what I say or do, if I do nothing or I do something, TI's response is the same: Start Over From A Full Backup Again.  This despite the fact that right now the banner at the top says "Last backup 4/13/2020" which is correct.  It says Next backup 4/27/2020" which is correct.

Even more peculiar, this particular time I have a new problem: I actually have two backups set to go, one after the other. Usually in this situation I will end up with 2 red x's.  In this case, the backup that has the red x is the second one.  But the first one didn't happen either.  This first one, however. has: a) a green checkmark as if it happened; b) a banner that says its last backup is 2/11/2019 which is absolutely not true.  Its last differential backup was 4/13/2020 and its last full backup was 3/23/2020.  So this time was "extra special".

So my most critical question is, is there any way to have TI start from "where it left off" after something goes wrong, in the "usual" case where it missed a backup and is accurately reporting this to me?

And secondarily, what if it missed a backup and now thinks its last backup was very different from when its last backup actually is, what's up with that and how do I get it to know what's actually gone on?

Thank you.

0 Users found this helpful
Legend
Posts: 106
Comments: 26750

Alan, if a backup fails for any reason, it should retry according to the Error handling settings for the task (Options > Advanced > Error handing), and should continue the same Backup scheme and therefore, if a differential was due to be created, do so on either an automatic retry, or on a manual one.

To be able to understand why this is happening differently for you will require more information and probably the easiest way of collecting that is to run an Acronis System Report and then share the zip file this produces via a cloud share link from such as Google Drive, OneDrive etc.

See KB 58820: Acronis True Image: Collecting System Report

Beginner
Posts: 5
Comments: 19

Hi Steve,

Thank you for the response.  I did not have error handling set to retry the backup; I will change that since I like that idea.  But if I understand you correctly, even in this situation, where I did not have error handling set up, it should still continue the same backup scheme as before?  Or are you saying that in order to have it continue "where it left off", I should turn on the "repeat attempt if a backup fails"?  

I will gather the system report information and reply with the link.  My issues now have issues: when I try to change the error handling I get an "unknown error" on one of my two backups, and "network disconnected" on the other (won't even let me get into options).  I rebooted, didn't help.  I said "test connection", connection is happy.  So, confusion on top of confusion.  This behavior is new whereas the issues I was describing with the backup restarting at full are longstanding.  

Regards, Alan 

Beginner
Posts: 5
Comments: 19

Legend
Posts: 106
Comments: 26750

Alan, thanks for the system report.

The first / most recent error shown in the logs is:

20/04/2020 08:30:02 :964  Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
20/04/2020 08:30:02 :965  Operation System started by schedule.
20/04/2020 08:30:04 :149  Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
20/04/2020 08:30:04 :161  Operation: Backup
20/04/2020 08:30:04 :163  Priority changed to Low.
20/04/2020 08:30:22 :295  Create Backup Archive From: SYSTEM_DRV (1-2); Windows7_OS (C:); Lenovo_Recovery (Q:) To file: \\192.168.3.176\Elements 5TB\SS3\System_2020-04-20.tib Compression: Normal
20/04/2020 08:30:22 :309  Pending operation 172 started: 'Creating partition image'.
20/04/2020 08:30:22 :789   Writing full version to file: System_2020-04-20_full_b10_s1_v1.tib
20/04/2020 08:30:24 :356  Pending operation 172 started: 'Creating partition image'.
20/04/2020 09:18:55 :171   Writing full version to file: System_2020-04-20_full_b10_s1_v2.tib
20/04/2020 09:18:56 :058  Error 0x40004: The disk is full.
20/04/2020 09:18:58 :617  Error 0x101f6: Disk is full
20/04/2020 09:18:58 :617  Error 0x70015: Disk is full
20/04/2020 09:18:58 :755  Error 0x13c0005: Operation has completed with errors.

Basically, you have run out of space on your Elements 5TB drive for your backup files.

The previous backups shown in the log all look to have been successful.

Beginner
Posts: 5
Comments: 19

Thank you, but I think unfortunately you've gotten sidetracked by a little bit of lack of clarity on my part.  Yes, the backup failed because I let the backup drive get full. However, I came to you with a question without proof, and I think you went looking for that proof in the uploaded file and... it's not there. 

Specifically: because I have done this 10 times before and have noticed that every single time, after the drive full error, when I make space on the drive and then try to get TI to restart where it was in the differential chain, it starts a new full backup, and I don't want it to do that for the 11th time, I came to the forums to ask the question of how to prevent it starting over with a full backup at this exact moment in time, which is *after* the initial failed backup (that was my fault, due to the drive being full) and *after* fixing the underlying problem (there is now room on the drive) but *before* I have tried to get it to restart the backup chain. 

My thought process was, I already know what will happen if I do not ask for help: I'll end up with a full backup instead of a differential backup when I try to restart the backup chain (either by waiting until next week or by clicking "backup now"). But it's true, because I am trying to avoid this happening, I cannot present you with proof that this is what's going to happen.  All I can tell you is that this has happened every single time before and so I truly believe, but have no proof, that if I do what I have done before, I will get the same result as before.  

If the only long-term way to fix it is to let it make a full backup again and provide the zip file, I can do that, but I really was hoping there was some other way.  

So, my questions: 

1. I am assuming that it's already too late to tell it via error handling to try to do the differential again this time.  Is there any other way, from where I am right now, with a failed backup and error handling off at the time of failure, to get it to perform a differential backup the next time the backup is scheduled?  Waiting for the next scheduled backup does not work, neither does pressing "backup now".  But it still makes no sense to me that there would be no way for it to "pick up where it left off", so I was really hoping there was some way to tell it to pick up where it left off.  Is there?  

2. So going forward, clearly your instructions regarding error handling are the way to go.  So I tried setting up the error handling, and this caused new questions because I was not able to get the error handling to turn on.   When I try to change the error handling I get an "unknown error" on one of my two backups, and "network disconnected" on the other (won't even let me get into options).  I rebooted, didn't help.  I said "test connection", connection is happy.  This behavior is new whereas the issues I was describing with the backup restarting at full are longstanding.  Note, both backups back up to the same location - the same folder on the same network location.  And yet only one says it has no connection to the network. 

Do you have any suggestions regarding these issues?

Thank you. 

Legend
Posts: 106
Comments: 26750

Alan, can you confirm the task names for the ones which exhibit the behaviour of starting a new Full backup after a failure instead of continuing a Differential chain?

Also, can you point me to a date when this last happened that might still be shown in the logs received?

Beginner
Posts: 5
Comments: 19

Steve, thank you for your reply.  The active task names are System, and Data.  They both exhibit this problem.  They are my only currently active backup tasks.  

The full backups that occurred on 2/10/2020 represent the most recent example of the issue.  Unfortunately when I cleaned up the drive to allow room for the new backups to occur, I deleted some of these older backups.  So I have a slightly "cleaner" answer for System than for Data.  

But, I had a full backup of the Task Name "System" on 1/13/20.  The series from went b9_s1 (full) on 1/13/20, to b9_s2(diff) 1/20, b9_s3 (diff) 1/27, and then b9_s5 (diff) 2/03.  Then instead of doing b9_s6 on 2/10, it did a full b10_s1 on 2/10.  So there was a skip in the numbers... what happened to s4, I have no idea.  It skipped from 3 to 5.  It's too long ago for me to remember what happened (if it was even something I noticed).  But, I think the skipping is not what caused the problem on 2/10, I think that was a disk full error.  Since I'd had a full backup on 1/13/20, I should not have had another full until 2/24/20 (if you ignore the number skip) or 2/17 (if you take it into account). But you can see that after this, everything was fine for a while... full 2/10, diffs, 2/17, 2/24, 3/02, 3/09, and 3/16, followed by another full on 3/23.

The other task that I have running, I did delete some of the backups so I am guessing I think that I had a full backup of the Task Name "Data" on 1/13/20 and differentials on 1/20, 1/27, and (possibly/probably) 2/03.  Then there was a full backup on 2/10.  I can't tell if it skipped from 3 to 5 since I deleted those.  But, since I'd had a full backup on 1/13/20, I should not have had another full until 2/24/20.  As an added "twist", these "b" numbers are supposed to increment... ie, after b9_s6 you go to b10_s1 etc.  But somewhere in the chain for the Data task I went from b24 or b25, back to b10 on 2/10/20.  (it's b24 on 1/06/20).  So the numbering got lost on Data but not on System.  But then things continued as they should, same as with System..   Full 2/10, diffs, 2/17, 2/24, 3/02, 3/09, and 3/16, followed by another full on 3/23.  

Regards, Alan

Legend
Posts: 106
Comments: 26750

Alan, thanks for the further information.  I am seeing several things in the logs focussing mainly on your System task.

Working backwards from the most recent backup activity.

20/04/2020 08:30:22 :789   Writing full version to file: System_2020-04-20_full_b10_s1_v1.tib
20/04/2020 09:18:55 :171   Writing full version to file: System_2020-04-20_full_b10_s1_v2.tib
20/04/2020 09:18:56 :058  Error 0x40004: The disk is full.
13/04/2020 09:11:44 :313  \System_2020-04-13_diff_b10_s4_v1.tib
06/04/2020 09:02:36 :802  \System_2020-04-06_diff_b10_s3_v1.tib
30/03/2020 08:55:03 :226  \System_2020-03-30_diff_b10_s2_v1.tib
24/03/2020 11:35:52 :117  \System_2020-03-24_full_b10_s1_v1.tib
16/03/2020 09:12:09 :651  \System_2020-03-16_diff_b10_s6_v1.tib
09/03/2020 09:21:54 :394  \System_2020-03-09_diff_b10_s5_v1.tib
02/03/2020 09:13:41 :765  \System_2020-03-02_diff_b10_s4_v1.tib
24/02/2020 08:46:01 :547  \System_2020-02-24_diff_b10_s3_v1.tib
17/02/2020 08:41:31 :200  \System_2020-02-17_diff_b10_s2_v1.tib
10/02/2020 21:01:39 :201  \System_2020-02-10_full_b10_s1_v1.tib
03/02/2020 08:49:23 :299  \System_2020-02-03_diff_b9_s5_v1.tib
27/01/2020 08:44:27 :295  \System_2020-01-27_diff_b9_s3_v1.tib
20/01/2020 09:02:22 :486  \System_2020-01-20_diff_b9_s2_v1.tib
 

13/01/2020 20:09:59 :153  Error 0x1e50023: Cannot access the path: P:\Computer Backups to save longterm\System_2018-09-24_full_b9_s1_v1.tib
13/01/2020 21:43:18 :137  \System_2020-01-13_full_b9_s1_v1.tib

06/01/2020 09:00:50 :378  \System_2020-01-06_diff_b10_s2_v1.tib
30/12/2019 10:44:45 :766  \System_2019-12-30_full_b10_s1_v1.tib
23/12/2019 08:57:03 :763  \System_2019-12-23_diff_b9_s4_v1.tib
16/12/2019 08:56:55 :311  \System_2019-12-16_diff_b9_s3_v1.tib
09/12/2019 08:40:35 :605  \System_2019-12-09_diff_b9_s2_v1.tib
 

02/12/2019 20:19:15 :139  Error 0x1e50023: Cannot access the path: P:\Computer Backups to save longterm\System_2018-09-24_full_b9_s1_v1.tib
02/12/2019 21:43:52 :977  \System_2019-12-02_full_b9_s1_v1.tib

25/11/2019 08:58:38 :787  \System_2019-11-25_diff_b10_s2_v1.tib
18/11/2019 10:23:06 :293  \System_2019-11-18_full_b10_s1_v1.tib
11/11/2019 09:05:04 :998  \System_2019-11-11_diff_b9_s4_v1.tib
04/11/2019 08:51:25 :560  \System_2019-11-04_diff_b9_s3_v1.tib
28/10/2019 08:52:26 :473  \System_2019-10-28_diff_b9_s2_v1.tib

21/10/2019 21:48:47 :162  Error 0x1e50023: Cannot access the path: P:\Computer Backups to save longterm\System_2018-09-24_full_b9_s1_v1.tib
21/10/2019 23:28:17 :289  \System_2019-10-21_full_b9_s1_v1.tib

14/10/2019 08:43:31 :589  \System_2019-10-14_diff_b13_s2_v1.tib
07/10/2019 10:15:31 :074  \System_2019-10-07_full_b13_s1_v1.tib
30/09/2019 08:30:03 :175   Writing full version to file: System_2019-09-30_full_b13_s1_v1.tib
30/09/2019 08:30:04 :785  Pending operation 172 started: 'Creating partition image'.
30/09/2019 08:46:34 :384   Writing full version to file: System_2019-09-30_full_b13_s1_v2.tib
30/09/2019 08:46:34 :861  Error 0x40004: The disk is full.

Looking at the above log entries, you have changed the number of differential files from 3 to 4 to 5 before a new full backup over the period shown.

You look to have perhaps restored data from an older backup image that includes the C:\ProgramData\Acronis folder path which is causing the reset back to the _b9_ chain each time the highlighted error is thrown for the path error using P:\

A similar pattern is shown for your Data backup task.

Beginner
Posts: 5
Comments: 19

Thanks Steve; 

1. Can you tell me where to look to find this log you are looking at, so I can point you to the correct place(s)?

2. You appear to be suggesting two things: one is that these full backups were done at the designated times, and were performed because I changed the # of differential backups.  I may well have changed the number over time, but certainly not recently, and definitely I never changed from, e.g., 6 back to 4 or 4 to 2. If I can see the logs, I'll be able to tell a little better.  However, these two examples below illustrate my problem.  

Example 1: why did it start over after only one differential?  I know I never had it set to a single differential, yet that is what happened here; it was previously 4, then went to 2.  It's possible I switched from 4 to something else, but it would not have been 1 or 2, and it would not have been something I did between 1/06, when I got on a plane, and 1/19 or 1/20, when I returned home:

13/01/2020 21:43:18 :137  \System_2020-01-13_full_b9_s1_v1.tib

06/01/2020 09:00:50 :378  \System_2020-01-06_diff_b10_s2_v1.tib
30/12/2019 10:44:45 :766  \System_2019-12-30_full_b10_s1_v1.tib
23/12/2019 08:57:03 :763  \System_2019-12-23_diff_b9_s4_v1.tib

Example 2: Why is it trying to restart with a full after 4 instead of 6?  Clearly it was set to 6 on the previous cycle.  And I did not change it.  It is clearly demonstrating that on 4/27 it's going to start over with a full backup instead of the currently-designated 6.  According to this record, it already tried.  

20/04/2020 08:30:22 :789   Writing full version to file: System_2020-04-20_full_b10_s1_v1.tib
20/04/2020 09:18:55 :171   Writing full version to file: System_2020-04-20_full_b10_s1_v2.tib
20/04/2020 09:18:56 :058  Error 0x40004: The disk is full.
13/04/2020 09:11:44 :313  \System_2020-04-13_diff_b10_s4_v1.tib
06/04/2020 09:02:36 :802  \System_2020-04-06_diff_b10_s3_v1.tib
30/03/2020 08:55:03 :226  \System_2020-03-30_diff_b10_s2_v1.tib
24/03/2020 11:35:52 :117  \System_2020-03-24_full_b10_s1_v1.tib
16/03/2020 09:12:09 :651  \System_2020-03-16_diff_b10_s6_v1.tib

In terms of what went wrong, in the second example, it appears to be that the disk was full.  But the order in the logs doesn't make sense; the "decision" to make a full backup seems to have preceded the identification, by the program, that there was in fact a full disk.  Like it had already decided to do a full not differential, and then it found the disk full.  Which leaves a head scratcher there for me.  

And regardless, I still get the impression that, given what we are seeing here, I am going to get a "full" this week when I should be getting s5 or s6.  And I still don't know how to change that.  

However, with the first example, something interesting happened.  As you noted, and as I found (not, I think, in the log you were looking at), on 1/6 the s2 backup went off as planned.  On 1/13, something had changed and somehow it was trying to access this weird path on P: as the start of its chain.  Which is odd, because the start of its chain was clearly on 12/30/2019, not this backup on an entirely different drive from 2018.  Then when it couldn't find it, it started over with a full.  In this case, I understand that it couldn't find a full and therefore it made a new full, but I am mystified as to why it would look in P: for the full, and why it would be looking for the wrong filename for the full on top of that.  How do I stop that from happening in the future?  

Related to this, I did not understand this statement: "You look to have perhaps restored data from an older backup image that includes the C:\ProgramData\Acronis folder path which is causing the reset back to the _b9_ chain each time the highlighted error is thrown for the path error using P:\" 

Of note, I have not looked at the file on P: that the log is referring to, in a very long time.  The P: drive is a separate drive and I do not use TI2017 to write to that drive.  There are, however, .tib files on P:, in the folder indicated.  And I have indeed looked at .tib files on P:.  Not that one, but other ones. 

Are you saying that the act of looking at, or restoring data from, a .tib file on P: disrupts the TI2017 backup chain count on Elements 5TB?  

Alternatively, are you saying that there is a reference somewhere to this ancient file and if I get rid of it, some of my problems will go away?

Thank you, Alan

 

Legend
Posts: 106
Comments: 26750

Alan, please download the MVP Log Viewer tool (link in my signature below) and use this to review the log files for your backup, which is what I was using to compile the information in my last post above.  You have to visit each log in turn to see the log entries.

The log information is purely showing what has happened on your computer for these backup tasks.  The number of incrementals created before a new full backup is created is controlled only by the task configuration settings for the Backup scheme being used, so if the number varies, then this has been changed by a user.  ATI only does as it is instructed to do.

The key error that looks to directly cause the change in backup identifier _b?_ is this:

Error 0x1e50023: Cannot access the path: P:\Computer Backups to save longterm\System_2018-09-24_full_b9_s1_v1.tib

This needs to be seen in the context of the full log text:

02/12/2019 20:19:14 :511  Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
02/12/2019 20:19:14 :512  Operation System started by schedule.
02/12/2019 20:19:15 :121  Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
02/12/2019 20:19:15 :127  Operation: Backup
02/12/2019 20:19:15 :129  Priority changed to Low.
02/12/2019 20:19:15 :139  Error 0x1e50023: Cannot access the path: P:\Computer Backups to save longterm\System_2018-09-24_full_b9_s1_v1.tib
02/12/2019 20:19:15 :214  Create Backup Archive From: SYSTEM_DRV (1-2); Windows7_OS (C:); Lenovo_Recovery (Q:) To file: \\192.168.3.176\Elements 5TB\SS3\System_2019-12-02.tib Compression: Normal
02/12/2019 20:19:15 :218  Pending operation 172 started: 'Creating partition image'.
02/12/2019 20:19:15 :749   Writing full version to file: System_2019-12-02_full_b9_s1_v1.tib
02/12/2019 20:19:16 :684  Pending operation 172 started: 'Creating partition image'.
02/12/2019 21:29:50 :554  Pending operation 172 started: 'Creating partition image'.
02/12/2019 21:43:52 :694  Pending operation 172 started: 'Creating partition image'.
02/12/2019 21:43:52 :977  The following backups have been successfully created: \\192.168.3.176\Elements 5TB\SS3\System_2019-12-02_full_b9_s1_v1.tib
02/12/2019 21:43:53 :196  Operation has succeeded.

As shown above, this was a scheduled task which immediately hit the error with the path to your P:\ location, which also referenced a backup file using the _b9_ sequence identifier.  This is turn then caused the task to start again using that _b9_ identifier.

If you have restored any data for files stored in the C:\ProgramData\Acronis folder path, then this can cause problems by restoring data to an earlier time, i.e. 2018-09-24 per the file name in the problem error path.

If you haven't been restoring such data, then something is getting corrupted in your ATI 2017 installation, either in the Scripts (.tib.tis) XML files, or else in the internal Database used by ATI.

For the later scenario, I would recommend forcing a rebuild of the Database as per the steps given in KB 60915: Acronis True Image: repairing program settings

Beginner
Posts: 5
Comments: 19

Steve,

Thank you, I have downloaded the tool.  It looks like it's a "cleaner" way to view the files in the ti_demon folder where I was looking yesterday.  The "short view" is cleaner than what I looked at "raw", which was more like the "regular" view.  But one doesn't see the reference to the P: drive unless one switches to the Regular view.  

I think I'm getting a clearer idea of what happened thanks to your guidance, but I'm still not sure what I did or how to prevent it in the future.

  • I will definitely try "repairing program settings" - because I cannot even access the System task options anymore, and because when I try to change the error handling settings for Data, I get "an unknown error has occurred".
  • I do understand that error handling will help going forward. 
  • I have definitely been on full + 5 differentials for a long time on the Data task (I found proof going back to early 2018, see below) and strong evidence that this has been the case on the System task since at least late 2018.  I know you say ATI does what it is told, but I am 100% certain that it is sometimes pulling the information on "where am I, is it time for me to do another full" from someplace other than the Options I see on the GUI, because I am certain that they have been set to 1 + 5 since 2018.  I am assuming that this has something to do with your question about whether or not I have done a restore, and so my questions now center around that. My goal is to make sure that whatever I did before, I don't do it again.  
  • System had a much more "tumultous" life with multiple errors where it couldn't find the P: drive starting very early on. So clearly I have been ignoring problems there for many years and I need to pay attention now.  

The part that's still confusing me has to do with where in the world is the program picking up these references to the "P" drive. You state "If you have restored any data for files stored in the C:\ProgramData\Acronis folder path..."  

  • Regarding the "folder path" part of that statement: what is the C:\ProgramData\Acronis folder path? 
    • How do I find what filenames are stored in the path? 
    • How do I find where the program is picking up these references to long-ago files? 
    • Is there a way to edit the folder path so it points where i want it to, after an "incident" of this type?
  • Regarding the "if you have restored any data" part of that statement, I would like to be able to restore a random file or two without having to rebuild my backup tasks (and start again from a full backup) each time I do so. I would like to be able to look at a .tib from an older time.  Is this possible? 
    • If I have restored my data, Is there a record of this if I do it, that I can look at in the log?  Because honestly I have no memory of if I looked in these .tibs recently or not.   
    • What "counts" as "restoring data for the files stored in the path"?   
      • What if I just look at a .tib and don't restore anything, does that still cause the task to reset?
      • There are two ways you can "restore" data.   One is to click the button for "recover files".  I never do this. 
      • The other way is to go to the .tib, double click on it, and, in a file-explorer like manner, navigate to the files I want to pull/recover.  I copy/paste them where I want them.  I did this within the last week or two, but I did not go back to P: that time, I did it off a very recent backup on Elements5TB. But we're talking 2 tiny files here, in one folder, out of 1000s of files in the backup.  Not everything in the backup.  Does this "count" as restoring data for the files stored in the path?
        • If this copy/paste thing "counts" as a "restore",is there any way to tell the program to ignore that and not restart at full and not do a "throwback" to an old .tib?  I don't see any real-world reason why I need to start over with a full backup after restoring a couple of random files.  

Background FYI: Based on what I'm seeing and what you're saying, it sounds like both System and Data have been "thrown back" to old references. 

  • The System task was unsuccessful in finding its "throwback", resulting in an error message.  Note, the backup is exactly where the error message says it looked for it, on P:  Yet it was unable to find it. 
  • The Data task apparently successfully found its "throwback", resulting in going from b25 to b9.  I don't know where the Data task looked for and found b9, because there is no error message.  But there's a b9 on P:. So the logs I've looked at so far do not contain all the data needed to figure this out.  
  • So apparently the Data task was able to find and read off of P: but the System task was not.    

Background FYI: proof that the Data task has been on 1 + 5 (resulting in s6 followed by s1) since 2018:

Full history showing s6's for the Data task back as far as b9. 

Recently: disobedience, and throwback to a very old full backup.

Data_2020-03-16_diff_b10_s6_v1.tib Obedience to s6 rule
Data_2020-02-10_full_b10_s1_v1.tib Operation has succeeded. Non-obedience to the s6 rule
Data_2020-02-03_full_b10_s1_v1.tib Terminated by user - Non-obedience to the s6 rule for having started a full in the first place.  
Data_2020-01-27_diff_b9_s4_v1.tib Operation has succeeded - throwback to b9_s4 - full b9 exists on p:  but b9_s3 does not.  So it's combining the b from one set of instructions with the s from another.  Other, more recent full b's exist on P: and on Elements5TB but were ignored. Corruption?? Did I touch/restore from b9 at this time?  
Data_2020-01-27_diff_b25_s3_v2.tib Error 0x40004: The disk is full.

Obedience to s6 rule from b16 to b24:

Data_2020-01-06_diff_b24_s6_v1.tib
Data_2019-11-25_diff_b23_s6_v1.tib
Data_2019-10-14_diff_b22_s6_v1.tib

Data_2019-08-26_diff_b21_s6_v1.tib
Data_2019-07-15_diff_b20_s6_v1.tib
Data_2019-06-03_diff_b19_s6_v1.tib
Data_2019-04-15_diff_b18_s6_v1.tib
Data_2019-03-04_diff_b17_s6_v1.tib
Data_2019-01-14_diff_b16_s6_v1.tib

There was some oddness around b15 associated with a disk full error.  Result, non-obedience to the s6 rule and starting over at b15, (not b9).   
Data_2018-12-03_diff_b15_s2_v1.tib
Data_2018-11-26_full_b15_s1_v1.tib
11/19/2018 11:49:57 AM: 18428 E00040004: Error 0x40004: The disk is full.
Data_2018-11-12_diff_b15_s4_v1.tib

Data_2018-10-15_diff_b14_s4_v1.tib
Data_2018-09-03_diff_b13_s6_v1.tib
Data_2018-07-16_diff_b12_s6_v1.tib
Data_diff_b11_s6_v1.tib (6/4/2018)

Data_diff_b10_s6_v1.tib

Data_diff_b9_s6_v1.tib (3/12/2018)

Background FYI - System.  Occasional obedience to s6 rule on System (in between many errors), strongly suggesting I had it set to 1 + 5 in GUI since at least late 2018:

System_2020-03-16_diff_b10_s6_v1.tib
System_2019-11-11_diff_b9_s4_v1.tib
System_2019-09-23_diff_b12_s6_v1.tib
System_2019-08-12_diff_b11_s6_v1.tib
System_2019-07-01_diff_b10_s6_v1.tib
System_2019-04-01_diff_b12_s6_v1.tib
System_2018-11-12_diff_b10_s6_v1.tib

Note, once I set it to 1 + 5 I would not have "gone back".  I don't have tons of room on mybackup drive.  My intention has always been 1 + 5, and this "post mortem" indicates that there's been something very wrong with System for a long long time (with the constant throwing back to b10 or b9) and I just haven't been paying attention to it.  

Thank you for hanging in; I think I'm getting closer to understanding.  Note that I am partly documenting for you and partly for "posterity" so perhaps someone else doesn't have to undergo the mental calisthenics I am dealing with.  If my density can help someone in the future, great...

Regards, Alan

Beginner
Posts: 5
Comments: 19

Update.  I tried Method 1, rebuild the database folder.  Didn't help.  I then tried Method 2, rebuild all settings.  Didn't help.  I then did a repair of the install.  Didn't help.  Now when I try to "add an existing backup"  it says "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 contained a renamed copy of the same backup."

I can try uninstalling and reinstalling but I don't have a great deal of hope that that will work.  

Is this "throwback" filename embedded in the .tib itself?  That could be the corruption that is being referred to?  

Alan

Legend
Posts: 106
Comments: 26750

Alan, the most likely place any reference to your old P: location is held is in the Database files.

You could browse through the .tib.tis script files in C:\ProgramData\Acronis\TrueImageHome\Scripts folder using Notepad to look at the XML information, but it is unlikely to be there, and I don't believe this type of information is stored in the Windows Registry.

What you can try doing is:

Copy the C:\ProgramData\Acronis\TrueImageHome\Scripts folder to another place.

If you want to keep copies of the old logs going back to 2018 then create a new Acronis System Report and then copy the zip file to somewhere out of any of the Acronis folders.

Now open the Control Panel > Programs & Features and uninstall ATI 2017 normally.

Next, download the Acronis Cleanup Tool (link below) then run this as Administrator to do a full clean up of all residual data for ATI 2017.
Note: the KB document for the cleanup tool would have you make changes to the Windows Registry.  If you do this, then make a backup of the Registry / Registry entry first.  Personally, I tend to skip those steps and leave the registry alone unless absolutely necessary!

Restart the computer to complete the cleanup actions, then do a clean install of ATI 2017.

At this point, you have several options:

You could check that you can make a totally new backup task to show all is working correctly.

You could Add an existing backup file and reconfigure the settings for the same.

You could copy back the .tib.tis script files copied from the Scripts folder earlier, either one at a time or all together.  Do this when the ATI GUI is closed, then check that the task from the script file is shown in the GUI when you reopen it.  You should still reconfigure the task to ensure all settings / schedule etc is correct.

Beginner
Posts: 5
Comments: 19

Progress report: I clean-uninstalled and then reinstalled.  I tried to "add a backup" and at first got the same error message, but then the backup appeared in the list anyway.  In this way I added both the Data and the System backup back.  Both of them currently state that they were last backed up on 4/13 and are next due for backup on 4/27.  Both are set up to have 5 differentials followed by a new backup.  Both are set up with error handling. 

I did take one risk and put the @task@_@date@ back in the script files since it had been removed and I like that feature.

I'll report back what happens next...

However, it'll be a while before I can test the error handling... but it doesn't look promising. I set the error handling to try 5 times 6 HOURS apart in the GUI, but I see this in the script...

<stream_options allow_silent_media="false" cache_network_write="false" compression_level="normal" encryption_algorithm="none" format="tib" freespace="0" ignore_bad_sectors="false" reattempt_count="5" reattempt_on="true" reattempt_pausesec="30" silent_asz_cleanup="true" silent_mode="false" type="disk" ver="1">

If this part of the script is referring to the error handling?  If so, it doesn't appear to be taking what I told it in the GUI. 6 hours would be 21,600 seconds.  

What I am still unclear on in terms of "how to avoid this in the future" is, what is the "risk" of looking at old backups - how can that mess up my current backups, what are the rules, how can I prevent problems if I do look at or copy a couple of files out of an old backup?  

As noted earlier I would like to be able to restore a random file or two without having to rebuild my backup tasks (and start again from a full backup) each time I do so. I would like to be able to look at, and copy files out of, a .tib from an older time.  Is this possible without messing with my current backups?  If not, how do I clean up the mess right at the "time of" so it does not mess up the backup scheme?  

Thank you, Alan

Legend
Posts: 106
Comments: 26750

Alan, thanks for the progress report...!

It is recommended / best to avoid making changes to the .tib.tis script files as far as possible - you should be ok with adding @task@_@date@ but all other changes should be through the ATI GUI settings pages. 
Note: @task@_@date@ doesn't work with ATI 2020 disk backups now using .tibx files due to changes introduced by Acronis with new dependencies for the new file format.

There should not be any risk of looking at old backup files or recovering random files etc.  The only time this may cause an issue is if the backup file names are the same as the names of current backups but were created for different source data!  This is because ATI has the habit of adding an entry in the GUI for backups that are explored in Windows and uses the backup name for the entry, so would try to add information for such a 'matching name' to the database.

Where possible all backup names should be unique to avoid such issues.  If necessary, you could rename the older backup files to avoid this.

Beginner
Posts: 5
Comments: 19

Update:  On Monday, both backups were attempted - the Data task and the System task.  Both wanted to do full backups instead of the scheduled differential.  The logs show why:

"2020-04-27 18:15:03:707 21924 W01E50023: Error 0x1e50023: Cannot access the path: W:\SS3\Data_2020-03-23_full_b11_s1_v1.tib" 

I cancelled both backups because I knew I was going to need to reboot soon and didn't have time to wait for the full backups to complete.  Also I wanted to continue to troubleshoot/solve this problem.  

Important fact: it *can* access that drive.  Because after the error message, it was successful at starting the (full) backup.  Log excerpt:

2020-04-27 18:15:03:807 21924 I000101F8: Pending operation 172 started: 'Creating partition image'.
2020-04-27 18:15:31:073 20788 I00640000: Writing full version to file: Data_2020-04-27_full_b11_s1_v1.tib
2020-04-27 19:44:02:449 21924 W013C0001: Terminated by user.
 

So... it couldn't find it to *read* from but it could find it to *write* to.  

It just doesn't make any sense to me.  Recall, I added these back to ATI from the source files after the clean uninstall and reinstall.  So ATI could see that source file just fine at the time that the new script was created.  That file that is referenced above, that's the source file that was used to add the backup.  It is absolutely still there, that is absolutely still the correct name.  

However there's an interesting twist.  W: is a mapped network drive.  It is mapped from \\192.168.3.176\Elements 5TB . Those things are the same physical object.  That mapping hasn't changed in years, and certainly has not changed since I set up the backup on the weekend.  But the script that was generated uses W: to refer to the older backups in the chain, but \\192.168.3.176\Elements 5TB to refer to the new backup it's about to do.  Here's an excerpt from the script, although I redacted the string it had for password and username just to be extra safe.  

<volumes_locations>
                        <volume_location device_instance_id="" uri="W:\SS3\Data_2020-03-23_full_b11_s1_v1.tib" volume_id="1749485597" />
                        <volume_location device_instance_id="" uri="W:\SS3\Data_2020-03-30_diff_b11_s2_v1.tib" volume_id="2171471796" />
                        <volume_location device_instance_id="" uri="W:\SS3\Data_2020-04-06_diff_b11_s3_v1.tib" volume_id="2365494836" />
                        <volume_location device_instance_id="" uri="W:\SS3\Data_2020-04-13_diff_b11_s4_v1.tib" volume_id="196032545" />
                        <volume_location device_instance_id="" password="XXXX" uri="\\192.168.3.176\Elements 5TB\SS3\@task@_@date@.tib" username="XXXX" volume_id="0" />
                    </volumes_locations>

And then if you dig deeper into the log, there's this (bolding mine):

| trace level: warning
| line: 0x4d3f22948e29f1c8
| file: k:\8058\products\imager\archive\impl\utils.cpp:241
| function: `anonymous-namespace'::GenerateGuiErrorWithPath
| line: 0x4d3f22948e29f1c8, k:\8058\products\imager\archive\impl\utils.cpp:241, `anonymous-namespace'::GenerateGuiErrorWithPath
| $module: ti_demon_vs_8058
|
| error 0xb007f: The initial full backup version is not accessible at the moment.
| line: 0x65e40aa0b48716d
| file: k:\8058\products\imager\archive\impl\operations\archive_operation_backup.cpp:732
| function: TrueImage::Archive::BackupArchiveOperationImpl::TraceFirstVolumeExistance
| line: 0x65e40aa0b48716d, k:\8058\products\imager\archive\impl\operations\archive_operation_backup.cpp:732, TrueImage::Archive::BackupArchiveOperationImpl::TraceFirstVolumeExistance
| $module: ti_demon_vs_8058
|
| error 0x4002d: The specified file path does not exist.
| line: 0xf35f747b3b21fc55
| file: k:\8058\file\windows\winnt_dir.cpp:1356
| function: winnt_dir::iterator::iterator
| line: 0xf35f747b3b21fc55, k:\8058\file\windows\winnt_dir.cpp:1356, winnt_dir::iterator::iterator
| function: FindFirstFileW
| path: \\?\W:\SS3\Data_2020-03-23_full_b11_s1_v1.tib
| $module: ti_demon_vs_8058
|
| error 0xfff0: The system cannot find the path specified
| line: 0xbd28fdbd64edb8f1
| file: k:\8058\common\error.cpp:307
| function: Common::Error::AddWindowsError
| line: 0xbd28fdbd64edb8f1, k:\8058\common\error.cpp:307, Common::Error::AddWindowsError
| code: 0x80070003
| $module: ti_demon_vs_8058

See the \\?\ before the W:?  I was thinking maybe that shouldn't be there and that's why it can't find that file?  Is that a bug?  I know you are saying I shouldn't edit the script directly but what if I changed all the previous instances of W: to \\192.168.3.176\Elements 5TB ?  

I don't recall how I did the "add backup", if I did it by navigating to the source file from "W:" or from "\\192.168.3.176\Elements 5TB".  Maybe if I re-imported the backup and made sure I used the \\192.168.3.176\Elements 5TB link, all my volume_location device_instance_id's would be \\192.168.3.176\Elements 5TB and not W:?  And then maybe the error wouldn't occur?  

Note: I did try doing it the "other" way, since I didn't like the anomaly of the two being different.  I went back to the GUI and changing the destination from \\192.168.3.176\Elements 5TB to w:\.  It seemed to "take", and the GUI said W:\SS3.  Then I clicked on my second backup, then clicked back on the first one and... it was back to \\192.168.3.176\Elements 5TB.  

Thoughts?

Thank you, Alan

Legend
Posts: 106
Comments: 26750

Alan, one key factor here is the use of mapped drives, which is something I do not do for security reasons.  Any mapped drive is wide open to malware attack.

I always use either the \\ip address or \\network name for my NAS destination and haven't seen this issue.

Rather than edit the script .tib.tis file, I would suggest removing the task again in the GUI then adding back again without using the mapped drive letter (W:), so that you navigate direct to the remote \\192.168.3.176 location both in the GUI and in the Script that is created by using 'Add existing backup'.  That option is hidden behind the caret (v) to the right of 'Add backup' in the GUI.

Beginner
Posts: 5
Comments: 19

Success!  Thank you for all of your suggestions.  

So it sounds like my errors were due to:

1. Corruption (we never did figure out where it was pulling those super old filenames from, and now I have a clean install); and 

2. ATI dislikes mapped drives. 

It will take time (presumably, months) to confirm that: 

A. Restoring a couple of files from a backup doesn't lead to "throwback" filenames; and 

B. the setting in Error Handling is working as desired - I won't know that until the next time I let the drive get full, but it still concerns me that the script says "reattempt_count="5" reattempt_on="true" reattempt_pausesec="30" " when I set it to pause 6 hours (21,600 seconds).  

One more question: you stated "Note: @task@_@date@ doesn't work with ATI 2020 disk backups now using .tibx files due to changes introduced by Acronis with new dependencies for the new file format."

In ATI 2020, does the GUI allow you to use the date in the filename in some different way?  Or is it simply no longer allowed?  

Regards, Alan

Legend
Posts: 106
Comments: 26750

Alan, there are whole raft of changes introduced with ATI 2020 which bring new rules for how backups are managed etc.  One current issue is that backup tasks once created can not be renamed, even when cloning the settings.  Once a backup name is chosen and the first backup for that task created, then any attempt to change the name will cause significant problems!

Changing the script .tib.tis files is one area where no changes should be made.

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 63516: Acronis True Image 2020: Incremental backups do not create separate files when using new backup format

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

Beginner
Posts: 5
Comments: 19

OK that is a lot of big changes, thank you.  I read all of the links, and if I am understanding correctly, the way I do things now will not be usable if I move to .tibx, however the option to not move to .tibx is still available.

Specifically, I do a full followed by 5 differentials, then another full, then 5 differentials, etc. I understand that I can still do this in ATI 2020.

If I want to grab a couple of files from an old backup, I go to that .tib in File Explorer and drag and drop the files I want, where I want them.  It looks like this behavior is still OK in ATI 2020.

When the drive gets full, I manually delete the older backups (but never the current full backup).  I understand that I would, in ATI 2020, need to delete from from the GUI.  

However what I actually do is save maybe 1 full .tib for each calendar year.  But... I save them on a different physical drive.  I copy them using File Explorer onto another drive and save them longterm.  But I remove them from the drive where they were originally written.  So, e.g., I have a full .tib from a 2019 backup, one from a 2018 backup, and one from a 2017 backup, all sitting on a completely different drive.  Then if I want a file from one of those, I go to that .tib in File Explorer and drag and drop the files I want, where I want them.  If I understand correctly, in ATI 2020, if I stick with .tib's I can still do this, but if I move to .tibx, this behavior of copy/pasting the .tibx file to another drive to save longterm, even if I also save the little 12kb "first" backup as it was just before the copy, *will not work anymore*.  Is that correct - in ATI 2020 this will work if I stick with .tib but will not work if I move to .tibx?    

Thank you, Alan

Legend
Posts: 106
Comments: 26750

Alan wrote:

OK that is a lot of big changes, thank you.  I read all of the links, and if I am understanding correctly, the way I do things now will not be usable if I move to .tibx, however the option to not move to .tibx is still available.

  • Correct that you cannot do as you have been doing with changes to the .tib.tis files etc. Not correct for having an option to not move to .tibx format.  You can continue any existing Disk backups using .tib files but you cannot create a new Disk backup using .tib unless you jump through some hoops to do so.

    See forum topic: How to create a Disk backup as .tib (not .tibx) which will create a new backup task using the older .tib format in the Windows ATI 2020 GUI.

Specifically, I do a full followed by 5 differentials, then another full, then 5 differentials, etc. I understand that I can still do this in ATI 2020.

  • Yes, the backup schemes remain the same, but the key difference is that you need to keep all the differentials if you want to be able to recover from the chain.

If I want to grab a couple of files from an old backup, I go to that .tib in File Explorer and drag and drop the files I want, where I want them.  It looks like this behavior is still OK in ATI 2020.

  • This remains the same.

When the drive gets full, I manually delete the older backups (but never the current full backup).  I understand that I would, in ATI 2020, need to delete from from the GUI.  

  • Definitely not recommended to manually delete any backups other than by using the new 'Clean up versions' tool provided in the task menu for each task in the GUI.

However what I actually do is save maybe 1 full .tib for each calendar year.  But... I save them on a different physical drive.  I copy them using File Explorer onto another drive and save them longterm.  But I remove them from the drive where they were originally written.  So, e.g., I have a full .tib from a 2019 backup, one from a 2018 backup, and one from a 2017 backup, all sitting on a completely different drive.  Then if I want a file from one of those, I go to that .tib in File Explorer and drag and drop the files I want, where I want them.  If I understand correctly, in ATI 2020, if I stick with .tib's I can still do this, but if I move to .tibx, this behavior of copy/pasting the .tibx file to another drive to save longterm, even if I also save the little 12kb "first" backup as it was just before the copy, *will not work anymore*.  Is that correct - in ATI 2020 this will work if I stick with .tib but will not work if I move to .tibx?    

  • If you want to save one Full disk backup each year, then the best option is to create a separate, non-scheduled task for this purpose that is pointed at your separate backup drive.  To keep these backups completely independent you should remove the task settings from the GUI after the file is created, then create a new task for the next year.
    The first backup file of a task is always full size, it is the next full backup that causes the 12kb metadata file to be created for the task.

Thank you, Alan

Beginner
Posts: 5
Comments: 19

That's a lot.  I definitely won't be in a hurry to "trade up".  But at least now I know what I'll be in for.

Thank you for all.

Alan