Skip to main content

Acronis True Image 2019 - repeated fail on scheduled incremental backups, but afterwards, they complete successfully when run manually with "Backup now"

Thread needs solution
Forum Member
Posts: 7
Comments: 48

After replacing a failing HD with a new SSD and then installing ATI 2019 (I could not activate 2020 as already posted) and setting up my backup plan, I manually ran the base and then checked the destination and saw that the default TIB file name had spaces in it.  I do not like spaces in file or directory names!

I then did the following:

  1. Deleted the old base with:  This computer -> Name with spaces -> Clean up versions... -> check Full
  2. Renamed with:  This computer -> Name with spaces -> to remove the spaces and replace them with "_"
  3. Saved the changes to the backup plan with Backup -> Options -> Backup scheme -> Ok -> Save.  I have done this a few times now.
  4.  Manually ran the base with:  Backup now
  5. Checked the destination and then saw that the TIB file name now had "_" in it.

Since then, the next 2 scheduled incrementals have failed.  They complete successfully when run manually with "Backup now".  After the 2nd time that this has happened, I concluded that something is broken.

I have uploaded a screen snip of the error message and a folder listing after the incrementals were successfully created manually.

How do I fix this problem?

Thank you,

Attachment Size
ATI2019_backup_fail1.PNG 20.04 KB
ATI2019_backup_fail5.PNG 16.9 KB
0 Users found this helpful
Legend
Posts: 81
Comments: 17555

#1

Steve, sorry but the screen images do not tell us anything useful here to understand why your scheduled backups do not succeed but manual backups do?

Please use the MVP Log Viewer and post the logs for the failing scheduled tasks and working manual tasks if you are able.

If necessary, create an Acronis System Report and attach that is within the allowed file size limits or else post a link to a shared location (OneDrive, Dropbox etc).  If you prefer to not post the report zip publically, then send me a PM with a link so that I can take a look to see what is happening?

Forum Member
Posts: 7
Comments: 48

#2

Steve,

I am in the MVP Log Viewer.  It defaults to TI_demon which only lists the manual incrementals.  I will attach the latest one which does not show an error.  I do not see any log files for the automatic/scheduled incrementals.

Actually, it appears that I did run the original base where there were blanks in the name as an automatic/scheduled backup.  I am attaching that log too.  Note that this is for the base that I removed and then after removing the blanks in the name, I reran manually.

I will keep digging...

Thanks,

Attachment Size
512720-172353.log 4.28 KB
512720-172354.log 3.76 KB
Forum Member
Posts: 7
Comments: 48

#3

Steve,

I have now checked all of the other logs and there is nothing obvious to me after looking at all of them.  Which of the other log categories are important to look at?

Thanks,

Forum Member
Posts: 7
Comments: 48

#4

Steve,

The System Report zip is under 8MB.  Should I upload it "as is" or unpack it and remove anything that you consider unnecessary and then repack it?

Thanks,

Legend
Posts: 81
Comments: 17555

#5

Steve, you will need to look at the Schedul2 log but in order to understand it and find the relevant entries, you will also need to identify the internal task identifier for your scheduled task.

In the Schedul2 log you will see entries such as:

09/09/2019 18:10:00 :000  Trying task 1-11 as TIME_NORMAL

To know what task 1-11 is, you need to use the Acronis Scheduler Manager tool (link below) to get a list of all tasks by issuing the 'get list' command.

From the output listing, find the task, i.e. 1-11

1-11  *TrueImageHomeNotify* /dummy /script:"A46C9D16-6E12-400E-B28E-58B1E49AE5F8" /uuid: "A46C9D16-6E12-400E-B28E-58B1E49AE5F8" /task_type:2 /run_mode:?RunMode?

Next, you need to match the script identifier to the XML files stored in C:\ProgramData\Acronis\TrueImageHome\Scripts then open the script .tib.tis file in Notepad to find the task name.
So from the above, I would be looking for A46C9D16-6E12-400E-B28E-58B1E49AE5F8.tib.tis

Opening that file in Notepad shows me the task name:

<?xml version="1.0" encoding="UTF-8" ?>
<batch>
    <version>1.0</version>
    <uuid>A46C9D16-6E12-400E-B28E-58B1E49AE5F8</uuid>
    <display>Win 10 SSD Diff&#32;E</display>
    <priority>low</priority>

