Instant recovery is very slow

[rimvydukas]

Hi,

I have a problem, that instant recovery is very slow:( VM is published in 1 minute interval, but it starts very long, and when I log on - everything is very very slow. Is it expected thing or is it possible to improve something? ESXi and proxy server is on 1Gbit network, proxy server storage is on SAN disk. When I started to use veeam it seemed that everything was a lot of faster, but when I configured all archive jobs or when I upgraded to v7 - everything seems so slow:(

[veremin]

Where is the repository with corresponding vPower NFS server located? Thanks.

[rimvydukas]

Repository, nfs and backup proxy are on the same physical server. There are no backup jobs runing at this time.

[veremin]

So, the repository server is also located on the same machine, right? What type of repository is being used? Ordinary Windows or CIFS share? What about usage of special Windows features on repository, like Data Deduplication?

Thanks.

[Vitaliy S.]

In addition to what Vladimir says, can you please tell us what is the vPower NFS datastore performance if you check it with vSphere Client? What is the latency to this datastore?

[rimvydukas]

Repository is on Windows 2008 R2 server, so no Windows native deduplication. Repository type is Windows. And it seems that VM acts very slow when I use instant recovery on machine which has lets say 30 restore points (I use newest restore point). VM with lets say 5 restore points starts more quickly. I checked NFS datastore performance and when VM starts I have 1000 miliseconds read and write latency:( When I start VM with 5 restore points - latency was 200 miliseconds. When VM is started - latency drops to 60 miliseconds but everything is slow event if I try to press right mouse button or open task manager:( And vmware complains about high latency of VM disks.

[veremin]

Does the corresponding chain have only 1 full backup (oldest file) and 29 following increments? Thanks.

[rimvydukas]

Yes, full is done one time during a month.

[Stephan23]

I hope it is OK to dig out this old thread, but I have exactly the same problem.

The machine that was deployed by Instant VM recovery was very slow until it was migrated to its original vSphere datastore. Disk latency at this point was around 30-40 ms.

- The Veeam Proxy is a dedicated hardware with 8 CPU cores and 32 GB memory
- The Disk Repository is an old SAN that is not used for anything else and is connected with fiber channel with the proxy, no compression or dedup on the storage side
- No backup job was running
- The restore point was from a full backup
- In the backup job inline data reduplication was active and the compression level was "Optimal"

edit: the vPower NFS Service is running on the same proxy

[foggy]

- The Disk Repository is an old SAN

I believe this is the reason. Instant VM Recovery runs a VM from a deduplicated and compressed backup file and is a complete random access to disk, which that device could probably lack. Btw, what kind of VM it is? The amount of I/O it can generate also directly affects IR performance.

[Stephan23]

ok, bad phrasing. with old i don't mean "slow", i mean "the san we used before the current one". it's a vnx 5300 with a lot of drives.

the vm was a windows server 2003 r2 enterprise x64, is running a sql server 2008 with very little going on and hosts mostly self developed software via network share. but i deactivated network before booting the vm and there were no i/o going.

[foggy]

To completely rule the storage out, you can test IR from some other storage - backup server's local disk, for example.

[Stephan23]

i did some testing, but wasn't able to reproduce the issue. even the same vm with the same restore point was running ok, relatively high latency peaks but not the constant 30-40 ms i had before.
i'll keep an eye on the behavior and report back if i get relevant information.

thanks

[foggy]

Probably some kind of parallel activity took place at the time you initiated IR.