Backup fails with 'backup location was not found', but validation is fine...!

I have a simple backup job that takes full backups to an external disk.

After several successful backups over the last threee months, the job is now failing with:
“The last backup has failed. The backup location was not found on the destination drive. Make sure the correct storage device is connected to the computer.”

I run a Validate using the same backup job (from the ‘down arrow in ring’).

Validate works fine and red error mark o the backup job (and in the middle of the screen between source and destination) vanishes.

Excellent.

I run the backup job again. Fails with the same error!

The only clue I have is that when I last ran backups, version 1 (i.e ….b1-s1-v1.tib) was not present on the destination drive (I wouldn’t delete it, and chkdsk shows no errors; perhaps TI deleted it to keep within the disk-space rules I have set , but I also have told TI to ‘keep the first backup’; so where it has gone is a mystery). The validation that immediately followed gave me the option to ignore this first version, so I did. And subsequent validations has been fine.

I know that validation is supposed to bring the Acronis database of backups into sync with the actual backup files. And what TI thinks was the last backup (at the top of the screen) is displayed in the list of backup files when I ‘open location’ for that job. So everything looks OK but TI thinks otherwise.

After several successful backups over the last threee months, the job is now failing with:
“The last backup has failed. The backup location was not found on the destination drive. Make sure the correct storage device is connected to the computer.”
Validate works fine and red error mark o the backup job (and in the middle of the screen between source and destination) vanishes. I run the backup job again. Fails with the same error!

decomplexity, do you have the Log File Viewer app (link in my signature below), if so, what does this say about this problem?

Have all your backup tasks been pointed to the same external disk drive without any change of drives?

Have you considered creating a clone of the current task then deleting the original task settings before trying to run the cloned task?

What if you re-pick the source and destination again in your backup task? Does it then run, or give the same behavior. I'd try that first, and if no dice, try the clone settings featuer that Steve mentions up above.

