Skip to main content

Cloning NVMe drives results in corruption

Thread needs solution

I have learned the hard way, that cloning to a NVMe SSD drive will result in corrupted data. As long as the destination drive is NVMe (it does not matter the source), it will result in apparent success. Both Linux and WinPE will do the same. The progress starts at just about 50% and it will finish the process rather quickly. It finishes as successful, but it is not. If you try to boot the operating system, it will not boot properly because of missing/corrupted files. I have tried this approach on different computers, and the outcome is always the same. 

It happens with build 35860 as well. This is very annoying, and I am currently using a competitor's software to clone to NVMe because Acronis True Image will not do its job properly.

If the source drive is NVMe and destination is AHCI it will work fine though.

0 Users found this helpful

Joaquim, welcome to these public User Forums.

Sorry but more information is needed to better understand the procedure that you are following when doing any cloning of NVMe drives?

Are you using the Windows ATI 2021 application to do the clone along with the Active Clone feature?  If so, how is the target NVMe drive being connected to the PC?

Are you using the Acronis Rescue Media to boot the PC to do the clone?  If so, how is the target NVMe drive being connected?

NVMe normally requires UEFI / GPT when being used for Windows boot drives, so the PC being used for cloning should be booted in UEFI boot mode.

I am using Rescue media to boot and clone. Target NVMe is inserted into M.2 internal slot. The source disk can be an internal SATA drive or can be connected via USB adapter, it does not matter, outcome is the same.

It is not an issue of non booting, but an issue of corrupted/incomplete clone. System boots and then BSOD, because of missing/corrupted files. And Acronis rescue media progress starts at about 50% which is odd.

Same computer setup work perfectly when using competitor's software (like AOMEI Backupper or EeaseUS Todo Backup), the disks are cloned perfectly.

The reported issue is reproducible with bot Linux and WinPE rescue media.

If I were you I would scan both source and target disk using chkdsk to see if any errors are found.  Acronis True Image checks disk and file system integrity prior to clone or recovery.  I have no idea if competitor products do or not but I have a feeling they do not.  I say that because I have seen other reports like yours comparing ATI to other products and even earlier versions of ATI saying that ATI produces errors and the comparisons do not.  Error checking is relatively new to ATI so it is a shock when a user finds that his/her disk(s) are corrupted in some way which is preventing ATI from performing the requested operation.

Hi Joaquim. This is not helpful sorry, but I can confirm that I have the exact same results.

I have used ATI for years with success but it won't work between any M.2 NVMe drives. I even upgraded to 2021 to see if that would work but no success.

We are an all HP workplace and I regularly upgrade hard drives by using ATI to create an image on an external USB drive, then restoring to the new (larger) drive from that USB drive. It just doesn't work now.

I am doing a UEFI boot from an ATI 2021 USB boot drive as UEFI.

Is there a possibility that Acronis could look at this? It seems like a software fault to me.

 

Roger.

Just a cross reference to a post I made in the 2020 forum based on ATI 2020 where I documented my own experience in upgrading the 128GB Liteon NVMe M.2 SSD supplied with my HP Omen laptop to a new 500GB Samsung 970 Evo Plus NVMe M.2 SSD including screen images capturing the steps.

See topic: Help with cloning single drive...

I have not needed to repeat this process since upgrading to ATI 2021 but have no concerns that it should not work if needed.

On a note of caution, I would only do a further test by using a second, spare NVMe drive, with the current working SSD stored safely!  This is primarily because this is my main laptop that I use continually and if any problems did show, I would have the original SSD ready to get back into the working state again!  I only have this one laptop that has an NVMe drive else would be happy to test on a less important PC!

If the source drive isn't NVMe and the destination drive is, there will be a problem. NVMe drives have a built-in controller in the drive. Windows has a native NVMe driver available in its driver file repository. This means when a booted Windows system sees an NVMe drive that driver is automatically installed and the drive is recognized. That native driver isn't available at boot time unless it has previously been installed. Therefore, NVMe drives cloned or restored from a non-NVMe source don't boot.

The fix is to inject the needed NVMe driver into the cloned or restored system. This can be done with Acronis Universal Restore or simply be using dism.exe from a command window to add the driver to the offline system.

