I had to put in an emergency triage case with Veeam for Veeam 9.5 update 1. Over the weekend I had some DFSR stuff go wonky and overwrite all of my primary user storage folders. The quickest way for me to do a restore would be to restore the entire VMDK where the user folders were stored and then add that disk to the existing file server and update the DFS file share for the users. The VMDK itself is 1.5 terabytes. Our Veeam server resides across a WAN. There is a local proxy to the file store and a local data domain. So the current backup process is:
Veeam backup job starts in the data center and talks to the proxy at the remote site
The remote proxy talks to the vCenter at the remote site and backs up to the data domain at the remote site
Data doesn't traverse the WAN. Backup is local
So the problem is that if I want to JUST restore the 1.5 terabyte VMDK, there is no way to instruct the restore process to simply use the proxy at the remote site to communicate with the Data Domain at the remote site to restore the VMDK file back to the remote site's vCenter instance. Currently when I attempt to restore, the Veeam Server in the data center attempts to initiate the restore process and hairpin from the data domain at the remote site, to the veeam server in the data center, back to the ESXi host you choose to restore to through the UI. This is terribly inefficient and according to the technician I am working with, this is hardcoded to work like this. So basically if I only want to restore my VMDK file, I have to saturate a WAN pipe that I absolutely cannot saturate as I have priority services that are sensitive traversing that same path. Meanwhile, all of my local links between the proxy, the vCenter/ESXi hosts, and the data domain are 10Gb links.
Any reason that you cannot use the "Restore virtual disk" option instead of "Resfore VM Files"? The former can use a proxy and restores just a disk to a VM vs restoring the entire VM, while the latter is more like copying the VMDK from the backup to the ESXi host. Restoring the virtual disk is typically much faster than copying the VMDK to a datastore.
If the reason you don't want to use "Restore virtual disk" is because it powers off the VM during the restore, you can always just create a small shell VM and then restore the virtual disk to that VM, then attached the restored disk to the original VM.
Or, if you really just want to copy out the VMDK to the datastore, then you can install the Veeam remote console on a server at the remote site and I believe that should keep the copy operation local.
tsightler wrote:If the reason you don't want to use "Restore virtual disk" is because it powers off the VM during the restore, you can always just create a small shell VM and then restore the virtual disk to that VM, then attached the restored disk to the original VM.
The file server in question has multiple drives that host multiple shared volumes. Having the file server offline is not a possibility.
The volume in question has multiple shares on it outside of the "users" directory that are perfectly fine and I do not wish to overwrite whatever business has happened in the last 48 hours.
Creating the shell VM, while plausible was not an option that was given to me by the technician at the time but there might be a reason he did not suggest this step due to something I am leaving out.
tsightler wrote:
Or, if you really just want to copy out the VMDK to the datastore, then you can install the Veeam remote console on a server at the remote site and I believe that should keep the copy operation local.
The Veeam console will not let you connect to "nothing." You also cannot connect to "localhost" unless Veeam server is actually installed. Running the Veeam console from the proxy server will prompt you to connect to an actual Veeam server and will not allow you to just connect to a proxy. The ultimate solution that I am currently using, is that I had to uninstall all software from the proxy and then install a standalone instance of Veeam on the proxy. Once the SQL Express instance was installed and the service was installed, I then had to add the local vCenter server and then import the site local backup on the data domain. Once I did that, it removed the primary Veeam backup server from the mix and allowed the restore to proceed only over local links.
While I appreciate the options that were given, in Veeam 9.0 I recall you used to be able to simply "import" the backup from the Console as you suggested from an SMB share and initiate the restore that way. My first instinct was to do this however, the console absolutely would not open up unless I connected to the data center Veeam server for 9.5. Once you connected to the Veeam server the Veeam Agent on the data center based Veeam server, seemed to want to do the heavy lifting with communication between the data domain and the remote site vCenter Server hence saturating our WAN.