Skip to main content

True Image 2018 9850 refuses to see my backup files

Thread needs solution

I'm trying to do an incremental backup and I'm getting an error saying TI can't find the backup file I've specified.  The job is called "BACHomeG" which points to

S:\Backup\BacHome\BACHomeG_full_b1_s1_v1.tib

S:\Backup\BacHome\BACHomeG_inc_b1_s2_v1.tib

 

This used to work as you can see I've previously made 1 incrementals.  Now all the sudden trying to do another incremental is failing.  In the backup options I've reselected both the source drive and the destination folder, yet it still refuses to see the previous backup files.

 

WIndows 10 1709

2 attached screen grabs

 

What can I do to get TI to see those files?  I've tried re-adding the backup but it still fails.

 

If I create an entirely new full backup job to the same destination folder, it works just fine, including subsequent incrementals.  Only my older backup jobs refuse to access the older backup files despite the files being present where they are supposed to be.

 

Attachment Size
BChastain2.jpg 164.06 KB
BChastain.jpg 427.64 KB
0 Users found this helpful

Bruce...did this occur as a result of a Windows 10 update?  Or possibly upgrading to ATI 2018?  Have you made any hardware changes to the S:drive?  True Image tracks the disk signature, not just the drive letter.  

Do any of the existing backups work? Or do they all fail?

There is a way to add them, but you probably won't like the answer.  If you uninstall ATI 2018 and then reinstall ATI 2018, you should then be able to add all of the backups...Yes, you would then have to reconfigure each of the backups.  However, the added backups would use the full and all incrementals, and the next backup would be an incremental.  Prior to the uninstall, you can save the backup settings, however, I have never done this, so I can't describe exactly how this works.  Steve Smith is an expert, you should wait and hopefully he will add some info.

Regards,

FtrPilot

 

 

Bruce, couple of suggestion along the same lines as from Randy above.

Try reselecting your task source and destination locations, then either retry the backup or do a Validation for the task and see if this succeeds or not?

Next, if you are considering doing an uninstall / reinstall of ATI 2018, then use the new option provided on the Setting page (gear cog icon) in the GUI and 'Save settings to file..' so that you can later use the 'Import settings from file..' option after the new install.  You will still need to do some reconfiguration of the task just to check all is as expected.

Before going that far, you may want to try forcing a rebuild of the Acronis Database files where information used by your tasks are stored.

To force a database rebuild, you need to first delete or rename the C:\ProgramData\Acronis\TrueImageHome\Database folder but this can only be done when no Acronis Services or Process are active.

To stop the Acronis Services and Processes, you need to do this in a specific order or else you will be chasing your tail..  Open the Services.msc control panel and stop all Acronis Services first, then open Windows Task Manager and end all Acronis programs shown there.

After deleting or renaming the Database folder, simply relaunch the main ATI application which will restart everything it needs and will create a new Database folder.

You will have lost all your task history detail but when you either run the tasks again or do a validation, this will start to rebuild / discover information from your existing backup files.

In reply to by truwrikodrorow…

FtrPilot, I did recently do the major fall update but it went smoothly and I both full and incremental backups since then.  So I don't think the update was the cause.

 

I did the ATI update prior to the Windows Update and it all went smoothly there too.  I did multiple backups after than upgrade.

 

No hardware changes.  My S: drive is an external Raid 1 USB box that I've had for years.  As best I can tell, it still works perfectly.  I also manually set the drive letters long ago and no changes there either.  I've NOT done any operations on the drive like volume renaming, drive letter, disk signature, partitioning, etc.  It should be exactly the way it's been for years.

 

The old backups seem to be a mixed bag.  Most no longer work with the same error message I posted.  Oddly, just a couple (also to the S: drive) do seem to start normally.

In reply to by truwrikodrorow…

Steve,

Boy, it took me about 15 minutes to figure out how to Validate a backup.  It hasn't finished yet as I type this but from the drive lights it seems to be running just fine so far.  It's a big file and I'll update if it fails.  So far no error messages.

