Skip to main content

Internal error: number of copied sectors differs from counted

Thread needs solution

I am trying to restore an ATI 2017 disk & partition backup to a new drive. The source computer is Windows 7. The source drive is a 1TB Hitachi HDT721010SLA360. The target drive is a 1TN Seagate, though I don't have the model number handy. I've booted from the Recovery disk to restore. Initially, I used the 'Tools' selection to remove the existing partition from the target drive and reallocate it as MBR. The restore runs for about 20 minutes and I then get a message, "Recover Operation Failed". The logfile has several messages as shown in my attachment, and ends with several messages, "Internal error: number of copied sectors differs from counted". I've tried the restore 4 different times with 2 different .tib files stored on two different backup devices, one of the .tib's was a full backup.

I've reviewed several other posts in this forum having this message, but none really seemed to apply to my circumstances. Any insight here would be greatly appreciated as the original main drive is having intermittent failures and really needs to be replaced.

 

Attachment Size
AcronisRecoveryLog.jpg 98.04 KB
0 Users found this helpful

Given your final statement about the source drive, that it is having intermittent failures and really needs to be replaced, there has to be a question mark here over the integrity of the backup images that you are attempting to restore?

If you have the MVP Log Viewer tool, I would recommend checking the logs for when the backup images were created, if you still have these present, and ensure that there were no significant errors reported for when the backup was created?

Validating the backup .TIB image files can only verify the checksum for the data written to the file against the value stored within the file, so this cannot confirm that the data captured was good, especially if any bad sectors were ignored (via the Advanced > Error handling settings).

If your backup image contains several individual partitions, then I would suggest attempting to restore these one by one, rather than as a whole disk, to see which partition is giving the error?

Another approach here would be to obtain a dual-drive dock with hardware cloning capabilities which could perform a whole disk to disk copy (warts and all!).  I have one I bought from Amazon a while ago that does this.  https://www.amazon.co.uk/gp/product/B01E6I7TOQ

Thanks for the reply. Actually, I was working on a couple of systems at once and I misspoke about the intermittent failures. That was on the other system. The system I'm actually trying to restore is supposedly fine. Since posting, I've run chkdsk on the 2 visible partitions and no errors were found. I ran the restore from two different incremental backups (thinking maybe the most recent was corrupt) and from the full backup. I tried this using both an external USB drive where one set of backups is kept and also from a backup done to a network device where a 2nd set of backups are stored. The network backup is a separate backup job, not a copy of the USB. I tried recovering to a 1TB drive that I allocated as MBR using the Recovery Tools, and also to a 500GB drive. All attempts failed with the "number of copied sectors differs from counted".

I could try your disk cloning idea, but if it copies "warts and all", would that not simply replicate the problem on the copy?

One of the partitions is an "HP Factory Image". I'll try omitting that from the restore as it won't really be needed. Otherwise, are there any other suggestions you might have? As it stands it does not appear that I have any backups for this computer that can be restored making my backups kind of useless at this point.

See forum topic: Internal error: number of copied sectors differs from counted and the post I wrote in that post on 09/20/2017 which I had found from another topic in the forums.

Found another hit via Google that may be relevant:

See webpage: https://www.experts-exchange.com/questions/22947018/acronis-server-restore-how-to-restore-to-different-size-disks.html where it suggests:

the answer is to check the box that restores the master boot record and track 0.  this will, apparently set the correct number of sectors.  anyway this is the fix, i found just by trying different things.  

I'm going to give this another try right now. The target drive may not be the exact same geometry as the source, so perhaps excluding the "HP Factory Image" partition will leave enough space (with a bit extra) for the OS partition. I believe I do check the "MBR and Track 0", but I'll double check that. Stay tooned ...

I gave this another try last evening. I omitted installing the original partition D: and the target drive supposedly then had 10G unallocated. I definitely checked recover MBR and Track 0". Unfortunately, same result (see image).

So, am I just out of luck being able to create a restorable backup from this computer? I've never run into this on Acronis before. I've always been able to restore to a new drive successfully (I might have had other problems booting it ...).

Ideas?

Attachment Size
445248-145261.jpg 119.96 KB

Do you still have the source 1TB Hitachi HDT721010SLA360 drive to allow for trying a different version of ATI or else using an alternative product such as Macrium Reflect Free to create a backup image and attempt to restore this to the new Seagate drive?

If you have used ATI over different versions, then you would have these shown in your Acronis account and be able to download the default, Linux based Rescue Media as a .ISO file.

Yes, the drive is still running in the original computer. This backup was done with ATI 2017. I may have a 2018 .iso around somewhere. I could give that a try. I suppose it couldn't hurt.

I tried doing the restore with ATI 2016, ATI 2017 and ATI 2018. I made fresh total image backups using ATI 2017 and ATI 2018. At some point, I was able to start the Windows boot, but it continuously rebooted. I tried Universal Restore, but it failed looking for the driver PCI\VEN_8086&dev_2829&SUBSYS_00000000&REV_02. I've run into that problem before when restoring to a Virtual Machine and the solution was to set the registry values for HKLM\System\CurrentControlSet\Services\Msahci, and HKLM\System\CurrentControlSet\Services\IastorV to zero. Then doing a full backup. That didn't work so I tried setting the additional keys pciide and iastor to zero. Again, no go.

In the end I gave up and re-installed Windows from scratch. I've only failed to restore using Acronis twice before that I can recall. One was to a HP laptop with Windows 7 Home Professional, I don't recall the make of the 2nd one, and this one which is an HP tower with PEGATRON  TRUCKEE 1.04E01 motherboard and i7 920 processor. Perhaps some of these proprietary "name brand" system have things built in to defeat restoring to non-name-brand hardware.

I continue to suffer with the scratch-installation. Apparently Microsoft provides no mechanism to permit Outlook to use a profile .pst file when Outlook is reinstalled, so my user has currently lost all of his hundreds of color category settings. But, that's another story ...

Done with this issue. Failure. Moving on ...