Unable to restore partition from backup. 0x101f6 format/resize problem

Do I understand correctly that you are doing a disk & partitions recovery to an SSD from computer A but doing this on computer B using ATI 2020 running from within Windows on computer B?

If the above is correct, then do both computers (A & B) use the same BIOS boot mode when booting into the Windows OS?  Are both using UEFI or both using Legacy?

The backup image file G:\Eagle Backups\ATI 2020\System\Eagle_system_full_b2_s1_v1.tib is using the format from older versions of ATI (.tib) instead of that which is now created by ATI 2020 for new disk backups which use .tibx files.  Was this backup created by ATI 2020 or by an earlier version?

When doing a disk restore / recovery, it is recommended to leave the target SSD installed in the computer where it will be used, and boot that computer from the Acronis rescue media in the correct BIOS boot mode to perform the recovery, with the backup image held on an external drive connected to that computer.

Please download the MVP Log Viewer tool (link in my signature below) and use this to review the log file for your recovery operation then post a copy of the full log detailed messages from using the Log View: Regular option.  This will give more information on which partition is giving the format / resize error?

Thank you for your help. 

Do I understand correctly that you are doing a disk & partitions recovery to an SSD from computer A but doing this on computer B using ATI 2020 running from within Windows on computer B?

My real goal is/was to restore to SSD on Computer A, but having failed multiple times, I was trying to do as you say, and restore to Computer B.

If the above is correct, then do both computers (A & B) use the same BIOS boot mode when booting into the Windows OS?  Are both using UEFI or both using Legacy?

Both computers are using UEFI to boot.

The backup image file G:\Eagle Backups\ATI 2020\System\Eagle_system_full_b2_s1_v1.tib is using the format from older versions of ATI (.tib) instead of that which is now created by ATI 2020 for new disk backups which use .tibx files.  Was this backup created by ATI 2020 or by an earlier version?

I upgraded to ATI 2020 but didn't change the format type.  So it was created by ATI 2020 but used the old type.

When doing a disk restore / recovery, it is recommended to leave the target SSD installed in the computer where it will be used, and boot that computer from the Acronis rescue media in the correct BIOS boot mode to perform the recovery, with the backup image held on an external drive connected to that computer.

I tried exactly that.  Each time, I was told that the image was corrupt.

Please download the MVP Log Viewer tool (link in my signature below) and use this to review the log file for your recovery operation then post a copy of the full log detailed messages from using the Log View: Regular option.  This will give more information on which partition is giving the format / resize error?

Here is the log file:

17/05/2020 09:59:29: +01:00 44828 I00000000: -----
17/05/2020 09:59:29: +01:00 44828 I00000000: ATI Demon started. Version: 24.6.1.25700.
17/05/2020 09:59:29: +01:00 44828 I00640002: Operation Eagle_system_full_b3_s1_v1 started manually.
17/05/2020 09:59:30: +01:00 44828 I013C0000: Operation: Recovery
17/05/2020 09:59:30: +01:00 44828 I0064000B: Priority changed to Low.
17/05/2020 09:59:30: +01:00 44828 I000B03FC: Recover Backup Archive From file: G:\Eagle Backups\ATI 2020\System\Eagle_system_inc_b3_s6_v1.tib Recovery of: Disks
17/05/2020 09:59:31: +01:00 44828 I000101F8: Pending operation 53 started: 'Clearing disk'.
17/05/2020 09:59:31: +01:00 44828 I000101F8: Pending operation 53 started: 'Clearing disk'.
17/05/2020 09:59:31: +01:00 44828 I000101F8: Pending operation 14 started: 'Copying and merging partitions'.
17/05/2020 09:59:39: +01:00 44828 I000101F8: Pending operation 14 started: 'Copying and merging partitions'.
17/05/2020 09:59:41: +01:00 44828 I000101F8: Pending operation 14 started: 'Copying and merging partitions'.
17/05/2020 10:00:27: +01:00 44828 E000101F6: Error 0x101f6: A format/resize error.
| trace level: error
| line: 0x65b5eb7011094703
| file: c:\bs_hudson\workspace\123\processor\diskadm\da_commit.cpp:348
| function: DaProcessor::CommitImpl::OnDaError
| line: 0x65b5eb7011094703, c:\bs_hudson\workspace\123\processor\diskadm\da_commit.cpp:348, DaProcessor::CommitImpl::OnDaError
| $module: ti_demon_vs_25700
|
| error 0x2160008: A format/resize error.
| line: 0xc75257350ce0fa0f
| file: c:\bs_hudson\workspace\123\core\da_api\context_context.cpp:1231
| function: context::Flush_
| line: 0xc75257350ce0fa0f, c:\bs_hudson\workspace\123\core\da_api\context_context.cpp:1231, context::Flush_
| $module: ti_demon_vs_25700
|
| error 0x70020: The archive is corrupted.
| line: 0xf5f8cbcf76155639
| file: c:\bs_hudson\workspace\123\core\resizer\compress\zlibdf_d.cpp:58
| function: resizer::ZLibDecompressor::Process
| line: 0xf5f8cbcf76155639, c:\bs_hudson\workspace\123\core\resizer\compress\zlibdf_d.cpp:58, resizer::ZLibDecompressor::Process
| $module: ti_demon_vs_25700
17/05/2020 10:00:27: +01:00 44828 I000101F8: Pending operation 14 started: 'Copying and merging partitions'.
17/05/2020 10:00:32: +01:00 44828 I000101F8: Pending operation 62 started: 'Recovering MBR'.
17/05/2020 10:00:36: +01:00 44828 I001D0000: Fixing operating system bootability.
17/05/2020 10:00:36: +01:00 44828 I001D0000: The operating system bootability has been fixed.
17/05/2020 10:01:26: +01:00 44828 I001D0000: Fixing operating system bootability.
17/05/2020 10:01:26: +01:00 44828 I001D0000: Updating boot caches on volume '\local\hd_ev\vol_guid(11B41738420C36228A48CEA38D711E38)'.
17/05/2020 10:01:26: +01:00 44828 I001D0000: Updating boot caches on volume '\local\hd_ev\vol_guid(F43CD02F41A624574546529E1A434B8E)'.
17/05/2020 10:01:26: +01:00 44828 I001D0000: Updating boot caches on volume '\local\hd_ev\vol_guid(905269D6495A82DBF853BEB0EDE29CC2)'.
17/05/2020 10:01:26: +01:00 44828 I001D0000: Updating boot caches on volume '\local\hd_ev\vol_guid(F4DFD3C945FFB46BE5559D8A58A4B5CF)'.
17/05/2020 10:01:26: +01:00 44828 I001D0000: Updating boot caches on volume '\local\hd_ev\vol_guid(F050B503444DE430FA5381875787EB86)'.
17/05/2020 10:01:26: +01:00 44828 I001D0000: Updating boot caches on volume '\local\hd_ev\vol_guid(4F3D49A64F36F2736DD979AF80843063)'.
17/05/2020 10:01:26: +01:00 44828 I001D0000: Updating boot caches on volume '\local\hd_ev\vol_guid(26BD589F4939B3F89ABB9B8696629BD7)'.
17/05/2020 10:01:26: +01:00 44828 I001D0000: Updating boot caches on volume '\local\hd_ev\vol_guid(7C17F7214E198C5AE9E2A9A53DB3BC4A)'.
17/05/2020 10:01:26: +01:00 44828 I001D0000: Updating boot caches on volume '\local\hd_ev\vol_guid(AA363B9001D4F17A551B19C800EA78BD)'.
17/05/2020 10:01:26: +01:00 44828 I001D0000: Updating boot caches on volume '\local\hd_ev\vol_guid(7B6DDCB001D4F1BFBDB6EA5800EA78DF)'.
17/05/2020 10:01:26: +01:00 44828 I001D0000: The operating system bootability has been fixed.
17/05/2020 10:01:26: +01:00 44828 E013C0005: Error 0x13c0005: Operation has completed with errors.
| trace level: error
| line: 0x9f2c53c72e8bced8
| file: c:\bs_hudson\workspace\123\products\imager\demon\main.cpp:738
| function: main
| line: 0x9f2c53c72e8bced8, c:\bs_hudson\workspace\123\products\imager\demon\main.cpp:738, main
| $module: ti_demon_vs_25700