I've had trouble in the past with ATI forgetting the destination from time to time.  Extremely intermittent and reselecting the destination always fixed it.  It was one thing I was hoping the recent update would fix.  Now reselecting the source and destination doesn't help.  Still the same quick failure message.  I don't know but perhaps it's the same problem but a slightly different error message and the circumvention no longer works. 

I've tried the database rebuild before I posted but it didn't help.  I couldn't figure out what services to stop so I booted to safe mode and that allowed me to toast it.  Restarting ATI rebuilt the files, but didn't help the symptom at all.

Bruce, if the validation doesn't help, then perhaps a Repair Install would be worth trying - this is simply reinstalling the full installer over the top of your existing program and let it repair anything that needs it.

Bruce, for additional information take a look at the script file for the backup. The file gets updated with each backup and the <volumes_locations> section should show the backup locations. See if something there is amiss.

In reply to by truwrikodrorow…

BrunoC, this is from a freshly created and full backup I did this morning:

                    <volumes_locations>
                        <volume_location device_instance_id="STORAGE\VOLUME\{D9ADB38E-B4F8-11E7-A589-F7A5D28B145D}#0000000000100000" uri="S:\Backup\BacHome\BACHomeH_full_b1_s1_v1.tib" volume_id="1432318976" />
                        <volume_location device_instance_id="STORAGE\VOLUME\{D9ADB38E-B4F8-11E7-A589-F7A5D28B145D}#0000000000100000" uri="S:\Backup\BacHome\@task@.tib" volume_id="0" />
                    </volumes_locations>

And this is from a failing one:

                    <volumes_locations>
                        <volume_location device_instance_id="STORAGE\VOLUME\{D9ADB38E-B4F8-11E7-A589-F7A5D28B145D}#0000000000100000" uri="S:\Backup\BacHome\@task@.tib" volume_id="0" />
                    </volumes_locations>

I note there is only 1 instance_id in the bad one but that might be a side effect of failing to find the file.  I've attached the script file.

One side note about the S: drive.  Due to it's size it's a GPT drive, if that's important.

Attachment Size
430610-140247.zip 1.81 KB

Sigh.  Repair install did not help.  I haven't tried the uninstall/reinstall yet because even if that helps, I'm sure it'll just come back again.

In reply to by truwrikodrorow…

The missing volume_location device_instance_id in the script seem to be the problem.  As best I can tell from the working and nonworking scripts is the working ones have at least one valid volume_location device_instance_id with the final path/filename filled in (not the ones with @task@ in it).  One working script has 8 of them, one for each backup (1 full and 7 incrementals).

As an experiment I copied a volume_location device_instance_id from a working script to a busted one, editing it slightly for the correct backup file name.  The busted one started working.

Armed with that, I played around with the Add Existing Backup feature.  When I tried it before it didn't help but this time it did.  I first deleted the busted backup which deleted the associated script.  Then I re-added it and it didn't recreate the script immediately.  Then I noticed the Backup button changed to Reconfigure.  Selecting Reconfigure is the trick that recreates and fills in the script.  That's probably what I did wrong before.  Anyway, it scans the files and adds all the needed volume_location device_instance_id fields, as many as needed.  Now the backup works correctly again.

So now I can repair the bad backups when they happen.  The remaining question is why ATI deleted all those fields.  I can't think of anything obvious that might have triggered that behavior.  All I can think of is the external USB raid box won't power itself back up after a power failure (unfortunate but they tell me it's intentional) and sometimes I don't notice it's still off.  I might have tried to start a backup with it still powered off and that triggered the bad behavior, but that's just a guess.

This also helps me because sometimes the scripts get out of sync with the backup files, for example when I have a bad Windows crash and I have to restore the c: drive from backup.  Now I know how to fix the script.

And yep, I realize deleting the backup toasts the backup settings too.  That's a good reason to manually fix the script instead of using Add Existing Backup.

Thanks for all the help guys.

Bruce, thanks for reporting on your results. It is good to know. Glad you are back in good shape too.