Cannot recover data - Error 0x101f6 A format/resize error occurred
I'm trying to move to a new computer, and upgrading the HDD that came with the laptop to an SSD since they're better for performance all around. I have the new drive, which is a 500GB SanDisk SSD, and the backup from my old laptop is from a 512GB disk. I can't take the drive from my old laptop and put it into the new one, as the old drive is an NVMe over SATA drive, and the new one is a regular 2.5" SATA drive.
The data partition on the backup is 463.9GB (208.5GB used) according to Acronis True Image 2019, and the drive size is 465.76GB according to Windows' Disk Manager. As I understand, Acronis should be able to resize the data partition so that it and all the other recovery and whatnot partitions can fit on the new drive, however that didn't work. So I used diskpart to clear the disk out (as initially the other partitions recovered fine, and it was just the data partition that failed). I then tried to recover just the data partition from the backup to the new drive, which is a little bit bigger than the entire partition from the backup. That also failed.
I am getting very agitated by the repeated failures. The log files (attached) seem to say that nothing happened between between starting the recovery and it ending with errors over half an hour later, and the drive remains completely unallocated space, like the recovery didn't even try to write any partition information on the drive. I know that both the disk with the backup and the destination disk were being accessed because they're in an external enclosure and the access/write lights were blinking, and yet the destination seems completely unchanged.
The log file quotes an internal error for number of copied sectors differ from counted, so I'm pretty much assuming there's an error in the partition resizing bit of Acronis, but that also wouldn't explain why it couldn't recover the data partition to the target disk when no resizing of anything was needed in the first place.
My backup is not encrypted, but it is compressed to Max. The backup I'm trying to use is the only backup made for an incremental scheme. I had originally tried doing this with a different backup, but that wasn't working, so this backup I tried to restore fro is a fresh new one made last night, and it still fails. I can't think of much else I can try to get this to work. I've also tried using the Acronis Universal restore boot USB to launch True Image's recovery environment and restore the backup from there, but when that didn't work I tried moving to the external enclosure where I'm at now. It is not a sector-by-sector backup.
Is Acronis broken? Am I doing something wrong? Why can't I restore even just the data partition to a drive that is bigger than the entire partition was allocated for? I originally recovered the data to the bigger HDD that came with the new laptop, and it worked (albeit slowly because of HDD limitations), so I don't think it's my backup settings or anything I'm doing wrong, I firmly believe this is an error on the part of Acronis not liking the smaller drive, even when what it's recovering is smaller than the target drive. I assume it's unhappy because the backup was taken from a drive that was bigger, even if not everything is being restored.
Additionally, when using the Universal Restore boot environment, I could not recover and resize partitions a trying to select the destination for the selected partition(s) did not bring up a new window, but caused any input on the windows already present to make the laptop loudly beep. While this is clearly an issue, this is an issue for another day/topic. But really, I'm annoyed at how broken this seems to be.
I understand your SSD is a new drive however running chkdsk /f to look for filesystem errors on the drive would be something I would do in your situation. True Image will fail if errors are found on either disk in a recover process.
chkdsk /r should not be run on your SSD as NAND cells do not use the same structure that hard drives do in regards to sectors.
Steve Smith wrote:Drew, welcome to these public User Forums.
The log doesn't really add very much to the information that you have already given above, other than confirming that you are seeing a format/resize error where the main factor is the number of copied sectors differs from counted.
I would recommend that you do a CHKDSK /F for your source data partition to check for any file system issues at work here. If you have time to do so, a CHKDSK /R is also recommended to ensure that there are no bad sectors present on that source drive, though this will take some time to run to completion.
Previous format/resize issues that I have seen reported in these forums have had disk or file system issues at the root cause, not problems with ATI itself. This tends to be confirmed by the fact that you were able to recover your data to a larger HDD drive, albeit slowly!
I ran chkdsk on the drive from the old laptop, the drive that the backups are located on, and the new SSD I'm looking to put the backup on, and Windows identified no problems with any of them. I used the /R command on the destination SSD, but it did not find any bad sectors. Running chkdsk /r on the drive with the backup would have taken hours to run, and the fact that the backup was used successfully to clone to a larger drive indicates to me that the drive with the backup is likely not the source of the issue.
I understand that you advised chkdsk /r not be run on the SSD, Enchantech, but as the only risk was increased wear on the SSD, I didn't think it would be much trouble.
I don't see how the issue could be caused by the source drive if creating the backup was successful, as was restoring it to the other, larger drive. Is there anything else that I can do to troubleshoot this myself, or do I need to contact the official support team?
Does the log file stating that there was an internal error about the sector count not mean anything?
I don't see how the issue could be caused by the source drive if creating the backup was successful, as was restoring it to the other, larger drive.
Drew, the recommendation for CHKDSK was for the source drive, not the backup storage drive or your target SSD drive. If ATI encounters any file system or sector issues on the source drive it can switch to using Sector-by-Sector backup method which will create a much larger backup image, and file system errors can cause free space size to be wrongly reported.
Disks can become corrupted at any time so just because a recovery was done previously does not mean that things are ok now.
Tell me, the recovery done before, was it done using the same backup image file?
If it was you might try using that file and see what happens.
chkdsk should be run on all partitions of a hard disk if that source contains an operating system some partitions are not lettered thus preventing chkdsk to run on them. The only way to run chkdsk on non lettered partitions is to assign drive letters to them temporarily so that you can do so. This is the only way to insure that corruption does not exist on the disk.
You can usually assign drive letters to disk partitions using Windows Disk Management. There are some cases where Disk Management will not allow the assignment of driver letters to partitions. In that case the Diskpart utility run from a command line must be used. That process is a bit complicated if you need to go that route.
Steve Smith wrote:I don't see how the issue could be caused by the source drive if creating the backup was successful, as was restoring it to the other, larger drive.
Drew, the recommendation for CHKDSK was for the source drive, not the backup storage drive or your target SSD drive. If ATI encounters any file system or sector issues on the source drive it can switch to using Sector-by-Sector backup method which will create a much larger backup image, and file system errors can cause free space size to be wrongly reported.
Yes, as I said, I ran chkdsk on the old laptop's drive and it reported no errors. I ran chkdsk /r on it and restarted, and it stopped progressing after 15%, so I shut it off, as the boot version of chkdsk gives no information as to what's happening, if it's progressing, or what it's working on. I ran chkdsk /r on all other partitions on the source drive, and they came back with 0 bad sectors.
The backup size is 91GB, which is with max compression. I would expect a full sector-by-sector backup would be significantly larger on a 512GB drive. The knowledgebase even says that sector-by-sector backups won't be compressed, so I don't believe that this is the case.
Additionally, Acronis has verified that the backup is valid before every attempt at recovery, so I would like to imagine it would verify the sectors as part of that validation, but I suppose it could also just be running a checksum on the archive.
Enchantech wrote:
Disks can become corrupted at any time so just because a recovery was done previously does not mean that things are ok now.
Tell me, the recovery done before, was it done using the same backup image file?
If it was you might try using that file and see what happens.
chkdsk should be run on all partitions of a hard disk if that source contains an operating system some partitions are not lettered thus preventing chkdsk to run on them. The only way to run chkdsk on non lettered partitions is to assign drive letters to them temporarily so that you can do so. This is the only way to insure that corruption does not exist on the disk.
You can usually assign drive letters to disk partitions using Windows Disk Management. There are some cases where Disk Management will not allow the assignment of driver letters to partitions. In that case the Diskpart utility run from a command line must be used. That process is a bit complicated if you need to go that route.
The backup I'm working with now is a new one after the initial backup failed to drive. It was created overnight from Saturday into Sunday morning. The new backup did not restore correctly either, and I did not try to restore this backup to the larger drive that worked earlier.
I am able to open the backup and view the files in the backup through Acronis and through windows explorer, it contains all partitions from the old drive, and I can open all of them and open the files from them, including the C drive with my data and programs. Throughout my attempts to restore this backup on the SSD, Acronis has validated that the backup is not damaged.
When I ran chkdsk on the SSD, including chkdsk /r, I created a partition across the entire drive, as it is brand new and had no partitions on it. Chkdsk did not find any errors with the new SSD, /R or no.
If it matters, I have also attempted to restore my backup to the drive with no partitions on it (all unallocated, as it came in the box), and with creating a whole-drive partition through Disk Manager, and neither method worked.
To be painfully sure it isn't bad sectors on the source drive, I'll boot the old laptop using the recovery that worked on the HDD, and run chkdsk on the SSD inside the laptop that the backup was made from. Other than the slim possibility of bad sectors there, is there anything else I can be doing to try to fix this myself?
I ran chkdsk on the old laptop's drive and it reported no errors. I ran chkdsk /r on it and restarted, and it stopped progressing after 15%, so I shut it off, as the boot version of chkdsk gives no information as to what's happening, if it's progressing, or what it's working on.
Normally, when CHKDSK starts going slower that is an indication that something isn't good, so just stopping it after 15% isn't going to tell you what problems may be present on that drive.
The alternative here would be to use the drive makers own disk diagnostic tools to check the whole drive.
I concur with Steve on this.
I had chkdsk run in a recovery environment so I could see the progress (I very much dislike progress bars with little to no indication it's still working, as is the case with the regular run-on-reboot option that was seemingly stuck at 15%), and it fixed a bunch of things. I made a new backup and it recovered onto the SSD fine, so this can be marked as resolved or whatever else might be used here.
However, I'd very much like to recommend/see better error reporting from Acronis so that its easier to diagnose and correct these issues.
Thank you for your help! I have no idea why or how the backup didn't recover on the smaller drive when the same backup file had worked on a larger drive, but now that it's fixed, I suppose I don't really care why.
Drew,
We're glad to see your issue sorted.
I do windows data recovery, so that such issue do not interrupt my interruption.