Task Problem with ABU after volume restore

Thread needs solution
truwrikodrorowrelupicugojestutroclulachosaswunuhospikigawakijosaswenomaruclojeueclikaspedrubewidebrisubrohutrurifruuagothunugekedrumucisiuobrobrecrupeslapuswosluprothethibakaslechurathikucli
Beginner
Posts: 2
Comments: 3

I have observed this behavior in Win 7 Pro x64, but by its nature I suspect it occurs with any OS. This is a universal problem with ATIH and ABU, so I wonder why I have not see it mentioned on a forum. Maybe I'm missing something here.

When I do an image backup of my system volume (which contains the ABU11.5 product) and then restore it using the bootable medium, everything works correctly, except that the backup task information is corrupted and is subsequently shown by ABU 11.5 as "failed." I can work around this by cloning the backup plan and deleting the original one. I think I know why this happens, but I don't have a way to fix it except for the cloning work-around.

Here's why this happens:

When the volume backup is made, a snapshot is taken of the ABU state contained in its databases early in the process--long before the backup process has finished. ABU places this state information in folders contained in %ProgramData%\Acronis, which is backed up as part of the system volume. Therefore, the backed-up databases do not contain the state of ABU AFTER the backup finishes; they contain the state when the backup is in progress.

When the volume has been restored and I run ABU, the ABU databases are in the state they had when the backup was still in progress, not the state after it finished. ABU expects them to contain the state when the restored backup finished, and this causes the problems with the displayed task and the corresponding backup plan. Even restoring the ABU databases from a later backup does not solve the problem; they all contain an incomplete state for the same reason.

I could change the environment variable ProgramData to point to a non-backed-up volume, and I think this would resolve the Acronis problem. But, that would prevent backing up some non-Acronis folders as well--definitely not an acceptable thing if I were to lose my system volume and had to restore it.

If Acronis placed the state information in a location determined by a separate environment variable, I could set that to a non-backed up location. I have tried relocating the Acronis state information using a soft link after installation, but the Acronis folders are protected, and moving them is highly problematic. I have not tried creating the soft link before installing ABU, although that might work.

Does anyone else see this problem?

Sun, 04/06/2014 - 20:01
0 Users found this helpful
truwrikodrorowrelupicugojestutroclulachosaswunuhospikigawakijosaswenomaruclojeueclikaspedrubewidebrisubrohutrurifruuagothunugekedrumucisiuobrobrecrupeslapuswosluprothethibakaslechurathikucli
Forum Star
Posts: 0
Comments: 1379

Hello.
This problem is known. You're right about the root cause. There were attempt to fix it and 'make up' plan status in such conditions to report success, but it caused undesired side effects. Is it really a significant problem? If you can clone this plan, it's not a centralized one, it won't report failure to Management Server, so you can just ignore it. Or not? I think it's possible to alter plan success status using a script for a command-line utility (dml_dump) after restore. The plan ID is the same and you need to create this script just once.

for reference - issue number is ABR-11998

Sun, 04/06/2014 - 20:48