Internal error: number of copied sectors differs from counted

Jorge, welcome to these User Forums.

Sorry to hear of the problems you are finding in trying to recover your system.

One of the issues from your description of your system is that you are running a RAID system but if you are using the standard Acronis Rescue Media which is Linux based, this does not have any support for RAID.

I suspect that if you recovered your backup image to a non-RAID single drive (HDD or SSD) that you would be able to restore without seeing this error.

The normal advice for this situation would be to create the alternative WinPE version of the Rescue media and to inject the Intel RST drivers needed for RAID support, which can be done automatically by using the MVP Tool Custom ATI WinPE Builder tool, but requires that you have another computer with ATI installed (2016 or later) and with the Windows 10 ADK also installed. See the link for MVP User Tools and Tutorials in the Useful Link section of the forum page.

Steve, thanks a lot for replying.

I'm not sure if I got your point, but my RAID 0 array is hardware based, not software. And before deciding the purchase of ATI 2016, I looked up Acronis site searching for info on the RAID issue, and found that if ATI could see the drive as one single unit, it would work fine. They also claimed to support any RAID array, as they do today. I could find no info whatsoever about problems in recovering a system to its original disk, RAID or not, bootable media or not. I strictly followed all Acronis directions to recover the system, and have never seen anything about limitations with RAID arrays, bootable media or not.

Also disappointing was the impossibility to contact their technical support in such an emergency.

Maybe I failed to read the fine print...

Thanks again and regards.

Jorge, if your RAID is pure hardware and the drives present as a single drive, then there should be no issue.

Thinking further about the core issue of number of sectors copied...  I remembered another topic I dealt with a few months back where this type of problem was caused by the user partitioning the drive before doing the restore.

See topic: Boot error before AND after restore, Stop 0x0000007B then scroll down to the post on Wed, 04/12/2017 - 07:36 where the OP wrote:

- tried another disk.  Same behavior as with the original disk.  ATI 2014 was a nuisance when restoring the OS partition to the new disk.  It cost me about a day of dedicated trying and retrying.  This was due to a bug in Acronis True Image that many people have asked about in these forums over many years: "Number of copied sectors differs from counted" (0x70001).  Eventually I found a workaround, so I will describe this as a side note, in case it might save people a few hundred-thousand person-hours.

Side note about the ATI error.  You try to recover a partition to a destination partition, everything seems to run to completion, but at the end you get a failure message.  The log shows "Number of copied sectors differs from counted" (0x70001).  I concluded that this is not a user error (as in stupid, like trying to restore 80 GB of actual data to a destination 40 GB partition), but rather a bug in ATI.  To restore my 3 partition images and MBR to a new hard drive, my initial approach was to create the partition table on the destination drive using GParted.  I set up 3 partitions with plenty of capacity for the data that I was restoring, in the same order as on the original drive: 1) Dell Utility; 2) Recovery; 3) OS; and some more partitions for data, not covered by my ATI backups.  The ATI 2014 boot disk restored the first two small partitions (Dell Utility and Recovery) with no problems.  But when restoring to the OS partition, I kept getting the error; and the outcome was unallocated space where the OS partition should have been.  I tried setting a ridiculously large partition size for the OS destination partition (500 GB for a partition that was originally 90 GB and had 60 GB of data).  Same error.  I tried setting up the target disk within ATI itself instead of using GParted, using the "Add a New Disk" tool.  This also did not work. 

Eventually I found the workaround for the bug.  The trick was to recover partitions only to unallocated space on the destination hard drive, and to use the default size for the OS partition.  In other words, I could not partition the drive first, then restore data to it.  The third partition (OS) had to be restored using the default partition size to unallocated space -- that is, not recovering to a partition that was already set up, and also not recovering to unallocated space >with a change of size<.  The destination partition had to be exactly 90.02 GB to restore without error because the original partition that was imaged was 90.02 GB.  This also means that if the original partition had been very large -- say, 1.7 TB on a 2 TB disk -- and there were not that much unallocated space available on the destination, there would be no way to recover the image without error.

Steve, thanks again for your efforts.

I was recovering the system to the same disk, and I did not partition it before recovery. Acronis did.

In all attempts, the recovery software in  the USB bootable media recognized the destination drive as RAID, confirmed its size, warned that it would have to clear the disk to complete the operation and asked for my OK, which I did.

Jorge, one further question / suggestion? Given the spec of your system (Asrock Z97 Extreme4 with Intel i7 processor and 16Gb of RAM) - I would expect this to be booting using UEFI rather than using Legacy, are you booting the USB Rescue Media also using the UEFI option?  This should match the mode that Windows uses.  See webpage Check if your PC uses UEFI or BIOS for more information.

Steve. 

My PC is UEFI.

Anyway, I've already reinstalled Windows 10 from scratch, and Acronis as well to recover my data files and folders, which it did flawlessly. The problem was only that strange system recovery failure.

From now on, I'll rely on microsoft recovery tools for that purpose.

Regards and thanks for your help.

Jorge Martins.

Jorge, thanks for the feedback, glad that you have resolved the major problem here and have recovered your computer and data etc.  Sorry that we couldn't get to the root of the strange recovery failure for you!