Skip to main content

linux rescue media Win10 boot disk clones always corrupted

Thread needs solution

Every Acronis 2018 linux rescue media clone (on each build) that I have performed on the Win10 boot disks of two systems has resulted in a corrupted destination disk. I've had a support ticket open for almost FOUR MONTHS on this, and (lack of) progress towards a solution falls way short of my expectations. I suspect I've been categorized as "that guy with the oddball problem we can't reproduce and nobody else has reported", so I'm fishing here to see if anybody else has experienced this same thing.

The clone operation appears to complete successfully with the status "success" dialog. However, looking at the clone log will show an error during the Universal Restore driver injection phase at the end of the operation, and subsequently running a chkdsk /F against the destination disk will show corruption that is not present in the source disk. The source boot disks also get a clean bill of health from sfc /scannow.

This only happens when cloning my Win10 boot disks, which triggers the Universal Restore driver injections. Clones of my non-boot RAID array genuinely complete successfully without log errors or chkdsk corruption. The 2017 rescue media clones these boot disks without any trouble, which is probably because it's not doing the Universal Restore injection, which I don't want anyway.

One of my systems in a custom-built desktop purchased last year with an ASUS X99 Deluxe II motherboard (UEFI). The other system is an old ASUS non-UEFI laptop purchased in 2010 but for which last year I replaced the internal HDD with an SSD and did a cold, fresh Win10 install on the bare SSD.

I have attached the following files from the most recent laptop clone test:

1) Screen shot of the "success" screen displayed despite the error in the clone log.

2) Screen shot of the clone log.

3) Saved clone log in XML format.

4) Output from running chkdsk against the clone destination disk, showing corruption.

Clones of the desktop boot disk also result in similar corruption, though the error in the Acronis log is different -- a parse failure of the DSDT table during the Universal Restore injection phase. But chkdsk reports similar corruption.

It is not a destination disk problem. I've used 2018 linux rescue to clone to multiple destination disks from each system and the corruption is there every time. I've used 2017 linux rescue to clone both systems to multiple destination disks and the corruption is NEVER there. Thus, 2018 is definitely buggy.

I use linux rescue media for offline cloning because I prefer fewer things that can go wrong compared to cloning a live system, or using WinRE/PE-based rescue media that can get pissy over duplicate disk signatures when cloning to the same destination disk that already has an earlier clone of the source disk.

I think most people would consider this to be an urgent problem when you have backup software displaying a success screen after having written a corrupted backup. Unless you are running chkdsk against the destination disk after cloning, you won't know you have a problem, and you will be potentially pretty screwed if you had to restore from an unknowingly corrupted clone.

If anybody reading this is doing 2018 linux rescue cloning of Win10 boot disks, please look at your rescue logs and run chkdsk on your clones to see whether this is happening to you too. Thanks.

 

0 Users found this helpful

I would suggest creating a stand alone True Image media without the Universal Restore module and try the clone again.

I have no idea why what you are experiencing is happening but getting UR out of the picture should surely help!