Destination path is "wrong" by drive signature only.
Acronis True Image 2021 build 39287 on Windows 10 22H2 19045.2965 x64.
I replaced the local 6TB SATA hard drive backups were being saved to with an 8TB SATA local hard drive, just to increase space for other data being being stored on the same drive. Still had 2TB free on the drive, meaning I hadn't been hitting space limits in prior backups, no drive failure or corruption issues, etc. All data folders including the backup target folders were copied over to the new 8TB drive.
Backup fails citing that the expected destination path isn't available. Seems to be expecting the previous drive signature or GPT volume GUID. Fine, that's true, I didn't do anything to try and maintain the existing drive signature when replacing the hard drive. Replacement drive has been mounted as E: same as the drive it replaced had been mounted.
But going into Acronis True Image 2021 and re-selecting the destination path, or even temporarily choosing a different destination path and then switching back to the original intended path, doesn't correct the problem. Acronis successfully browses the "new E: drive" when letting me choose the destination. But after saving my new destination selection, Acronis True Image continues to report:
2023-05-16T04:31:40:745-04:00 25032 E000B0428: Error 0xb0428: The backup location was not found on the destination drive. Make sure the correct storage device is connected to the computer.
| trace level: error
| line: 0x4d3f22948e29f356
| file: c:\jenkins_agent\workspace\ati-main-win-ati\529\products\imager\archive\impl\utils.cpp:639
| function: TrueImage::Archive::CheckVolumeDeviceIdMatch
| line: 0x4d3f22948e29f356, c:\jenkins_agent\workspace\ati-main-win-ati\529\products\imager\archive\impl\utils.cpp:639, TrueImage::Archive::CheckVolumeDeviceIdMatch
| Path: E:
| ExpectedId: STORAGE\VOLUME\{5740BA3D-401A-11E7-A037-806E6F6E6963}#0000000008100000
| ActualId: STORAGE\VOLUME\{FE7D7262-F363-11ED-A574-806E6F6E6963}#0000000001000000
| $module: ti_demon_vs_39287
Note I'm not trying to "start my backup scheme over from scratch", but I will do that by simply creating a new backup task if it comes to that. Either by cloning the task or just re-creating from scratch.
I was just wondering whether anyone knew how to make Acronis believe "the new drive E: is the correct drive E:, and you should continue to use it" so that we just resume where we left off. Clearly USB drives and other removables have their own challenges here, but in this case we're just talking about a local SATA fixed drive.


- Log in to post comments

Thank you. That certainly makes sense. I invoked the "Move..." operation, and by default Acronis is already pointed to the correct and desired path on the E: drive. So I simply press OK to save that as the "new" location, and Acronis made some motions like it was saving it successfully, and it cleared the error off the screen of my previous failed backup attempt. But attempting to run the backup after using "Move" still resulted in the same error.
So I went through the "Move..." operation again, but this time used Acronis to cretae and select a new "Files.tmp" folder instead of the actual "Files" folder which was the current and desired location. Acronis actually did move the existing backup files (except for the "do not delete first backup" TIB, it seems) to the new "Files.tmp" folder.
But then I tried to invoke "Move..." to move the backup back to the intended "Files" folder and things got weird. Acronis would let me browse, select and save the original "Files" folder as the destination for the backup, but it never did actually move the TIB files back into that folder. And the message "Backup successfully moved to xxxxx" that would be presented kept confirming "Files.tmp" instead of "Files".
I started a backup anyway just to see what would actually happen, and the backup is running now, saving the new TIB to the "Files" folder (not "Files.tmp"). So all my previous TIBs are now under "Files.tmp" for some reason, but the backup is writing to "Files" again now as expected. So it's probably starting my scheme over from scratch I guess, since it doesn't have my previous TIBs in that folder, but "close enough."
- Log in to post comments

Alan,
Thanks for reporting back. Your description sounds a bit odd on actual handling of the Move command and, I must admit i have never used it to move to a new drive which may have something to do with the behavior.
Glad that things are working for you now nonetheless.
- Log in to post comments

Alan Adams wrote:Thank you. That certainly makes sense. I invoked the "Move..." operation, and by default Acronis is already pointed to the correct and desired path on the E: drive. So I simply press OK to save that as the "new" location, and Acronis made some motions like it was saving it successfully, and it cleared the error off the screen of my previous failed backup attempt. But attempting to run the backup after using "Move" still resulted in the same error.
So I went through the "Move..." operation again, but this time used Acronis to cretae and select a new "Files.tmp" folder instead of the actual "Files" folder which was the current and desired location. Acronis actually did move the existing backup files (except for the "do not delete first backup" TIB, it seems) to the new "Files.tmp" folder.
But then I tried to invoke "Move..." to move the backup back to the intended "Files" folder and things got weird. Acronis would let me browse, select and save the original "Files" folder as the destination for the backup, but it never did actually move the TIB files back into that folder. And the message "Backup successfully moved to xxxxx" that would be presented kept confirming "Files.tmp" instead of "Files".
I started a backup anyway just to see what would actually happen, and the backup is running now, saving the new TIB to the "Files" folder (not "Files.tmp"). So all my previous TIBs are now under "Files.tmp" for some reason, but the backup is writing to "Files" again now as expected. So it's probably starting my scheme over from scratch I guess, since it doesn't have my previous TIBs in that folder, but "close enough."
Hello Alan!
Thanks for sharing the workaround.
Cheers!
- Log in to post comments