@Mildur would you know that ?
Did you check if are not other backups jobs running during the migration?
Hello @bharathn, I think the steps below should help you.
-
Open the Veeam Backup & Replication console and navigate to the Backup & Replication section.
-
Locate the desired backup job that contains the virtual machine you want to restore and right-click on it to select Restore.
-
In the Restore wizard, select the virtual machine you want to restore and click Next.
-
In the Restore options section, select the Restore Virtual Disk option and click Next.
-
In the Restore options section, select the Restore separate disks option and click Next.
-
Select the individual VMDK files that you want to restore and configure the restore options for each one, such as the destination datastore, the disk format, and the restore point.
-
Click Next to proceed to the final step of the wizard, where you can review the restore settings and start the restore process.
With this, you should be able to restore your VMs with separate tasks for each VMDK file as this allows for greater control and visibility in the restore process.
Hi All,
Currently we do an Instant recovery from the ‘Entire Computer’ backup taken by Veeam agent, it goes for P2V conversion. Once the instant recovery completes, when we initiate ‘Migrate it to Production’ (may be to VMware Hypervisor using dedicated proxy which can handle 4 concurrent tasks. But it seems Veeam is treating the restore as single task and the number of VMDK files/Disk associated with the restored VM is migrated one by one which prolongs the RTO. Is there a way to consider each VMDK file as separate task (which will allow for parallelism) during the entire VM restore (using instant recovery method and ‘Migrate it to Production’)?
Hi @bharathn
Can you share throughput speed?
@Iams3le - The problem with individual VMDK file restore was we have to spend more time for post restore activity considering the business applications installation and configuration are done on C drive partition. For Data disk, this applies well where I can mount the VMDK and validate/use the data required. But it becomes time consuming process when customer expects to bring it as actual VM with original configurations.
@Andanet We get around 25 MB/s to 30 MB/s for each VMDK file restore/copy to the production datastore.
@wolff.mateus - Yes, we made sure that the dedicated proxy is not used for any other task during the restore session.
Hello @bharathn, I think the steps below should help you.
-
Open the Veeam Backup & Replication console and navigate to the Backup & Replication section.
-
Locate the desired backup job that contains the virtual machine you want to restore and right-click on it to select Restore.
-
In the Restore wizard, select the virtual machine you want to restore and click Next.
-
In the Restore options section, select the Restore Virtual Disk option and click Next.
-
In the Restore options section, select the Restore separate disks option and click Next.
-
Select the individual VMDK files that you want to restore and configure the restore options for each one, such as the destination datastore, the disk format, and the restore point.
-
Click Next to proceed to the final step of the wizard, where you can review the restore settings and start the restore process.
With this, you should be able to restore your VMs with separate tasks for each VMDK file as this allows for greater control and visibility in the restore process.
But does this work for an agent backup for a physical server as they are doing P2V to VMware. Hopefully this is the answer but as noted check other jobs running as well.
@Chris.Childerhose - Yes, we have an option to export it as individual VMDK file to the Production datastore. But the problem as I mentioned in my previous reply it becomes time consuming process again to get the VM to its original state as it was before with the restored VMDK files.
@Chris.Childerhose - Yes, we have an option to export it as individual VMDK file to the Production datastore. But the problem as I mentioned in my previous reply it becomes time consuming process again to get the VM to its original state as it was before with the restored VMDK files.
Ok. I will try to look in my environment to see if I can help find something to help. Going to also check Dr. Google