Re Steve's question: "Have all your backup tasks been pointed to the same external disk drive without any change of drives?" I alternate two backup jobs (A and B) and two external disks (marked A and B), and I did check that I hadn't accidentally used backup job A to back up to drive B (each disk has a backups folder whose name includes the disk letter (A or B) to try to pre-empt this. (The disk with latest backup goes into a 'media' fire safe.)

I will pick the source and destination again as Bobbo suggests and see what happens.

If no joy I will clone the job.

If this doesn't work, I will define a new job (and let the existing backups sit where they are unti they are totally superseded

Clearly, there is a mismatch between which .tibs validate looks for and what backup looks for. And this should be impossible if Acronis was working consistently.

It could just be a spurious error when Acronis gets confused between teh job definition saying "keep teh first backup version" and it not being present!

Keep us posted with the results after resetting the source and destination drives again.

Be careful of Windows automatically assigning drives different letters too - this is common when using the defaullt assigned letter as it is usually D or E or whatever the next available letter is. This is a good article that explains the exact issue and how to resolve it.

If the drives share the same drive letter because they are usually not plugged in at the same time, but then get plugged in at the same time, Windows will assign a new letter to the last one plugged in and it will retain that letter (unless it gets bumpped further again). This can happen if you have another drive plugged in (say a flash drive) that picks up that letter by default and then you plug in the backup drive. It happens a lot more than you'd think and many users don't even realize it.

Because of this possibility, you might want to change your drive letters further down the alphabet where it's less likely to occur (for instance, start with N and make the other drive O - then re-pick the source and destination in your backup tasks and give them a whirl).

I will investigate. The error could be TI 2016's version of the the 2010 (and similar) error when if it could not find a drive at the setup driver letter would try to back up to C: (i.e. back up to the same disk). If is proves to be so, the present error message is at least an improvement on finding your system drive full of .tibs or - worse - having a hosed C: and finding that the backups you expected to use for recovery from an external disk werre not there!

It would not explain how Validate successfully finds the backups to validate, but stranger things have happened

Note firstly that the backup job is set up to use a folder on an external E: drive. Windows File Explorer agrees that the drive contains the desired folder containing the previous .tib versions

- select the failing backup job and run a validate with it. Result- OK (so it should be!)

- start a backup with the job. Result - fail ("The backup location was not found ...." - as before)

- redefine the Custom Destination to be exactly the same as it was (the log confirms this)

- start the backup job again. Result: Success!

Conclusion: the backup job can succeed on Validate and fail on Backup using the same job definition and without moving the external drive and a solution (for me at least) was to redefine the destination to exactly what it was.

Glad to hear it! I think we'll be seeing more of this behavior with windows 10 "upgrades". these upgrades are really full OS installs and it appears as though each install rebuilds the Windows Recovery parition, which may be changing the ID's of the drive and causing this behavior in Acronis. Doesn't seem to happen for everyone, but seems to be happening enough. At least it's not too difficult to go back in and reselect the source and/or destination as the exact same location again to get it working if this does happen after the Windows upgrade has occured.

We have True Image 2018 and the same issue is happening. I think I've determined that it occurs every time the computer is restarted - which isn't too often.

The backups and drives are located in the exact same area - no changes in assigned drive letters etc. If I reestablish the location (as the exact same) in True Image the backup will work fine again - until the computer restarts.

This happens to all six backup jobs. On Windows 10 with all updates to OS and software.

I have to say that I have not seen this behaviour as you describe it above - I have regularly rebooted my Windows 10 computers with ATI 2018 and have not seen any issue that required me to reselect the source or destination locations for any of my backup jobs.

The only time when reselecting such data has been needed has been after a Windows 10 upgrade when a new Recovery partition has been created which in turn can cause the partition ID's to change.

Assuming that you are seeing the same issue(s) are described in this topic thread, then the process for reselecting either the Source or Destination locations is the same as you would use for setting up a new backup task in the ATI GUI.

Select your problem backup task. Click on the Destination panel and reselect the same target location for where your backup files will be stored. If needed, do the same for the Source panel and reselect the source data to include in the backup.

Thanks. The UI isn't always obvious to me, but I do see how to change the destination now. I ended up cloning the job and that worked to get a back up last night. ETA:Pictures are worth a thousand words, and it can't hurt, so in case it helps someone else...

I have 3 separate, individual external disk drives connected via USB. Each drive is accessed by X:, Y: or Z:. In acronis I have 9 separate backups, 3 for each drive. My PC has 3 drives C,D,E. I will plug in x or y o Z, and execute the corresponding backup. i.e. if backing up to W:, I select the backup that starts with W~. As others have stated this used to work until I upgrades to acronis 16. I looked in support and did not see any way to file a report. I tried the FAQ, it had the problem, but no solution. cannot upload system report it is 9mb

John, not sure if you have made a typing mistake when you say you have 3 drives X:, Y: & Z: but then write about backing up to W: ??

Unfortunately there is no further support available for ATI 2016 as this has passed its end of support date. There is an option to use the Acronis Pay Per Incident support process but it is highly unlikely that any fix for ATI 2016 would be produced - more likely to be advised to upgrade to ATI 2018 (with no guarantee that this same issue would not be present if using the same backup tasks [from 2016]).

I can only suggest trying a new backup task to check that a simple, small backup can run correctly to one of your problem backup locations and if this is OK, then trying the Clone settings options for your existing task to duplicate each one in turn, and seeing if the new cloned task will run correctly too?

I'm using the latest version of TrueImage 2018 and there still is a problem! I have a permanently connected external drive and a drive letter that never changes but quite often my daily backup fails because TI can't find the last backup! This has been going on for weeks. I'll often get days without a problem then, bank, it fails. To solve it I've been deleting the backup job and re-creating it only for it to fail a few days later. I found a reference to the Storage\Volume ID on another forum thread and realised why the backup fails. Windows 10, in it's infinite wisdom, seem to change this ID every now and then. Now, when the backup fails I reselect the backup destination (exactly the sane drive and directory) and the backup then works.
Why does TI use this strange method of finding the last backup? What is wrong with using the drive-path?
This problem is going to persist until TI change the method of finding the last backup.
Many thanks to the writer of the MVP Log Viewer, without which I would never have figured this out!

Dennis, this is a known issue and circumvention. ATI records the destination drive unique ID in its internal database. My understand of why it does this is that some users could use multiple different drives which share the same drive letter - recording the drive UID means that only the correct drive can match the information held in the database.

This is fine until MS decides to issue a new Windows 10 Update such as the Spring 1803 one, then it also creates a new Recovery partition, and in doing these actions, the destination drive ID can also be changed. Reselecting the destination location is normally sufficient to correct things until the next MS Update!

Thanks for the reply. I still think it's a poor method of drive identification. Path, last backup, drive serial number combination, I would have thought, would provide an adequate identification of the used drive. I had thought of writing a small program to monitor any change in drive ID but trying some quick checks I couldn't find any Windows drive IDs that matched the ones TI was looking for. Now I know why!
Still, know that I know how to easily fix it I have a temporary cure!