So now I know that task 1-11 in the Schedul2 log is my Win 10 SSD Diff E backup task.

Searching in my Schedul2 log for 1-11 shows me just 2 entries.

09.09.2019 18:10:00.000 00001CB8 Trying task 1-11 as TIME_NORMAL
09.09.2019 18:17:31.563 00001408  Task 1-11 completed with exit code=0

This shows that the scheduled task ran normally to completion.  exit code 0 = success.

Forum Hero
Posts: 68
Comments: 8118

#6

Steve (OP),

There shouldn't be any issue having changed the name as long as it was done through the GUI - which it looks liek you did.  After changing the name, the next backup will always be a full (in 2019 and earlier at least).

I do see that one scheduled backup from your first log completed. Now that you've changed the name, just for grins, change the scheduled time to something in the near future (so you don't have to wait long) - let's say 2 minutes.  Then go in and re-pick the source and destination (for good measure, it can't hurt).  Then wait for the scheduled time to kick in and let's see what happens.

Also, just to make sure, you don't have the setting to only backup when the system is locked or anything like that, do you?  

Forum Member
Posts: 7
Comments: 48

#7

Bobbo,

Thanks for your reply.

The one scheduled backup in the logs was the original base before the name change.  From within the GUI, I deleted that base.  After that, I made the name change and then manually ran a new base.  From then on, the scheduled incrementals have failed but when I do them manually, they complete.

I am wondering if removing the original base has something to do with the problem?

Before your post (but as you suggested in it), I did go ahead and repick the source and destination and then save the backup plan as it seemed like the next logical step in debugging this.  Actually, I went through all of the backup plans settings and Ok'ed (lower right) them all just for grins.

I will see what happens on the next scheduled backup, but I will wait for its' real time and not push it forward.

Regards,

 

Forum Hero
Posts: 68
Comments: 8118

#8

Thanks for the update Steve!  I guess we wait and see if that helped or not.  As long as the original .tibx file name is still there (probably a 12KB), this script "should" continue to work.  

Forum Member
Posts: 7
Comments: 48

#9
Bobbo_3C0X1 wrote:

Thanks for the update Steve!  I guess we wait and see if that helped or not.  As long as the original .tibx file name is still there (probably a 12KB), this script "should" continue to work.  

I am still on ATI 2019 so there are only TIB files and not one big happy TIBX file as for ATI 2020.

Within the GUI, I removed the original base TIB file before renaming to remove the spaces.  What I am wondering is if removing the original base TIB file and then manually running a new base which created an new base TIB file is causing the problem.  Do you know the answer to this?

What do you mean by "this script"?

Thanks,

Forum Hero
Posts: 68
Comments: 8118

#10

The script = the backup task in the GUI, sorry for the confusion

No, I'm not sure of that exact scenario.  I don't think it would be an issue as long as the cleanup was done in the GUI and not directly in Windows File Explorer.  If done in file explorer, you would normally need to run a "validation" to get things back on track. I may have to play with this later though to see if I can replicate the behavior for you or not.

Personally, whenever a backup task goes wonky, I generally will just start with a new one to avoid any lingering or unknown problems down the road.  Unless it's a very big backup, or space is an issue, it's generally quicker just to start fresh with a new backup task than to try and make a failing backup work properly (unless they all have the same behavior and it needs to be troubleshot). 

Forum Hero
Posts: 68
Comments: 8118

#11

Testing now. I just deleted the originals in the GUI, renamed with underscores where spaces were and am waiting for some scheduled backups.  I set them to hourly and the next one is set to run in about 10 minutes.  I have to step away for a bit, but will post back soon.

Forum Member
Posts: 7
Comments: 48

#12

Personally, whenever a backup task goes wonky, I generally will just start with a new one to avoid any lingering or unknown problems down the road.

Bobbo,

Amazing, you read my mind all the way across the Internet!  If my next scheduled backup does not work, then I will start with a new one.  This is what I plan to do:

  1. Create an new folder in Windows Explorer on the external HD where I write my backups
  2. Copy the old bad backups TIB files into the new folder using Windows Explore
  3. Delete the old backup plan and backup files in the ATI GUI
  4. Create a new backup plan with the corrections that I did for the old backup plan
  5. Run the base manually just to get it done