Start: 17/05/2020 09:59:29
Stop: 17/05/2020 10:01:26
Total Time: 00:01:57

Further updates:

I have attempted fresh backups of Computer A, using the tibx format.  This time, I added the Validation step to the backup (this should be mandatory btw).  I successfully created a backup of my main partition, but then failed to create a backup of my data partition.  I tried this on two different drives on Computer B, but was finally successful on a drive on Computer A.

Here is the output from a Verification that failed:

18/05/2020 17:11:32: +01:00 16492 I00000000: -----
18/05/2020 17:11:32: +01:00 16492 I00000000: ATI Demon started. Version: 24.6.1.25700.
18/05/2020 17:11:32: +01:00 16492 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
18/05/2020 17:11:32: +01:00 16492 I00640002: Operation Eagle Data started manually.
18/05/2020 17:11:33: +01:00 16492 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
18/05/2020 17:11:33: +01:00 16492 I013C0000: Operation: Backup
18/05/2020 17:11:33: +01:00 16492 I0064000B: Priority changed to Low.
18/05/2020 17:25:19: +01:00 16492 E00000000: Error 0x4000d: The file is corrupted.
| line: 0xc8d8731ce106f9cf
| file: c:\bs_hudson\workspace\123\archive\ver3\adapter\error.cpp:65
| function: `anonymous-namespace'::ConvertArchive3Error
| line: 0xc8d8731ce106f9cf, c:\bs_hudson\workspace\123\archive\ver3\adapter\error.cpp:65, `anonymous-namespace'::ConvertArchive3Error
| $module: archive3_adapter_vs_25700
18/05/2020 17:25:19: +01:00 16492 E0004000D: Error 0x4000d: The file is corrupted.
| trace level: error
| line: 0xc8d8731ce106f9cf
| file: c:\bs_hudson\workspace\123\archive\ver3\adapter\error.cpp:65
| function: `anonymous-namespace'::ConvertArchive3Error
| line: 0xc8d8731ce106f9cf, c:\bs_hudson\workspace\123\archive\ver3\adapter\error.cpp:65, `anonymous-namespace'::ConvertArchive3Error
| $module: archive3_adapter_vs_25700
18/05/2020 17:25:19: +01:00 16492 E013C0005: Error 0x13c0005: Operation has completed with errors.
| trace level: error
| line: 0x9f2c53c72e8bced8
| file: c:\bs_hudson\workspace\123\products\imager\demon\main.cpp:738
| function: main
| line: 0x9f2c53c72e8bced8, c:\bs_hudson\workspace\123\products\imager\demon\main.cpp:738, main
| $module: ti_demon_vs_25700

Start: 18/05/2020 17:11:32
Stop: 18/05/2020 17:25:19
Total Time: 00:13:47

I am rapidly losing confidence in ATI, so any help you can provide would be very welcome.  Thank you.

Sorry but the new logs do not offer enough further information to suggest why you are seeing an issue.

Focussing on the source computer A only, please can you create an Acronis System Report on that computer and share it via a cloud service such as Google Drive, OneDrive, Dropbox etc.

KB 58820: Acronis True Image: Collecting System Report

Hi - I've got the report, but a bit nervous about the amount of information in it for a public forum.  Are you able to PM me and I will reply with the link?

P.S. I've been validating the backups from Computer B to Computer A and found them to be corrupt as well.

Please send me the link via a PM by using the 'Send message' option under my name shown in the forum.  Although my signature says not to do this, I can still read the link in the notification email that gets sent to advise of a new private message!

I tried that - it say Access Denied - you are not authorized to access this page.

Are you clicking on the Send message link or on my name? 

