ATI 2018 Archive Image Corrupt. *** RESOLVED ***’ worth the read.
I have read previous post that address this matter, but I am stumped and trying to find the answer. Ok, here we go...ATI 2018 FULL BACKUP and Validation passes. However, using the USB MEDIA to attempt restore the image file it says the backup is corrupt. ATI 2017 works and worked flawlessly in all regards from day one. Today, I found if I use the ATI 2018 startup interface I can restore the backup so the problems seems specific to the USB flash drive being created. I am not sweating this too much since my 2017 USB Flash drive works with the ATI 2018 backup boot interface and sees my NAS and files. However, it would be nice to know if there is a resolve to the issue. I have already submitted a support ticket and I have tested 3 different types of USB Flash Drives. All of them work fine in creation and boot with 2018, but they all report the backup is corrupt when obviously it’s not as reported by the 2017 USB Flash Drive. I even reinstalled ATI 2017 and recreated the USB Media with the same flash drives and EVERYTHING works fine.....just not the case with ATI 2018. Thank you for any suggestions.
Paul, welcome to these User Forums.
Out of interest what build version of ATI 2018 do you have installed and is this #9850, if so, have you rebuild the Rescue Media since updating to this latest build?
Personally, I haven't tested the default ATI 2018 Rescue Media as created using the Simple mode in the Media Builder - this is probably a little bit of laziness on my part, but is also by preference as I have been using the MVP Custom ATIPE Builder to create my USB Rescue Media and this has worked fine for me on both 2017 and 2018 (created using the ATI 2018 WinPE files and using the current Windows 10 ADK).
I did an OS partition recovery using my MVP USB stick last week with no mention of the backup being corrupt.
In reply to Paul, welcome to these User… by truwrikodrorow…
Steve, thank you for the reply and interest. I have build 9850 and I used both simple, advance,etc. to create the USB media. The Linux USB works fine, but prefer the WinPE. I also downloaded the MVP Tool and created a USB stick (sweet program by the way as I am no WinPe guru and saved a lot of time) but it also says the archive image is corrupt. I even created a backup both IN/OUT of Win10 and no change. I already had WIN ADK installed from previous Win10 studying, but I feel it must be ok since the meadia is getting created and works fine other than the fact it sees the image as corrupt. It’s obviously not corrupt since I can load and restore it using the Linux USB and the Linux Startup Recovery interface of ATI. I just don’t get it.
In reply to Paul, welcome to these User… by truwrikodrorow…
Steve, I have 9850 and yes I have recreated the USB Media using both ATI 2018 and the MVP WINPE Tool. Everything WinPE related says the image is corrupt, but all flavors of Linux USB and the ATI Startup F11 option works fine, the image cannot be corrupt. Hope this helps.
Paul, I would recommend opening a Support Ticket for this issue, especially as the image is not corrupt as evidenced by being able to restore using the Linux media but not with WinPE.
Where is your backup .tib image stored, what device and how formatted / how connected.
When you hit the image is corrupt message, have you looked at what the restore Log shows - you need to look at this while still active in the rescue media as is lost on restarting?
In reply to Paul, I would recommend… by truwrikodrorow…
Steve, backup file is on a WD NAS via 1gb network connection. I have no problem getting to it using either Linux or WinPE. There are no log files being created either, I have created a report and opened a service ticket 2 days ago, but no reply. I have removed WAK and downloaded the newsest version. I have Win10 1703, but I really feel none of that is relevant to the issue. I am walking through the meadia creation process preceded by a FULL format of the USB Flash, but gain I don’t think any of my efforts are going to resolve the issue. Thank you, Paul.
Paul, please reference this forum topic when you get opportunity to respond to your new support ticket, then Acronis will have more information from the dialogue found here too.
The only other suggestion to offer here would be to try the same backup file copied to a local / USB drive to test if the issue here is with the network connection handling in the new WinPE media?
My own restores have all be from local or USB drives, not from my NAS, so may not have been an accurate comparison to what you are doing here.
Steve, I will defined;y reference the forum. I have used the same WD NAS Drives for the past 3-4 versions of ATI without issue, but I guess you never know. I recreated the USB after updating the WDK and used the MVP tool. As expected it reports the image as corrupt. So, now I am backing up using the new USB Flash Drive, but creating the file on a different WD NAS. The WD Livenook/Mycloud Drives have never been ash issue before.....BUT since they use a Linux based system, maybe that is why my recoveries are only working with Linux, I also tested file/folder recoveries within ATI through windows and they worked fine. Anyhow, it’s not an urgent mattter, but surely the WD 3/4TB drives are coolmpatible with WinPE? I do thank you for your suggestions and hopefully tech support will have a resolve.
Update: I got it working, but not sure why this measure has anything to do with the issue. I found that if I select My Computer and then the drive mapping to the NAS that has my backup file, the WinPE USB will read and restore the image. I have tested this using both of my WD NAS Drives so all is well, but it sure doesn’t make any sense. The failure to recover due to the message of “image file corrupt” only happens when I was browsing to the option of MY NAS Drives in the interface. While I don’t see why the different outcome, it’s a success and I found my resolve. Thank You, Paul Porter and hopefully this post will help others.
Paul, glad to know that you have got this working though a mystery as to why choosing via the NAS option won't work correctly but going via My Computer does! Thanks for giving the feedback.
Paul...thanks for taking the time to troubleshoot , finding a solution, & providing feedback for the users.
I will see if I can duplicate the problem on my Synology NAS.
Regards,
FtrPilot
I do not have an answer for this issue but I am betting on this being a security issue with machine network session authentication.
I tested using my FreeNAS server. Booted WinPE from a machine that was shutdown directly to the WinPE media. I could navigate to the various backup folder locations on my FreeNAS server and supplying credentials was able to select these network share folder locations for backup targets which is what I tested first. I could complete all steps in creation of the the backup task however, when I selected Proceed with the task I would get an error that backup attempt failed. Insufficient privileges. I attempted several attempts even as far a logging on to the server as root, all resulted in the same error.
I then opened the Command prompt and ran net use z:\\servername\sharename /user:username password. This created a mapped drive Z: under This PC. Selecting that drive letter allowed a successful backup.
I then shutdown the computer. From a cold start I again booted into WinPE. This time I wished to test Recovery. I selected Recover in the True Image app, navigated to the backup I had just created in the previous step above providing credentials when prompted, selected it for recovery and then selected to recover files/folders from this backup which was a full disk backup. I then selected a folder with a few files and continued with the recovery. To my surprise the recovery ran to completion. No need to use a mapped drive letter at all.
After the recovery was complete I decided to try a full disk backup again to the same share folder. I setup the task and it ran without error.
I believe this to be an issue with security measures in place for SAMBA and an established network session. I would say had I waited for an extended time to perform my second round of tests they would not have succeeded because the network session established would have expired. I am going to test this theory further in a couple of days and will report back.
I am guessing here that a mapped drive to the network share will authenticate a net session for WinPE and that will last until it is reset or the session expires. Unfortunately I do not have the time right now to verify that. If I am correct here there is nothing that Acronis can do about this. It is a Microsoft network issue.
UPDATE:
After further testing on two different computers I found that in my tests ran above my failure was due to the fact that I had inadvertently tried to run the WinPE task to my NAS after the True Image app installed in Windows 10 OS on this computer had began a scheduled backup task to the NAS. The insufficient privileges error was the result. Looking at the WinPE log files which I always save showed that this task needed to be ended to begin the current task. Creating a mapped drive to the NAS worked around that issue I believe because I used a different network share for the mapped drive.
Conclusion: Users be mindful of other scheduled tasks which may be running and are not completed prior to booting to Recovery media to perform any task to a network connected share.
A few tips: When using WinPE keep in mind that there cannot be any spaces in share names as these do not resolve and you will get errors such as Cannot connect to specified location.
In some instances you may be asked to supply credentials more than once. If this occurs entering your credentials again should allow you to proceed with the task.
It should not be necessary to create a mapped drive to your network device to use Recovery media, either WinPE or Linux variants, to run a task to\from a network share. If you desire to use mapped drives that's fine but not necessary.
If share names fail to work in making connection substitution of the IP Address should resolve such issues. Example:
\\Devicename\sharename Alternative \\IPAddress\sharename
In all tests I was unable to duplicate the issue described by the OP in this thread. I will say that I expect there would be some changes in the Recovery Media with respect to WinPE variants to comply with SMB 3.0 security policies found in the latest versions of the WinPE packages. Whether or not that may be at fault here I cannot say but, I do suspect that might well be the case.