I assume that ATI can load an old TIB set if it has been moved from its original location to a new location.  If my above procedure needs any corrections, then please let me know.

Thanks,

Forum Member
Posts: 7
Comments: 48

#13
Bobbo wrote:

Personally, whenever a backup task goes wonky, I generally will just start with a new one to avoid any lingering or unknown problems down the road.

Bobbo,

Amazing, you read my mind all the way across the Internet!  If my next scheduled backup does not work, then I will start with a new one.  This is what I plan to do:

  1. Create an new folder in Windows Explorer on the external HD where I write my backups
  2. Copy the old bad backups TIB files into the new folder using Windows Explore
  3. Delete the old backup plan and backup files in the ATI GUI
  4. Create a new backup plan with the corrections that I did for the old backup plan
  5. Run the base manually just to get it done

I assume that ATI can load an old TIB set if it has been moved from its original location to a new location.  If my above procedure needs any corrections, then please let me know.

Thanks,

Forum Hero
Posts: 68
Comments: 8118

#14

I assume that ATI can load an old TIB set if it has been moved from its original location to a new location.  If my above procedure needs any corrections, then please let me know.

Yes, it can be done via rescue media or the GUI.  However, if you want to use the GUI in Windows, the name needs to be different than any other currently active backups in the GUI (can't import a backup with a name that already exists).  Always try to use a unique name for new tasks if you are keeping old backups around. I will often just append something like _01, if I want to use the same name, but to make it unique.  And try to keep each backup task in it's own separate folder (just in case) - it makes things cleaner for your own management, as well as the application since it is relying on the name as well as the .tib.tis ID name associated with the task.

FYI, in my test, the automatic backup ran as scheduled.  I think I did exactly what you did to replicate it...

Created a new disk backup with names in the spaces.  Ran the first backup and a couple others (had to do those manually to get them going though).  I then used the "clean up versions" option and deleted all of the backups on disk.  I renamed the backup job to append underscores where blanks were and manually ran one backup.  I then let it do a scheduled backup and it worked as intended.  

Hopefully, yours will work too, after re-selecting the destination again.  If not, yeah, a new job should straighten things out.

-------------

On a side note, (sorry, so many threads in 2020 since it's new and all these bugs, plus hopping back and forth between 2019 and 2020 as people are having to revert back like you, so I'm losing track)... have you considered running SFC /Scannow on the OS too, just to make sure there are no internal OS issues (can't remember if you have or not)?

Funny thing... last week, I checked 3 different systems that I had upgraded to 1903 and all of them found errors with SFC /Scannow and I generally don't run into this type of issue very often - especially not on all of my computers at once!  I don't know if I'm just unlucky, or if a recent Windows 10 update has caused some issues -a one of these machines was rebuilt from scratch only about 3 weeks ago and I have been running SFC /Scannow on it about once a week just to keep tabs on it, but out of the blue, it had issues!  That same system, SFC couldn't repair so I ended up doing a chkdsk c: /f /r first and then followed up with 

DISM /Online /Cleanup-Image /RestoreHealth (which said it fixed things)

and then followed up with another

SFC /Scannow (which said it found issues and repaired them this time).

I then rebooted and did a 

DISM /Online /Cleanup-Image /CheckHealth (which said it was good)

followed by another 

SFC /Scannow (which said it was good).

True Image was working fine on all 3 systems even with these OS errors, but am thinking that they could easily cause trouble for backups if they exist.  And with having to hop back and forth from 2019 to 2020 and back, hopefully there's nothing else funky going on.

 

Forum Member
Posts: 7
Comments: 48

#15

Bobbo,

Thanks for the tip on running sfc /scannow which reported "found corrupt files but was unable to fix some of them".  I rebooted in Safe Mode to my admin account and got the same results.

It is late so I will deal with the next logical step tomorrow which is as you said, DISM /Online /Cleanup-Image /RestoreHealth.  This is a less than 2 weeks-old fresh install of Win 10 1903 on a new SSD using the Win 10 Media Creation Tool 1903 followed by a few standard Win Updates.  Because of how my old HD was failing I decided against any cloning.

We are getting a bit off topic, but I have a listing of the sfc errors with findstr /c:"[SR]" %windir%\logs\cbs\cbs.log > sfcdetails.txt as described in a few links.  Just for kicks, if you are seeing this on 3 computers, I would be curious if we are seeing the same corrupted files.

I'm going to sleep now.  See ya later...

 

Forum Hero
Posts: 68
Comments: 8118

#16

Steve,

Unfortunately, my cleanup seems to have fixed the issues on all 3 of them so I'm not seeing any errors in the logs as they only go back a couple of days.  I went back to some of my older backups on this machine and restored the logs from them, but I'm also not seeing the errors there either.  Like you, one of my installs was almost nearly brand new too - and that's what has been making me wonder if a Windows update (or something else we have in common) could be causing these issues.  On this particular machine, I have not updated to 2020 and have been using 2019 177550 for several months and had not seen the errors before.  I probably hadn't run SFC /Scannow for a couple of weeks though so I'm really wondering if one of the major patch Tuesday packages started these errors.  Honestly, I don't know if they have anything to do with potential issues in True Image either, but I figured we'd at least check on them and try to rule them out once they are fixed and a new task is running to see if it runs as expected, or not.  2019 has been running solid for me for quite some time.

Forum Member
Posts: 7
Comments: 48

#17

Hi Bobbo,

In the sfc logfile, the errors were in C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Defender\MSFT__*.cdxml which are part of Windows-Defender-Management-Powershell, version 10.0.18362.1.  There were a bunch of them, so I used the "*".  I did the same as you:

  1. sfc /scannow (which found errors but could not fix them)
  2. DISM /Online /Cleanup-Image /RestoreHealth (which said it fixed things)
  3. sfc /scannow (which found errors and fixed them now)
  4. reboot
  5. DISM /Online /Cleanup-Image /CheckHealth (which said it was good)
  6. sfc /scannow (which said it was good)

I ran sfc scannow on my other computer which is also running Win 10 1903 and no errors were reported.  This computer had a clean install of Win 10 in January 2018 after a BSOD and has only been updated on-line and not with the Media Creation Tool.

Tomorrow, ATI 2019 runs the scheduled incremental and I will see if it fails or is fixed.  If it fails, then I will just create a new backup plan.  I put all of my settings in a text file for reference just in case I need them.

Regards,

Frequent Poster
Posts: 141
Comments: 844

#18

I know that anecdotal "evidence" is no evidence, but ...

I got a new laptop a couple of months ago and used it with few problems in the ATI 2020 Beta test.  When ATI 2020 went GA I reworked some of my backup tasks and suddenly one of them failed every time it was invoked by the schedule but would work fine when manually started.   I changed the scheduling and it has worked fine ever since.

The task was originally scheduled to kick off at some early time (such as 01:00 AM) when the laptop was inevitably powered off.  The task would then get started by "missed operation" processing when I started the laptop ... and it would fail.  I changed it to "Upon event" "System startup with delay" and all is good.

This obviously says nothing about the original cause, provides a "solution" that would work only for a device that gets shut down every day, and has no guarantee of working even then -  too many uncontrolled variables.   So this is just a shot in the dark: try a different schedule.

 

Forum Member
Posts: 7
Comments: 48

#19

Hi Patrick,

I have encountered the same problem before that you have described:

The task would then get started by "missed operation" processing when I started the laptop ... and it would fail.  I changed it to "Upon event" "System startup with delay" and all is good.

Using the same solution as you, before, I have fixed it.  I don't think that this is the same problem.  I went through all of the settings in my plan re-saving each one of them.  Tomorrow when my backup runs I will know if this works.

Frequent Poster
Posts: 141
Comments: 844

#20
Steve wrote:

I have encountered the same problem before that you have described:

The task would then get started by "missed operation" processing when I started the laptop ... and it would fail.  I changed it to "Upon event" "System startup with delay" and all is good.

Hmm. Even if it is not your current problem, it sounds like there is a problem in both ATI 2019 and 2020 with "missed operation" processing. I'll dig into it a bit but not clutter up this thread with it.

BTW, "missed operation" processing usually works fine.

Forum Member
Posts: 7
Comments: 48

#21

Yes, I have seen that there is a problem with "missed operation" processing.  As I recall, I had to turn off this setting, save, run the missed backup manually, turn it back on, and then save again.  After the 2nd time that this happened, my work around was to just keep this setting turned off and do missed backups manually.