Bug - ATI 2020 Diff "cleanup versions" still results in corrupt recovery warning in rescue media
Same issue as 2019. This was really not possible to test in Beta 2020 because the manual option to "cleanup versions" was broken in beta 1 and not available at all in beta 2.
The "cleanup versions", in itself is working. I will say though, that for incrementals, you can only cleanup an entire chain and not just some incrementals (like if you want to only cleanup the very last one). This is possible in 2019 with the .tib format and incrementals.
The differential cleanup in 2020 worked exactly as I expected it too. That is, until I decided to see if I could then recover with it via rescue media.
The behavior is exactly the same in 2019.... despite a successful cleanup in the ATI 2020 GUI and a successful validation after that in the GUI, when using the rescue media, I am immediately prompted that the backup is corrupt and asked if I want to try anyway. I did not proceed - it will likely work (as it has in my 2019 tests), but this is a very bad message for users to be seeing if the cleanup was allowed in the GUI, and was successful, especially if the GUI validated the backup after the cleanup without issue too.
Steve Smith wrote:Worrying....! A much better / clearer message is needed here, not 'corrupt' with no rationale to say why?
Yes indeed!
The really troubling things (although the error is bad enough), is that the rescue media is looking at the entire backup chain to be considered "usable" here. For 1, a differential should never rely on an entire chain - it is the original full for that chain and only the specific differential file itself being used for the recovery that should come into play, nothing else.
And 2, no other version chain in that particular backup script should have any bearing on a recovery from another version chain - not in a differential or an incremental backup. Only the current chain should ever be considered for any recovery options in the Windows application or the rescue media.
Bobbol, what exactly did you delete? Was it just that last Differential backup? In that case, the entire chain would simply be one Full backup in a single .tibx file. Are there any other chains?
I did find when I was testing the beta that every time a new differential was written, the latest file before it would be modified in some way.
I deleted the 2nd diff in version chain 1. That left
Chain 1: full1, diff1 (diff 2 was cleaned)
Chain 2: Full 2, diff1
Which version were you trying to recover with the rescue media, Chain 1 or Chain 2? If Chain 2 is the most recent, and not the one in which there was deletion, are you able to ascertain whether there was any change to the file as a result of the cleanup?
I assume you recreated the rescue media with the released version.
It also seems a bit disingenuous to suggest that we try to recover data by mounting the image if mounting is not supported for .tibx files. Or is there a functioning Mount function in the recovery medium even though there is none in Windows ATI?
Yeah, new rescue media, with the new public release on a fresh install of it after running the cleanup tool, rebooting and installing ATI from scratch to remove traces of the beta.
I attempted to restore diff 1 in chain 1 and got the error.
I may need to go back and try chain 2 as well, but if memory serves me correct from my testing in 2019 and 2020 betas, you'll get prompted that the backup is corrupt, regardless of the file you pick to restore from once you've done any cleanup.
The funny thing is, if you attempt to recover via the Windows GUI, there are no warnings or prompts - just the rescue media.
Patrick O'Keefe wrote:It also seems a bit disingenuous to suggest that we try to recover data by mounting the image if mounting is not supported for .tibx files. Or is there a functioning Mount function in the recovery medium even though there is none in Windows ATI?
Good point. Nope, you can't mount in the recovery media :)
Hello Everyone,
this issue and this one too are currently planned to be fixed in the next Update 1 (scheduled for September).
Awesome! Both fixes will be a warm welcome! I can't wait for the bitlocker support in the rescue media and removing this error/warning in the rescue media will prevent a lot of anxiety for users! Thank you for the update!
Hey Bobbo,
I just noticed that, for a chain of differential, you have to select the main TIBX file when working in the recovery CD. If you select a partial file ...-0001.TIBX, ATI will tell you it is corrupt. After you have selected the main TIBX file, you can see the different recovery points.
Since the behavior is like what you describe, I just want to make sure that your error is displayed after you have selected the recovery point, not as your select the archive.
Thanks for the hint, Pat. That's not very clear, and unlock the behavior in earlier versions of True Image! I will test it out and see if that helps.
I can verify what Pat says. I believe this is because of all backup files of a chain being in a single container. If you drill into any backup file of a chain you will see the same data no matter which file you use to explore.
I think the main tibx file acts as a container of sorts that allows the recovery tool to locate all the data. I think you can copy and paste any data you want from any file in the chain but recovery is a bit different.
ATI 2020 rescue media should likely only search for the first .tibx file then, since it is always there. By following the older .tib procedures, users are prone to see that their backup is corrupt, if not, and be very frustrated!
It is a learning curve I'll admit. Maybe when the next build comes out this problem with the app saying the backup is corrupt will go away.
Bobbo_3C0X1 wrote:ATI 2020 rescue media should likely only search for the first .tibx file then, since it is always there. By following the older .tib procedures, users are prone to see that their backup is corrupt, if not, and be very frustrated!
+1 on that idea. It is very counterintuitive to select a file that has a timestamp older that other archive files.
Ekaterina wrote:Hello Everyone,
this issue and this one too are currently planned to be fixed in the next Update 1 (scheduled for September).
Looks like Bitlocker support is still broken in rescue media - wow. :(
And the manual "cleanup versions" is broken too, or at least it's not consistent now. I haven't done many of these tests. However, I successfully used "cleanup versions" to delete the first differential in the same backup task for each of the two chains. However, no file was actually deleted, but yet I got the confirmation both times they were deleted and the Activity Tab showed a success too!
The automatic cleanup is working as it had no issues deleting the first chain as scheduled, but manually using "cleanup versions" may not work correctly each time. This is a new bug in the new version as at least the manual cleanup worked before.
I closed True Image and re-opened it and sure enough it showed all of the files still there, even though the Activity Tab had shown them successfully deleted. I went back and repeated the process for both files again and this time I checked file explorer and verified they were deleted as they should have been - so it worked the second time, but resulted in 4 entries in the activity tab!
Getting back to the original issue... the rescue media is working better now with cleaned up files. I was able to successfully pick any .tibx file after the cleanup and did not get prompted that the backup is corrupt. Instead, regardless of the file I selected, it then presented me the date/option to recover from. That is great.
But, as a last "bug" issue (and this is not new to 2020)... if I start the recovery from the left-hand panel, I can't proceed with the recovery. It lists all of the files, but there is no option to select one and continue. Instead, I have to close that and use the top recovery tab to do this. It's been like this for as long as I can remember and quite frustrating as I'm sure others may get stuck not realizing that they have to use the top recovery tab instead!