Another solution is to let the source system see an NVMe drive before it is cloned or backed up. That way the NVMe driver will be installed and available at boot time in the cloned or restored system.

Hi Mustang, Thanks for that. Lately I've been trying to do NVMe to NVMe and that hasn't been working. I pass some of our old PC's to workshop staff but before doing that I upgrade from a HDD to an SSD and that works fine but I think you are right, almost always those older units don't have NVMe so I haven't been striking the driver issues. It's only more recently that some users (we use a lot of VM's for industrial automation) are running out of space and need upgrades. 

 

Steve, I hadn't heard of the MVP tool so I think this may be the way forward. I'll give it a try and get back to you.

You can also have problems with NVMe to NVMe if the target is in a USB drive enclosure. True Image has a built-in Universal Restore component that can be triggered without the user's knowledge. This can ruin the clone. You have a better chance of success if the target is installed on the motherboard and the source is in the USB enclosure if both can't be installed on the motherboard.

My last attempt was just that. Source was NVMe inside USB case (Jmicron controller bridge) and the destination was in the internal M.2 slot. Exactly the same outcome. What is even stranger is the progress bar jump and the clone operation ends quicker than expect for the amount of data. Was finished as sucessful. With exactly the same setup I was able to clone perfectly with competitor's solution. I am not saying that competitor's are better, they just work

About lack of NVMe driver cloning from SATA, Windows 10 will see that hardware has changed and will install driver during boot (you will see a new device being installed info while booting).

I started this topic not to ashame Acronis, but to alert to this issue, and hopping for a fix. I like this software, and have  have been using it for years sucessfully.

 

 

Cloning NVMe drives results in corruption

cloning to a NVMe SSD drive will result in corrupted data

As long as the destination drive is NVMe (it does not matter the source), it will result in apparent success.

If the source drive is NVMe and destination is AHCI it will work fine though.

Is it just me or does anyone else see any contradictions in this? Also, comparing NVMe to AHCI is like comparing petrol to DOHC. They are not comparable.

Is the NVMe device being cloned or cloned to, which is it? These details are important to make any kind of meaningful argument about this or that.

Have you considered making a disk image of the source disk and restoring it to the target disk? I'm not sure if I have used the "clone" feature of Acronis True Image. But here I am, typing away on a system that's supported by a Samsung 970 EVO Plus NVMe disk that's connected to the M.2 slot. What I do know for sure is that I did not have to reinstall Windows 10 or any of the software. I migrated from a Samsung 850 EVO (SATA SSD) to this disk (PCIE/NVMe SSD), and as I recall it, I did a normal image restoration.

For the record, my system runs on UEFI and Windows 10 was (with 850 EVO still in use) and still is installed in UEFI mode. I have not experienced any major issues with my current Windows 10 installation. I can't even recall when I had a minor issue with it. And I certainly don't recall not being able to boot it or throwing a BSOD at me.

I migrated to 970 EVO Plus about 2 years ago (March 2019 it would seem). So I did use True Image 2020 back then, I believe, or the one before that. I definitely did not use True Image 2021 as it was not released yet.

So for what it's worth, you might want to consider doing a normal image backup and restoration.

For what it's worth, I did a number of tests yesterday using NVMe source to NVMe target. I don' have a USB enclosure that holds NVMe drives, so I tested with both NVMe drives in motherboard M.2 slots. I did both cloning and backup/restore testing. I tested both with Windows live clone and cloning from the WinPE recovery media. All me tests worked. After each clone or restore I removed the source drive before attempting to boot the target drive. All my test but one resulted in Windows booting on the first try. All the tests were done booting the clone or restored drive on the same computer as the source system. The one clone that failed to boot was done by selecting the third cloning option to clone as a data disk. I only tried that for fun to see what would happen. It resulted in a required device is missing BSOD. I was easily able to fix it by correcting the BCD file from WinPE.

The progress bar during the cloning process is very different than it is during a restore. It only gets to about 50% when all the data on the drive and the message says synchronizing with the operating system. It says there for awhile and then jumps to the end. The cloning process is very fast compared to a restore. It's amazingly fast.

If the clone doesn't boot, it's not because the data is corrupt or incomplete. It's either a problem in the BCD file not pointing to the Windows partition, a missing driver for the hard disk controller or an incorrect BIOS setting.

I rarely use the disk image feature to backup or restore, but if Acronis does supports cloning, it should work right?

Like I said before, same hardware setup, same settings, and cloning from both EaseUS Todo Backup and AOMEI Bakupper results in success. By sucess I mean a working destination NVMe drive, that boots perfectly.

Never selected the option to clone as data disk, always as a replacement disk in the same computer.

I also did clone from an NVMe SSD to a AHCI SATA SSD, with Acronis, and the clone works perfectly. It only fails when destination is NVMe. Also, the destination drive (NVMe) in all my tests was connected to an internal M.2 slot.

@Mustang, please do test with Linux rescue media if you do not mind. I only care about cloning feature, do not bother the backup/restore disk (using image), maybe that works, but to me it takes double the time, that I can not waste. I do clone alot of disks professionally, I require reliable software. And Acronis has been reliable, except for this NVMe issue.

 

Thanks for you valuable input Paul.

I tested both with Windows live clone and cloning from the WinPE recovery media.

By live clone, do you mean the "Clone Disk" option under Tools in True Image? I'm not very familiar with these extra features, and I don't think I have used it before. I believe I just made a fresh disk image and then immediately restored it when I migrated from my SATA SSD to my current PCIE SSD (NVMe).

After each clone or restore I removed the source drive before attempting to boot the target drive.

Leaving you with only one drive in the system I presume. This is a very good point! This way you know for sure that this is the one that's booting up.

I personally sometimes disconnect all but the target drive when installing Windows. It makes it easier for me to navigate and use partitioning tools when there i no more than one disk or partition in the system. It also helps me stop Windows from doing unintended things like scanning and testing my drives during installation or immediately after when the installation is being finalized. It also prevents it from putting its temporary files on drives other than the system drive (pooping all over the place just because there is a big gaping empty space is an old habit of Windows systems and they never ask for user consent).

All the tests were done booting the clone or restored drive on the same computer as the source system.

This is also a very important detail that should not be left out, when describing the problem and if we want to get to the truth.

For one, when I migrated from one type of SSD disk to another, I did so on the same system/hardware. The disk is all that changed. Had I cloned the SSD of one system to be used in another system, I don't know if that would have worked at all. I think it may have required additional drivers that are specific to the target/destination system, which is what we should be able to use the Universal Restore feature for. That is, when doing a normal restore of an existing backup. If we have made a clone instead of a backup & restore... well... I'm not so sure Universal Restore can help in that case. But frankly Universal Restore was not intended for that use case, so it would not surprise me if it failed to be useful in that situation. Normally, when people clone their disk, they do so with the intention of migrating all the data off that disk to a new, bigger and faster disk. On the existing system. Not to migrate from one system/hardware to another (that's where Universal Restore can be useful).

Expectations need to be set right from the beginning.

The one clone that failed to boot was done by selecting the third cloning option to clone as a data disk. I only tried that for fun to see what would happen.

That's expected. So that's also good and useful to know, it means our theory is solid.

The progress bar during the cloning process is very different than it is during a restore. It only gets to about 50% when all the data on the drive and the message says synchronizing with the operating system. It says there for awhile and then jumps to the end. The cloning process is very fast compared to a restore. It's amazingly fast.

Well, percent is a relative measure of some amount or quantity. The progress doesn't have to look smooth and consistent like sand in a hour glass. But if it goes like, 0%, 1%, 2%, ... , 50% and then all of a sudden jumps to 100% then it sounds to me like there should be more than one progress bar. One for the overall cloning task and one for any sub task.

Did you take time? How long did it take to restore vs. to clone? I believe I only restore a system disk image onto my new drive, and that was fairly fast. But if cloning is significantly faster then there may be merits to choosing that over a regular backup and restore. Otherwise I would always go for a regular backup and restore. What other benefits are there to cloning? You get a fully functional system or boot drive either way you go.

I think the main reason that people seek to "clone" a disk is because the term has become somewhat mainstream with the availability of cheap SSD drives/disks and the number of people moving away from mechanical drives and installing SSD disks in their machines (mainly laptop users). So the big SSD brands like Samsung, Kingston and Intel that sell "retail" packages of these disks bundle them with simple kits consisting of a USB to SATA adapter cables and software for making the transition or migration friction free (removing the heavy lifting of reinstalling Windows and all the software). In some examples, that software is in fact Acronis True Image, but under a different name (rebranded). But there are others also of course.

There is nothing special about a cloned disk. Nothing that can't be done with a regular backup and restore using True Image? Or am I missing something?... I mean you get your data, you get your partition tables, you get your boot sector... what else is there to it? With True Image, you can even go crazy and do byte for byte backup and include unallocated (empty) space in your backup if you feel like doing something fancy.

If the clone doesn't boot, it's not because the data is corrupt or incomplete. It's either a problem in the BCD file not pointing to the Windows partition, a missing driver for the hard disk controller or an incorrect BIOS setting.

There are certainly many possible explanations for a computer that fails to boot. One thing that jumps at me is that the boot manager may go under the name of "GRUB" and has been forgotten on a different disk drive. As in not included in the cloning process. As in computer not knowing how to boot into Windows that's on the cloned drive. This would help explain why the booting process normally works as expected, but fails to do so once the cloning is done. I'm just speculating of course, but the term "Linux" did come up. So I started thinking "multi boot" but the "Linux" reference may have been used only to indicate what kind of OS was used for the Acronis "Rescue Media". It may not be the case here, but it's totally possible to have a situation like that. Which is another reason to consider disconnecting disk drives you don't need (or you think you don't need) during Windows installation, or during a cloning process as well.

I rarely use the disk image feature to backup or restore, but if Acronis does supports cloning, it should work right?

It should, and it sounds like it does. Except when it fails to do so. Are you sure the cloning feature supports NVMe devices?

Never selected the option to clone as data disk, always as a replacement disk in the same computer.

The resulting clone, does it contain anything? Any files on it? I understand that it is unbootable, but you also said it's corrupted. So do you have anything useful on it, like files you can open?

What is the name of your NVMe SSD?

Do you have an UEFI system and is UEFI fully enabled (no CSM)?

Have you tried a different M.2 slot if you have more than one?

What we know so far:

  • Cloning NVMe SSD boot disk to SATA SSD results in a bootable SATA SSD.
  • Cloning SATA SSD boot disk to NVMe SSD results in unbootable NVMe SSD.
  • NVMe SSD is connected to internal M.2 slot.
  • Same results with Linux based and WinPE based Rescue Media.
  • Cloning SATA SSD boot disk to NVMe SSD using EaseUS Todo Backup or AOMEI Bakupper results in bootable NVMe SSD.
  • True Image 2021 build 35860 was used for testing.

 

Samir,

Thank you for your very detailed analysis and thoughts. I'll try to address some of your points and questions. Let me start by saying I would never use cloning in any of my own work. I highly prefer backup/restore. I only use cloning to test the software and to try to help other users who do prefer cloning. I've come to realize that a high percentage of TI users are relying on cloning as a backup solution for the speed and convenience involved.

1. You asked about the term "live clone". It means cloning a Windows system while it is running using VSS in the same way as a backup is done from within Windows. This only works if the target disk doesn't have an operating system on it. If there is an existing Windows system on the target disk, TI will require a reboot into the recovery environment. The Linux recovery environment is used. The other option is to boot into either the WinPE or Linux recovery environment (user's choice) and do the clone. And, yes the cloning option is found in the TI main GUI under the Tools section.

2. Booting with only the cloned drive in the system can make a difference for a few reasons. UEFI firmware can write changes to the BCD file in the EFI system partition. It attempts to make corrections. When there are two or more Windows UEFI/GPT systems present, the BCD is often changed to boot from the EFI partition on a different disk. System A could be booting from the EFI partition on System B. This is one of my pet peeves with modern UEFI computers. The user never knows this is happening because most of the time if System B is removed, the UEFI firmware will correct the BCD and tell System A to boot from the EFI partition of System A.

Another reason is that UEFI firmware has a problem when it sees two disks with the same disk signature. This will not normally be a problem. True Image will not change the disk signature on the target drive to match the signature of the source drive. This would only be a problem if the source and target disk had the same signature before the clone was done. This is one of the biggest misconceptions in this forum. People think a clone is an exact bit for bit copy of the source disk and therefore has the same disk signature. This is NOT NOT NOT the case! 

3. I specified that I was booting the cloned disks on the same computer just so users would understand that some of the cloning problems like missing drivers and different BIOS setting were not in play in my tests. I was just trying to show that True Image cloning is working for NVMe to NVMe.

You mentioned Universal Restore. It is intended to make a system bootable when put on dissimilar hardware. This should work equally for both restored and cloned systems. The main job of Universal Restore is to provide the opportunity to inject hard disk controller drivers for the new system that were not present in the old system.

4. Cloning a Windows OS disk using the "clone as a data disk" option did indeed have the expected result of the clone not being bootable. I can tell you this was interesting because I did leave the source disk connected when I first booted the cloned disk. To my surprise Windows booted right up. I discovered that the BCD for the cloned disk was telling Windows to boot from the Windows partition of the source disk. That explained why it booted. When the source disk was removed, the cloned disk did get a BSOD as expected.

5. I agree with your comments about progress bars in general. I just wanted Joaquim to know that what he saw during the clone operation was normal and didn't indicate there was incomplete or corrupt data on the clone.

I didn't actually measure the clone time versus the restore time. My feeling was that the clone time was about 1/2 the restore time.

6. I would assume that Linux here is only referring to the use of the Linux recovery environment. Certainly, dual boot Windows/Linux system provide additional problems not even being considered in this thread.

Thank you for your detailed answer Paul. I do like details, and I like numbers. As the old saying goes, the devil is in the details!

Big thank you for going out of your way to do these tests! Your own tests also support the idea that True Image 2021 does indeed fully support cloning of NVMe disks (to and from). I wish I could do a test of my own as I do have at least one NVMe disk to clone to, but it's not something I can easily do at the moment.

I can see why people would prefer cloning over image restore if cloning takes half the time. It makes me wonder how is it able to do that? What is it compromising on to achieve this? It is very interesting. I believe Clonezilla is preferred over backup software for the same reason. Doing the same work in half the time is very appealing to anyone (should be). Assuming of course it does work in the same way and give us the same result.

If there is an existing Windows system on the target disk, TI will require a reboot into the recovery environment. The Linux recovery environment is used. The other option is to boot into either the WinPE or Linux recovery environment (user's choice) and do the clone.

Now that you mention this, I do recall having trouble with one of my disks missing when I boot into Recovery Media. It might have been the NVMe disk. I know I had to download and install a truckload of Windows components to be able to build my Recovery Media using the WinPE option. After that it worked as expected. This was a long time ago now, but it was something related to missing drivers. This is a very common problem when new technology like NVMe is first introduced. In my experience, support for it is often introduced faster in Windows systems than in Linux systems. You can relatively easily get the latest drivers if you go for the WinPE option, but for Linux based Recovery Media... well... I'm not sure how you would go about updating the kernel or installing extra modules to add NVMe support. Since True Image 2021 is as new as it gets (regardless of build number) it should come prepared with newer Linux kernel that supports NVMe out of the box. I'm defending the use of Linux based Recovery Media. But it should be noted that WinPE is probably going to be the better option for a piece of software that's born out of the Windows OS.

Another reason is that UEFI firmware has a problem when it sees two disks with the same disk signature. This will not normally be a problem. True Image will not change the disk signature on the target drive to match the signature of the source drive. This would only be a problem if the source and target disk had the same signature before the clone was done. This is one of the biggest misconceptions in this forum. People think a clone is an exact bit for bit copy of the source disk and therefore has the same disk signature. This is NOT NOT NOT the case!

I'm a bit confused. So you're talking about the GUIDs as used on GPT disks? These are not transferred over to the target disk when cloning? Not so much globally unique... hmh... very interesting. I'm not sure how you would arrive then in a state of having two disks with the same GUID...

I specified that I was booting the cloned disks on the same computer just so users would understand that some of the cloning problems like missing drivers and different BIOS setting were not in play in my tests. I was just trying to show that True Image cloning is working for NVMe to NVMe.

I understand, and I appreciate your effort and attention to detail.

You mentioned Universal Restore. It is intended to make a system bootable when put on dissimilar hardware. This should work equally for both restored and cloned systems.

That's good to know. I have not used it in the context of cloning, so I didn't know.

Cloning a Windows OS disk using the "clone as a data disk" option did indeed have the expected result of the clone not being bootable. I can tell you this was interesting because I did leave the source disk connected when I first booted the cloned disk. To my surprise Windows booted right up. I discovered that the BCD for the cloned disk was telling Windows to boot from the Windows partition of the source disk. That explained why it booted. When the source disk was removed, the cloned disk did get a BSOD as expected.

Ha ha, that's funny. The only thing worse than that is unexpected BSOD. But yeah, that's another reason to disconnect disks you don't need ("or you think you don't need").

 

There is something seriously wrong with Acronis 2021.  It will not clone a Windows boot disk from a Nvme system drive to another Nvme drive on an Asus Prime x570 Pro.  The cloned drive will not boot.

However, Acronis 2018 will clone a Windows boot Nvme drive to another Nvme drive.  The clone drive will boot.

Acronis needs to update Acronis 2021 with the old code from 2018.

Joh H

 

That is a good point. I never tried an older version, and I was afraid NVMe support was not there, in such an older release. By the reports we are getting here, I am not the only one having issue with NVMe cloning...

This is starting to get interesting now...

Case 1 – Joaquim:

  • Cloning a NVMe SSD boot disk to a SATA SSD disk
    • using True Image 2021 (build 35860)
      • Linux based or WinPE based Rescue Media
    • results in a bootable SATA SSD target disk.
  • Cloning a SATA SSD boot disk to a NVMe SSD disk (internal M.2 slot)
    • using True Image 2021 (build 35860)
      • Linux based or WinPE based Rescue Media
    • using Samsung 970 Evo Plus or
      • HP EX900 or
      • WD Black SN750 or
      • Kingston A2000 as target disk.
    • results in unbootable NVMe SSD target disk.
  • Cloning a SATA SSD boot disk to a NVMe SSD disk (internal M.2 slot)
    • using EaseUS Todo Backup
    • results in bootable NVMe SSD target disk.
  • Cloning a SATA SSD boot disk to a NVMe SSD disk (internal M.2 slot)
    • using AOMEI Bakupper
    • results in bootable NVMe SSD target disk.

Joaquim, we still don't know what NVMe SSD disk was used?

Case 2 – John:

  • Cloning a NVMe SSD boot disk to a NVMe SSD disk (internal M.2 slot of Asus Prime X570 Pro)
    • using True Image 2021
    • results in unbootable NVMe SSD target disk.
  • Cloning a NVMe SSD boot disk to a NVMe SSD disk (internal M.2 slot of Asus Prime X570 Pro)
    • using True Image 2018
    • results in a bootable NVMe SSD target disk.

John, can you post the build number of both the versions you used? Also, what was the target NVMe disk you used?

Contradictory case 1 – Paul:

  • Cloning a NVMe SSD boot disk (internal M.2 slot) to a NVMe SSD disk (internal M.2 slot)
    • using True Image 2021 (build 35860)
      • Windows live clone or WinPE based Rescue Media
    • using Samsung 950 Pro as target disk
    • results in a bootable NVMe SSD target disk.

Paul, what was the target NVMe disk you used? Also, can you post the build number of your True Image?

 

Samir:

True Image 2021 build number 35860. The target NVMe disk was a Samsung 950 Pro.

 

Samir: I used different drives, like Samsung 970 Evo Plus, HP EX900, Western Digital Black SN750 and Kingston A2000. 

A further question here:

Do the source NVMe SSD's come from the same PC as where the cloning is being done?

If not, then I would suspect differences in the hardware between the cloning PC and the source PC is resulting is different drivers being used, i.e. to match the hardware in the cloning PC.

My own approach on the rare few times I have used cloning would be:

First install the new NVMe drive in the target PC (assuming migrating from a SATA drive) and boot with this new drive left as not initialised to allow Windows to find the new hardware and install any drivers needed.

Next to clone from the SATA drive to the new NVMe, initialising via the Add new disk tool.

Finally, shutting down, removing the SATA drive and test all is ok booted from the NVMe drive.

I have no PC's with multiple NVMe PCIe slots to allow a clone from NVMe to NVMe, and likewise I have no external USB adapters to connect NVMe or other PCIe card drives.
I did start to investigate such adapters but given the many different standards of these card drives, plus mSATA etc, it has been safer, simpler, quicker and least expensive to use Backup and Recovery, else I would have a bucket full of USB adapters that sit idle 99% of the time.

Note: I have upgraded my own Samsung 970 EVO Plus NVMe M.2 SSD from a smaller Liteon NVMe SSD using Backup & Recovery where both drives are used in the same laptop with no issues!

All the above suggests to me that some of the users reporting the issues here are using ATI for cloning on a more commercial scale, i.e. cloning drives from multiple different PCs on a bench system that does not / cannot match the hardware of the various source PC's where the drives are intended to be used.  If so, then perhaps Acronis has tried to become too clever when it comes to cloning by trying to match the hardware in the cloning PC by employing some of the Universal Restore tools!

This is a response to the request of the Acronis Forum Team email to John Herian.

True Image 2021 Build No. 35860

True Image 2018 BUILD No. 10640

Source Disk Samsung 970 EVO Plus 500 GB

Destination Disk Samsung 980 Pro 500 GB

John Herian

John,

I'm curious about the message given on the BSOD when you try to boot the cloned 980 Pro.

There are two main reasons why a cloned drive doesn't boot. The first is a driver problem. In that case the BSOD tells you there is an "inaccessible" device. The second is the BCD file is pointing to the wrong location of the Windows partition. In that case the BSOD tells you there is a "missing" device. What does your BSOD say?

Steve Smith: All my clones have been made to replace disks in the same computer. So the source and destination drives have been used in the same computer.

Last attempt, was a week ago on a Dell XPS with a 512GB Samsung PM951 OEM M.2 NVMe drive. I inserted the source drive into an external enclosure (Jmicron controller), and installed the destination drive (Samsung 500GB 970 Evo Plus) into the laptop. Then started cloning from WinPE rescue media, cloned started and jumped to very quickly to 50% and started synchronizing operating system. After 10 minutes it was done (source drive had about 100GB used). Rebooted the laptop, it displayed Windows 10 logo and started the loading animation, and bang, BSOD (unfortunatelly can't recall the BSOD error message). When cloning I selected the option that the destination drive was to replace a drive in the same computer.

Then using same method, I have used EaseUS Todo Backup, and it took way longer than Acronis (because it was really copying all files). After clone conclusion, rebooted laptop and it loaded the operating system correctly.

None of the clones was sector by sector clone.

Joaquim, thank you for sharing that detailed information.  I have no explanation why this didn't work correctly for you and without the log from the clone that later failed to boot / gave the BSOD and details of the latter, then cannot start to guess at what is happening for you and the others reporting these issues!

I cannot offer to try to replicate these issues, as mentioned above in my earlier update, simply because I do not have and don't intend to buy any external NVMe enclosures or adapters etc given that using Backup & Recovery for this type of migration works fine for me!

If EaseUs is capable of making a successful clone with the scenario you used for ATI 2021, then this suggests that there are issues here that Acronis development need to investigate, but for them to do so requires that users submit support cases to complain about this issue (and are prepared to provide diagnostic logs etc)!

Joaquim,

You should check your cloned system to see if Windows Recovery is working. The last time I tested using EaseUs ToDo Backup to clone was with version 12.0, Windows Recovery came up as Disabled in the cloned system.

Open a command prompt as administrator and enter:

reagentc /info

The system will respond with either Enabled or Disabled.

This a response to a request from the Acronis Forum team from John Herian

The BSOD form a non bootable NVMe clone:

1. Reinstall Windows

2. Advanced Options

3.  Turn off your PC (my choice)

John Herian

Wow this is an interesting discussion.

Various post on the forum and my own experience indicates that ATI 2021 Linux recovery media is broken. It does not work with my AMD systems.

I have only replaced the NVMe drive once, and took the same approach as Steve Smith - backup the recovery to the new drive. This was done with ATI 2020, not 2021.

Ian

I have used it on both Intel and AMD systems, so it's not CPU/chipset related. I guess backup and restore works, but that it is not a fix, just a workaround. Doing that way, takes double the time, because you need to backup the whole disk first, and then restore the image to the destination drive. And you need a 3rd drive to store the image. For fast deployment, cloning is the fastest choice. Until Acronis fixes it, I will use a competitor's software for NVMe disks.

John Herian wrote:

This a response to a request from the Acronis Forum team from John Herian

The BSOD form a non bootable NVMe clone:

1. Reinstall Windows

2. Advanced Options

3.  Turn off your PC (my choice)

John Herian

I have no idea what this means. Can you elaborate? Is there more than one John? I have seen a similar reference earlier. Where is this coming from, what does this list of actions suggest? I am confused.

 

I am sorry Joaquim and John that I can't be of any more help. I have compiled and updated a list of parameters that you all reported in, like what version of True Image you were using, what hardware, what works and what doesn't and so on. There is no pattern to it as far as I can tell. We may be missing some vital information here. So it's best if this is dealt with on a case by case basis and investigated by Acronis. For that to happen, you have to go through the support and report these issues, both of you (and anyone else who finds this discussion later on).

Other than that, if a competing product works for you, I suggest you use that instead. That or use the backup and recovery feature to restore rather than clone a disk. I understand the implications, like having to wait longer for the process to finish and the need for additional disks. But it's definitely better than no solution at all.

 

Same issue here - Attempting to clone a Samsung 970 EVO Plus 1TB over to a new Samsung 980 Pro 2TB, OS is Windows 10 with all latest updates installed as of 2/25/21.. I've done similar clones with other M.2/NVME drives dozens of times in the past with True Image without issue.. there's something about these particular drives that True Image doesn't play well with.  Each attempt reports a successful clone, but the destination drive will never boot.  Windows attempts to do an automated repair, but fails.  Here's what I tried (each time, moving the destination drive into the primary M.2 slot and removing the original source drive):

 

970 1TB in M.2 slot, 980 2TB in M.2 to USB adapter - fails to boot after clone

980 2TB in M.2 slot, 970 1TB in M.2 to USB adapter - fails to boot after clone

980 2TB and 970 1TB both in M.2 slots (motherboard has 2x M.2 slots) - fails to boot after clone

In each case, all the data is copied to the 980 2TB drive, it just fails to boot into Windows.  Windows attempts to do an automated repair, but fails.

I ended up just using Samsung's free drive/data migration tool, which worked perfect.

Acronis, please fix this!  I've been a True Image user for years now, will continue to upgrade provided these issues are resolved.  I'm aware the 980 Pro is a brand new drive and it can take some time to work out the issues.

Brett, welcome to these public User Forums.

Acronis will only be able to fix this type of issue if the users who encounter the issue report it directly to them by opening a Support Case - they do not trawl these user forums looking for issues to fix (unfortunately)!

I know it's an old post but will provide my feedback. I have tried 3 clonings in about 3 months, all Samsung Nvme drives, usually from 960 Pro to 970 Evo and first one was from Nvme mobo socket to USB enclosure (failed), another was from a mobo socket to another mobo socket on same motherboard Asus Strix Z690-E (failed) and a third one from a mobo socket to a PCI M2 Nvme adapter (failed).

I have 100% success rate with Samsung Data Migration tool, but 100% failure with Acronis.

The issue with Samsung Data Migration tool is that it's only from OS drive on current machine to another drive and will not work if you want to clone another OS drive from another machine (like a laptop with just one Nvme socket), so this is why a 3rd party solution is needed.

At this point I am not looking for a solution, just to share that for me, Acronis (2021) doesn't work for Nvme and is a write off.

Cloning/restoring to a drive connected by USB will always result in an unbootable drive because restrictions put in place by Microsoft. You can clone to/from M.2 drives attached directly to motherboard (and possibly those in PCIe adapter cards), SATA drives connected a SATA port on the motherboard or a PCIe adapter cards, but not to SATA/M.2 drive attached by USB. You can clone to SATA drive attached to an eSATA port as the OS cannot (apparently) distinguish eSATA from SATA port.

To "clone" an M.2 drive you need to backup the existing M.2 drive, then remove it and install the new drive, then do a restore.

another was from a mobo socket to another mobo socket on same motherboard Asus Strix Z690-E (failed)

Not sure what happened here. You do not say exactly how you are doing the clones; if you are doing a live clone from within Windows of OS drive it reboots into a temporary Linux installation which may not have all the necessary drivers to create a bootable drive. For this reason MVPs recommend using Windows based recovery media; the simple recovery media (uses Windows RE) usually works. Alternatively you can create Windows PE version. If you want maximum control over the recovery media use the MVP Assistant - New 2.0 with Rescue Media Builder (New Version 2.2.1).

Ian