I was clicking on Send message underneath your photo on the post.  If I click on your name, I then have an opportunity to send a message - which I have done. Thanks.

Thank you for the link to the system report zip file.

The report data only covers Backup & Validation activities from 16:50 yesterday 18th May and not any restore / recovery actions per your original post for this topic.

For the Backup operations, these are being shown as completing successfully but failing when the archive file is validated immediately afterwards.

A further factor shown in the logs is that validation is only failing when the destination for the task is a network location where the logs confirm that errors are occurring / detected when the file data is read back from the network storage location and checksums are recalculated giving rise to CRC errors.  Example from the logs below:

18/05/2020 05:32:53:897 PM type=log; level=err; message=pg #4ab8c000 fix 1->0 bit 6 in byte #e3;
18/05/2020 05:32:54:028 PM type=log; level=err; message=pg #4af8c000 fix 0->1 bit 6 in byte #863;
18/05/2020 05:32:54:314 PM type=log; level=err; message=pg #4bb8c000 fix 1->0 bit 6 in byte #163;
18/05/2020 05:33:35:045 PM type=log; level=err; message={"offset": 3156054016, "type": 255, "type_text": "DATA", "magic": 65, "crc": "6f5444da", "calc_crc": "64e0fbfb", "order": 0, "status": "CRC mismatch"};
18/05/2020 05:33:35:045 PM type=log; level=err; message=io#1: failed to verify page 3156054016: -5003 Data is corrupted: CRC mismatch or internal data structures mismatch;
18/05/2020 05:33:35:045 PM type=log; level=err; message=ar#1: failed to read segment 14112 0xbc1aa:0x81 (err=-5003);

Validation of backups stored on your local I: drive is shown to run successfully with no issues.

I am not seeing any errors shown in the Windows System & Application event logs for the time that the above errors were detected.

This suggests that the errors are being caused by something related to the network such as a cable or dropped packets or an issue on the destination system etc.

Thanks for taking a look.  I agree that the problem seems to be when saving (or validating) a backup over the network.  Windows does not appear to see any fault.  Does ATI use a completely different way of writing files over the network?  At the moment, I am checking all of my backups, and finding most of them to be corrupt (according to ATI).  That's from Computer B to Computer A as well as Computer A to Computer B.

I have no idea where to start looking for a solution to the problem?

P.S. My computers are networked using Ethernet and my router.

ATI should be using SMB 2.0 or higher across your network given that Microsoft have dropped SMB 1.0 for several years now.

It could be worth disconnecting / reconnecting network cables to see if that action would improve things by remaking the connections between the pins & socket connectors.

I would recommend doing any validation for supposedly corrupt files by copying these to a local drive before deciding if they are truly corrupt or not, thus removing the network component out of the validation process.  If the files can then be validated successfully, it would confirm that the errors are coming from the network side, and if they still fail, then corruption is probably happening during the file writes across the network as well as when reading data back again.

I do not do any backups between different computers as you are doing here, so not sure what other factors may come into play in terms of interaction between the files and the remote OS or active applications etc.  If one of the computers is overclocked or has memory issues etc that could contribute to issues.

For my own backups, I make these to local external drives, to a Synology NAS server and to the Acronis Cloud servers, and have never seen this type of issue arising that I have become aware of.

One further thought, if you have ATI on both computers, then does validation work when checking the local files to that computer that originate from the other computer?
Note: validation is not dependent on being done only on the computer that created the backup as it is purely a process of reading in the file data and comparing the stored checksums within the file with the values calculated from the read data blocks.  ATI writes a checksum with every block of data written to backup archive files, so validation confirms that these checksums are still correct and thus that the archive file remains unchanged from when it was written to disk.

I have tried validating the backup on Computer A (taken from Computer B) using Computer A and it failed.  I have also copied the backup on Computer B (taken from Computer A) onto an external USB drive and validated that on Computer A. This also failed.  This to me suggests that the problem is caused when creating the backup, not the validation giving false results.

