Instant Recovery timeframe

[Daveyd]

I know there are many factors, but what is the average timeframe that a VM can be up and fully functional (being able to log into the OS) from a Veeam Instant Recovery?

We are running v6 with the latest patch. I tested an Instant recovery from a VM. I chose last nights incremental to restore. My backup repositiory is a CIFS share on an Exagrid appliance connected via 1Gb NIC. The time for Veeam to actually publish the VM to the cluster was a few minutes, however the overall time to publish the VM, power it on and being able to log into the VM took approx 30 minutes. Is that typical?

[Gostev]

About 45 seconds to publish, and 45 seconds to boot Windows Server 2003 to logon screen in my personal lab. Which is my 8 GB RAM desktop with VMware Workstation 8.0 running backup server VM, and ESXi host VM. This virtualized ESXi starts the instantly recovered VM (second level virtualization, hehe). All of that is running on a single spindle of a regular 7200 rpm hard drive. So really, it is hard to imagine a slower environment

[tsightler]

Do you have the Veeam compatible firmware on the Exagrid? If so you should create your CIFS share and choose the "Veeam" from the share type. This will optimize the Exagrid for using the Veeam Instant Restore function as the Exagrid will make full uses of the "landing zone" to keep the most recent backup in cache.

Without this optimization, every block that must be read by PowerNFS causes the block to be rehydrated from the dedupe pool. Dedupe appliance are not optimized for the I/O pattern and can experience very high I/O latency when reading from the dedupe store. I've seen read times from 200-1000ms even on very high end dedupe appliance. At typical laptop hard drive will have PowerNFS latency of around 20-200ms. You can monitor this latency while your Instant Restore VM is booting by looking on the performance tab and selecting the datastore. This will show you the request latency. If this is 100s of milliseconds, you're going to see very slow boot times.

[Daveyd]

Do you have the Veeam compatible firmware on the Exagrid? If so you should create your CIFS share and choose the "Veeam" from the share type. This will optimize the Exagrid for using the Veeam Instant Restore function as the Exagrid will make full uses of the "landing zone" to keep the most recent backup in cache.

Without this optimization, every block that must be read by PowerNFS causes the block to be rehydrated from the dedupe pool. Dedupe appliance are not optimized for the I/O pattern and can experience very high I/O latency when reading from the dedupe store. I've seen read times from 200-1000ms even on very high end dedupe appliance. At typical laptop hard drive will have PowerNFS latency of around 20-200ms. You can monitor this latency while your Instant Restore VM is booting by looking on the performance tab and selecting the datastore. This will show you the request latency. If this is 100s of milliseconds, you're going to see very slow boot times.

We've had Exagrid's Veeam integrated firmware since it came out last year. Actually we are on Exagrids latest and greatest. The CIFs shares on the Exagrdis are setup as "Veeam" types. Not sure why its taking so long.

[tsightler]

Monitor the datastore I/O while the system is booting. If your seeing very high PowerNFS latency, that could be the issue and you'd probably want to hit up Exagrid support and see what's going on.

[Daveyd]

Are you referring to monitoring the NFS datastore on the Veeam backup server? We are not 4.1/5.0 and I am monitoring with Veeam monitor and cannot monitor NFS datastores without being at 4.1 or greater

[tsightler]

Yes, I was suggesting that you monitor the datastore latency metric on the VMs performance tab. Typically it's easy to see instant restore performance issues there. Not sure how to do this with older vCenter as my knowledge of those environments has already faded significantly.