Aller au contenu principal

Volume restoring process fails without any message leaving an allocated space on target disk.

Thread needs solution

When trying to restore a Windows 7 system volume backup consisting of 2 parts (1st full + 2nd incremental) the restoring process reaches "less than 1 minute remain" stage which lasts about 15+ minutes. Afterwards progression bar becomes unfilled again and restoring process stops without any message. As a result either destination volume (or unallocated space) of a target HDD transforms into/(remains as) unallocated space. Both parts of the backup passed program verification before restoring. The backup was always restoring into the volume or unallocated space of a sufficient size. 4 restoring attempts - all failed. Restoring 1st part of the same backup (the full one) reaches success (twice at the 1st try) with no problem at 2 different HDDs so the issue is apparently not in the target HDD. If the issue is in a particular .tib file (incremental part of the backup) why then it is not recognized as corrupted during verification? Or what is the cause of the problem? Any ideas?

0 Users found this helpful

Torsten, welcome to these user forums.

What version / build of ATIH 2017 are you using here? 
Is this build 8029 for the Standard version, or build 6116 for the Premium, New Generation version?

How are you doing the restore of your Windows 7 backup image?  
Is this using the Acronis bootable Rescue Media (recommended) or from within Windows?

What messages are written to the log file(s) for your recovery attempts?
Note: The Logs for recovery need to be viewed or saved before exiting from the True Image GUI or else these are lost on restarting the system back into Windows. Starting recovery from within Windows causes a reboot into a Linux OS environment, the same as the standard Rescue media, but has to modify the Windows boot configuration to do this (hence is not recommended).

Validation is only as good as an indication that the backup file has not been modified, damaged or corrupted.  It does this by recalculating the file checksum and comparing this with the value stored with the file.  This is not a guarantee that the backup contents in the file are good, only that the file has not been changed since it was created.  Mounting the file or exploring it and selecting various files or folders to copy to a temporary location can be a better indication of the file integrity.