It would very much appear as though the problem is caused by performing a backup to a network share.  I don't think that disconnecting and reconnecting cables will make any difference.  Ethernet is designed to detect errors and recover from them.  If it really can't recover, then it reports it to the application.  I am able to successfully transfer large files between the two computers with no errors and up with identical file sizes.

Interestingly, I have downloaded Paragon Hard Disk Manager (which includes Backup and Restore).  I had exactly the same problem - creating a backup on a local disk works fine, creating one over the network causes corruption.  I don't know if they both use the same technology, but it would appear that neither program handles errors properly - both report that the backup was OK, but then both fail during a validation.

For now, I have decided to switch to backing up on local disks as I haven't got the time to keep going at this. However, I have learned three lessons:

1. It is essential to set the option to validate a backup after creating it.

2. It is essential to validate a backup before attempting to restore.  When doing a restore, Acronis first deletes the partition, then attempts to do the restore, then stops when it finds that the backup is corrupt.

3. Don't try to do backups to network shares.  I wish I knew why this doesn't work, but it doesn't (most of the time).

Thanks for your help and useful suggestions.

Engeeaitch said in post #2:

I have attempted fresh backups of Computer A, using the tibx format.  This time, I added the Validation step to the backup (this should be mandatory btw).  I successfully created a backup of my main partition, but then failed to create a backup of my data partition.  I tried this on two different drives on Computer B, but was finally successful on a drive on Computer A.

Your comment that in this scenario the backup fail to creation on your data partition on the source disk.  This is quite telling actually suggesting that corruption exists on that partition of the source disk.  You also make mention in this thread that EaseUS behaved in a like manner, also very telling.

Did you try running a disk check on your data partition in an attempt to find any errors?  My guess is that if you had you would have found errors, corrected those errors, and be able to create good backups. 

I have run chkdsk /f /r on the drive and it passed with no errors.  I have successfully created a local backup on the drive. The problem exists when backing up from Computer A to Computer B and from B to A, which is why I think it is something to do with network shares.

Coming late to this topic; however, as multiple backup apps have same/similar problem, it suggest to me that it could be an issue with the router - have you checked the router logs for errors. Have you tried rebooting the router? If there are intermediate switches, you should also reboot them. The procedure I uses is to power down the router, power down the switch(es), power up the router then progressively power up the switches.

Ian

Again, you state that your data partition backup fails.  Now you state that you have run check disk on the drive.  Check disk must be run on all partitions of the drive.  If you have run check disk on the C: partition but the drive also has a D: partition for example, check disk will not check partition D:.

So the question becomes, did you run check disk on the data partition?

Correction - I have run chkdsk on the target partition (i.e. the network share) and it passed with no errors.  The backup fails in both directions - i.e. backing up from A to B and B to A. In both cases, I have been able to do the exact same backup to a local partition (the network share).  

Network traffic via IPv4, UDP TCP and Ethernet all have either CRC value or Checksum to verify data.  If data is corrupt that corruption will result in dropped packets.  Dropped packets will be resent and assembled at the destination in the correct order.   IPv6 does not use checksum and UDP checksum is a run and forget so verification is left to the application layer involved in the transmission.

Are you using IPv6 or UDP as your protocol?  If so then corruption may be introduced during transmission.  This is a catch 22 for you however because the application layer is responsible for detecting corruption which in this case if this is happening True Image is.  That does not fix your issue however.  This is probably a moot point as I doubt you use IPv6 or UDP in this scenario.

Does your Ethernet cabling pass under or around anything that may introduce electromagnetic interference?

In case anyone is having similar problems, I have finally got to the bottom of this.  I noticed that writing backups to a local disk on one of the machines gave the occasional error.  I ran memtest86 and it gave a few random errors.  Replacing the stick has fixed the errors, and I have not had any problems with writing and validating the backups since.  It appeared as if the ethernet was the problem, but in fact the data was being sent to large amounts of memory before being written to disk and that is where the the problem lay.

Nevertheless, I would strongly recommend that backups are validated - ATI will happily write a corrupt backup only to completely reject it when it comes to restoring it.