Hi ibarizz,
Thank you for the detailed explanation; a few comments and then some advice.
> Given that we’re performing an Entire VM Restore, we’re not restoring individual files but rather the entire structure of the VM with its VMDKs. Therefore, it’s unclear why the large number of files on the file server would impact the restore speed.
Can you elaborate on this statement a bit more? Are you suspecting that the contents of the virtual machine affect restore beyond just the total size of the VMDKs to be restored? The reason I ask is that your first statement is correct, the actual contents of the OS volumes doesn't matter during entire VM restore as there is no activity in the GuestOS on restore; all that happens is Veeam writes to the datastore via the VDDK library, and the datablocks for the VMDK are written.
I would suggest opening a Support case for this one; I do suspect there is some truth to what you're saying with regards to the proxies and disks, the workload likely is being spread out across multiple proxies, but I think there must be a bottleneck beyond just the proxies if it sits quite evenly at 60 MB/s per disk for your larger disks. Veeam Support can identify the true bottleneck from the logs and if necessary provide a test for the write speed during restore based on the transport mode. That is to say, for your VM with the larger disks, more proxies likely won't help as it's likely as you tell, fewer disks, fewer proxies/connections for writing disks in parallel, so you're likely bumping up against a bottleneck elsewhere, but it's best to let Support check the situation.
Please open a Support case and collect logs from the Veeam Backup and Replication server itself (use the 3rd radio option and select the Veeam server from the list); please mention the VMs you were testing with specifically as well as the approximate date/time of the test so the Support Engineer can jump right in with the research.
Thank you for the detailed explanation; a few comments and then some advice.
> Given that we’re performing an Entire VM Restore, we’re not restoring individual files but rather the entire structure of the VM with its VMDKs. Therefore, it’s unclear why the large number of files on the file server would impact the restore speed.
Can you elaborate on this statement a bit more? Are you suspecting that the contents of the virtual machine affect restore beyond just the total size of the VMDKs to be restored? The reason I ask is that your first statement is correct, the actual contents of the OS volumes doesn't matter during entire VM restore as there is no activity in the GuestOS on restore; all that happens is Veeam writes to the datastore via the VDDK library, and the datablocks for the VMDK are written.
I would suggest opening a Support case for this one; I do suspect there is some truth to what you're saying with regards to the proxies and disks, the workload likely is being spread out across multiple proxies, but I think there must be a bottleneck beyond just the proxies if it sits quite evenly at 60 MB/s per disk for your larger disks. Veeam Support can identify the true bottleneck from the logs and if necessary provide a test for the write speed during restore based on the transport mode. That is to say, for your VM with the larger disks, more proxies likely won't help as it's likely as you tell, fewer disks, fewer proxies/connections for writing disks in parallel, so you're likely bumping up against a bottleneck elsewhere, but it's best to let Support check the situation.
Please open a Support case and collect logs from the Veeam Backup and Replication server itself (use the 3rd radio option and select the Veeam server from the list); please mention the VMs you were testing with specifically as well as the approximate date/time of the test so the Support Engineer can jump right in with the research.
Statistics: Posted by david.domask — May 31, 2024 11:06 am