Skip to main content

Clone Source Drive Distroyed - Warning!!!

Thread needs solution

I have found a couple of posts on what happened to me, but it took awhile to find them.  I'm hoping my header might be more along the lines of what people search for and will find this....

 

After using the Clone tool for years on my notebook with no issues I went to clone the Boot Drive on my Desktop.  I didn't give it much thought, just grabbed an old drive the same size as the SSD that was installed.  I now know that there are issues with mismatched sector allocations on the drives.  THEY MUST MATCH!!!  This was not an issue with my notebook as I use two identical drives.

 

The issue is that the Clone drive didn't just fail, Acronis TRASHED my Boot Drive!!!   I find this totally unacceptable that they would modify the Source Drive in any way!! 

 

Luckily I have multiple backups and both uncompressed and backup copies of all of my User Data.  But the time to recover for this MAJOR BUG is rediculous.  I have used Acronis for years....   Maybe I should reconsider.

 

Hope this helps someone who is researchig before they actually attempt a Clone.

 

0 Users found this helpful

Pete, I have not heard of Acronis trashing the boot drive when doing cloning other than when users have made the mistake of selecting the drives incorrectly, which doesn't sound to be your case here.

Please see forum topic: [IMPORTANT] CLONING - How NOT to do this - which was written after dealing with many cloning issues in the forums.

If you still believe that you have found a bug in the Acronis Cloning feature of ATI 2018, then I would recommend using the Acronis Pay Per Incident service and submitting a ticket to Acronis for this.  If they agree that this is a bug, then the cost of your ticket should be refunded.

Was the clone started from windows and require a reboot to continue? If so, sounds like the bootloader got corrupted or failed to launch due to secure boot or driver compatibility with Linux.

This is why backups are always a good idea and recommended before cloning, even in the product documentation. 

Always safest to clone using rescue media and only after a backup is taken (just in case). I'm not sure the nature of trashed you experienced but suspect the bootloader was the issue and could be repaired.

1. Always backup first - safety net (as you found)

2. Always use rescue media to clone when possible to avoid windows reboot and Acronis bootloader change, as well as failure to boot from secure boot, driver incompatibility or other roadblocks

3. Always ensure the source and destination are correct so you don't reverse clone and wipe out the original drive

4. Never boot your system when there are 2 identical OS images attached (original and a clone) or the bios can change the bootloader on one or both drives and make them unbootable.

 

 

I did send a Feedback to Acronis on what I consider a MAJOR BUG and I do have multiple BUs.  So, in theory, I'll be able to recover - just a LOT of wasted time...  Thankfully my User Data resides uncompressed in multiple locations, so it took only a couple of minutes with Beyond Compare to get my notebook synced.

First attempt to recover gave me a slightly different but still non bootable drive.  This time I've wiped the C Drive vs. just trying to write over it.  In a little while I should know if that worked or not.

And I usually think of Linux being a more stable platform, but obviously not in this case.  So I created a new bootable WIN Recovery USB and that's what I'm using for this Recovery attempt.

 

Save the log of you can before it's done and save it to an external drive. 

Pete, thanks for the update - glad all is resolved at this time.

Yeah, I'm back to normal....   But it never should have happened. 

The issue using a non matching drive, especially since I *now* see it's a KNOWN ISSUE should either have a lockout error if attempted or a warning that the Destination Drive needs to be modified to match and there will be a much longer time to complete the Cloning. 

Really a shortcoming on Acronis's part.  (Management, coding or probably both...)

Pete, I would suggest submitting Feedback direct to Acronis with details of your concerns here about handling non-matching drives in a clone situation.

frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 250
Comments: 7092

PeteMc wrote:

Yeah, I'm back to normal....   But it never should have happened. 

The issue using a non matching drive, especially since I *now* see it's a KNOWN ISSUE should either have a lockout error if attempted or a warning that the Destination Drive needs to be modified to match and there will be a much longer time to complete the Cloning. 

Really a shortcoming on Acronis's part.  (Management, coding or probably both...)

Hello Pete,

I've discussed your case with the RnD and according to my colleagues, differences in sector allocation shouldn't be an issue, we've successfully cloned such drives in our lab. Would you mind sending us Acronis System Report via Feedback collected from the machine in question?  Or at least the models of the drives with the sector allocation used. We'd be very grateful for any information that will help to find the root cause of the issue.