Can't start backup recovery to external HDD
Hello,
maybe someone will have some tips for this issue:
We are trying to recover Full backup of one of our Windows 10 PCs which has 3 partitions, containing 36GB of data on 500GB HDD.
As a target for recovery we are trying to select empy, unformatted 500GB HDD connected via USB, but it won't let us.
If we have disk mapping selected, then 500GB HDD can't be selected - error: Failed to copy disks
We can only select 1TB HDD for some reason. That could be a hint for not enough free space in target HDD, but thing is, both source and destination HDD are 500GB, so I don't see why that would be the case here.
If I switch to Volume mapping, then I'm able to select this HDD, but as a default it's trying to recover EFI system on partition to Disk 1 on the client when we are doing recovery, instead of the USB HDD.
When I clear the mapping and set target for EFI system to USB HDD, then it looks fine at first, but once I start to map other partitions to USB HDD, it will always delete the previous mapping.
By that I mean - I map EFI system to Disk 4, then map C:\ partition to Disk 4, this clears EFI system mapping and won't let me change it, then if I map D:\ partition to Disk 4, it will clear the C:\ partition and if I map E:\ partition also, it will clear D:\ and I'm left with what you see in attached image "mapping.png".
If I let only E:\ partition selected (just to see what will happen) and start the recovery, I get "The object was not found in the session." error message.
TOL: Failed to execute the command. Recovery::Assistant::Commands::SetOptions
Additional info:------------------------
Error code: 22
Module: 309
LineInfo: 0x8D165E86FB819597
Fields: {"$module":"management_server_vsa64_13400","CommandID":"77A74DBD-4C42-4DFD-98AD-BF5CBD1C196C"}
Message: TOL: Failed to execute the command. Recovery::Assistant::Commands::SetOptions
------------------------
Error code: 22
Module: 309
LineInfo: 0x8D165E86FB819597
Fields: {"$module":"ams_recovery_assistant_addon_vsa64_13400","CommandID":"77A74DBD-4C42-4DFD-98AD-BF5CBD1C196C"}
Message: TOL: Failed to execute the command. Recovery::Assistant::Commands::SetOptions
------------------------
Error code: 1
Module: 563
LineInfo: 0xA816CBC5A4EF1324
Fields: {"$module":"ams_recovery_assistant_addon_vsa64_13400"}
Message: The object was not found in the session.
And ideas what might be wrong here?
Thank you
Lukas
Hello Maria
I can't provide the video now (I was doing this remotely in different country and HDD connected there is not empty anymore), but I think I can give you more information as I was eventually able to recover backup to this HDD yesterday.
But the procedure I used, was far from perfect and I'm not 100% sure the recovered backup is OK (not tested yet).
I will try to describe what I did and maybe you can tell me if it's supposed to behave like this.
1. As a first step I swithed to volume mapping (as Disk mapping wouldn't let me select Disk 4 as target)
2. After I switched to volume mapping I noticed, that it has automatically selected the empty 500GB (Disk 4) as target for all partitions except for EFI system partition.
I didn't want to write on Disk 1 (I will mention again, that this case was using Agent A to recover backup of Agent B to an empty HDD connected via USB docking station), so I cleared the mapping and started from scratch.
3. I assigned FAT32 boot partition to Disk 4 -> OK
4. Then I assigned C:\ partition to Disk 4 (in the selection I could still see the EFI partition assigned to Disk 4), but once I approved it, the EFI system partition was gone from the mapping.
5. But then I noticed, then when I was adding D:\ partition, both EFI and C:\ partitions were shown in Disk selection as reserved space.
Every time I added other partition, all the previous ones were gone from the mapping and eventually it looked like this:
6. I thought that it still might be OK, because when I was in allocation selection, I still saw all the previously selected partitions:
7. So I started the recovery process and when it reached 77% I got this warning about Access being denied:
I selected Ignore all and task eventually finished with warnings.
When I checked the log, it looked like Acronis was trying to write to boot sector of Disk 1 (again: Why??) and Windows understandably wouldn't let it. I don't understand why it's trying to write to (not selected) Disk of Agent used for the recovery task, even when I specified Disk 4 as a target.
Recovery of Win7 backups is no problem. It's just recovery tasks of Windows 10 backups that are creating this warning and are stuck there unless I chose to Ignore the errors (I had this Access is denied error before and chose to ignore it every time, recovered backups were usually OK).
What happened in steps 4-6 I saw for the first time, so maybe it was just some isolated incident, but step 7 is happening for all Windows 10 recovery tasks (unless I use Acronis USB stick).
Is this normal? Doesn't feel like working as intended to me :)
Thank you
Lukas
Helo Brose.
I would advise deleting all partition/volumes on the target USB drive and convert to the same system (MBR or GPT) as the source system.
Since it looks quite weird, I recommend that you open a case with Acronis Support Team for deeper investigation. Please share a link to this forum thread. You will also be required to collect Acronis System Report from the original system and from the Agent which performed the recovery just after reproducing this situation