True Image 2019 deleting newly-created backup file
When I do a new single-version full backup to an empty directory, True Image 2019 creates a backup file as expected.
When I rerun the backup to the same directory, it creates a new backup file, deletes the old one, and then verifies the new one. I think it would be safer to verify the new file and THEN delete the old one.
When I rerun the backup to an empty directory -- something I did successfully with True Image 2018 -- it looks for an old backup file, can't find it, and creates a new backup file with the same name. Then it deletes the new file, apparently thinking it's deleting the old one that it couldn't find. The verification step, of course fails, and I'm left with no backup.
Whatever events led to the new file and the (non-existent) old file having the same name, I think True Image should have a fail-safe mechanism to keep it from deleting a backup file it has just created.
Steve Smith wrote:
Louis, welcome to these User Forums.
When I rerun the backup to the same directory, it creates a new backup file, deletes the old one, and then verifies the new one. I think it would be safer to verify the new file and THEN delete the old one.
I suspect that this is correct for a single version scheme as only one backup file is to be stored and validation has to be actioned against the new file.
It's not correct. Or rather, the right things are happening in the wrong order. The old file shouldn't be deleted until AFTER the new file is validated, and if the new file is invalid, the old file should be left alone. (Have you ever seen validation fail? I have, and it was due to bad memory.)
When I rerun the backup to an empty directory -- something I did successfully with True Image 2018 -- it looks for an old backup file, can't find it, and creates a new backup file with the same name. Then it deletes the new file, apparently thinking it's deleting the old one that it couldn't find. The verification step, of course fails, and I'm left with no backup.
The only time I have seen this type of behaviour reported is where there has been some form of corruption for the backup task or the internal database storing information for the task.
Try creating a new backup tasks with a unique name (not reusing a previous name) and check that this behaviour is no longer seen. If the problem continues, then I would recommend a clean install of ATI 2019 (uninstall the current software, run the Acronis Cleanup Tool (link below), restart the computer then reinstall 2019).
I uninstalled True Image, ran the cleanup tool, rebooted, and reinstalled True Image 2019. The problem persists. My guess is that the version number isn't being incremented when the old backup file is missing, the old (missing) file and the new file have the same name, and that is why the new file is being deleted.
This is a regression from True Image 2018, which didn't have this particular problem.
I'll stand by what I said earlier: True Image needs a fail-safe mechanism to ensure that no matter what goes wrong elsewhere in the application, it doesn't delete the backup file that it just finished creating.
Louis, if you are able to recreate this issue without manually deleting any files etc, then I would recommend opening a Support Case with Acronis and let them investigate this with you in more detail - you could then also raise the design issue with regards to how single version backup chains work in deleting the old file before validating the new one.
I opened Support Case 03457121 on September 1, before I posted to the forum.
The good news is that the latest maintenance release of True Image 2019 fixes the more serious problem of a newly created backup being deleted.
The bad news is that the (relatively) minor problem of an old backup file being deleted before a new one is validated is still there. My experience with Acronis Customer Central was frustrating; while everyone was very polite, I had the impression that nobody at Acronis tried to reproduce the problem, either on the version of True Image that I was running or on a newer one. A simple "Yes, it was broken, but now it's fixed" would have gone a long way to assure me that opening a Support Case was worth the trouble. For all I know, I would have been just as well off doing nothing and hoping for a maintenance release that would fix the bug.
The remaining deletion/validation problem probably won't affect me, but someone, somewhere will lose data some day. I'd be happy to report it, but how, and to whom?
The remaining deletion/validation problem probably won't affect me, but someone, somewhere will lose data some day. I'd be happy to report it, but how, and to whom?
Louis, the only mechanism for reporting any perceived or actual defects in the ATI code is by opening a Support Case (with all the attendant hoops this might make you jump through!).
You can submit Feedback using the tool in the GUI but this does not guarantee any action other than that someone at Acronis will review it along with all other feedback received.
I'm having the same problem with an interesting twist.
I have two drives to backup. I backed up the first drive, then the second drive.
After backing up the second drive, I noticed the first backup for the first drive had been deleted.
I then performed a Second backup of the FIRST drive.
I then noticed that the first backup for the second drive had been deleted.
W....T....F.....??
Acronis 2019, fresh install on Win10 Build 17134, ATI 2019 Build 14690.
Frank, welcome to these public User Forums.
I would request that you use the "Create New Topic" option and raise a new topic for this issue, then give us a lot more information to work with so that we can try to understand why you are seeing the behaviour you are reporting?
We need to know how exactly your 2 backups are configured, are these two separate backup tasks or are you trying to do this using a single task.
We need to see the log files for the backup tasks - you can use the MVP Log Viewer tool to access the logs - see link in my signature.
Thanks Steve, I will create a new thread, but I believe I figured out what happened.
When I set this machine up years ago, I cloned (using ATI) the original drive onto a second drive, and left both drives in the machine.
My default settings included the (non-default) option to clone the drive signature, so I wouldn't have to re-activate software (Quickbooks, etc.) that uses the drive signature as part of its activation process.
So, when I used ATI to back up these two drives, it believed that these two drives were the same drive, based solely upon the drive signature, even though EVERY aspect of the two drives (make / model / capacity / contents / etc. / etc.) was different.
As Acronis wrote the software that cloned the drive signature, you'd think they would do just a little more digging before assuming that two drives with identical drive signatures where in fact the same drive.
Thanks,
Franko
Update: I checked the drive volume ID's, and they are different:
Seagate 1 TB Laptop SSHD
Label OS Disk
E:\>vol
Volume in drive E is OSDisk
Volume Serial Number is BC1D-6A1D
E:\>f:
F:\>vol
Volume in drive F is Recovery
Volume Serial Number is 9D24-8A46
WD Black 750 GB
E:\>vol
Volume in drive E is OSDisk
Volume Serial Number is ECFA-A146
E:\>f:
F:\>vol
Volume in drive F is Recovery
Volume Serial Number is 90FC-2EB3
I even changed the volume names, then repeated the backups & confirmed that each backup deletes the previous backup file regardless of the origin:
Drive A's backup process deletes a backup of Drive B.
Drive B's backup process deletes a backup of Drive A.
I have created a support ticked & will create a new post when this gets resolved.
A workaround for this issue I believe would be to create different folders for the each backup. Combining same named backups from different tasks in a single folder has always been problematic with the product and that practice has been discouraged over the years as the belief is that it introduces corruption to the products internal task database.
Enchantech wrote:A workaround for this issue I believe would be to create different folders for the each backup. Combining same named backups from different tasks in a single folder has always been problematic with the product and that practice has been discouraged over the years as the belief is that it introduces corruption to the products internal task database.
Thanks Enchantech, I didn't include this info in my post above (and should have), but I did include it in the trouble ticket I created.
Each backup was saved to the \MyBackups\ folder on Different (internal, M.2 SSD) Drives.
I have two internal M.2 SSD drives, and each backup was saved on a different drive.
Thanks!!
Franko
Unfortunately this still may cause issue. The problem with your setup is that even though you are targeting 2 different drives you are using same folder names.
This I believe to be a problem because I believe that True Image no longer uses drive letters to identify destination locations.
Might I suggest that you create unique folders on both destination drives and try it out. If is works then at least you have found a workaround.
Thanks, I will give it a try & post the results.
Franko
Enchantech wrote:Unfortunately this still may cause issue. The problem with your setup is that even though you are targeting 2 different drives you are using same folder names.
This I believe to be a problem because I believe that True Image no longer uses drive letters to identify destination locations.
Might I suggest that you create unique folders on both destination drives and try it out. If is works then at least you have found a workaround.