Instant VM Recovery

[ChrisJ83Knights]

Hi

We are currently in the process of doing a spec for our backup server and wanted to ask a question in relation to backup file location.

One of the VMs we backup has high IOPs requirements and needs to be on SSDs in the production environment, with this in mind the spec at the moment is LFF disks with SSD for cache for all backups apart from the VM in question. We would then have another array of SSDs in a RAID 5 configuration where the VMs backup files would sit.

Would this then mean when doing an instant VM recovery on the VM it would utilise the SSDs as the backup files sit on them? Giving us the IOPs required?

Is there any other folders through Veeam which hold the temp/changed files of Instant VM Recovery that would benefit from being on the SSD array as well?

Any help/advice appreciated.

[DGrinev]

Hi Chris,

Would this then mean when doing an instant VM recovery on the VM it would utilise the SSDs as the backup files sit on them? Giving us the IOPs required?

That's correct, the more IOPs you have on the repository storage the better performance you'll get.

Is there any other folders through Veeam which hold the temp/changed files of Instant VM Recovery that would benefit from being on the SSD array as well?

Nope, the changes during instant recovery process will be written to the production storage. Thanks!

[iav]

Is it possible to change VM parameters for instant vm recovery of agent backups? At least to recover disks as thin provisioned (not to get space on storage up to maximum size of a physical devices), memory size and cpu count?
Suddenly disaster-recovered VM made from physical servers can me a large smaller than original hardware, but now ther need to have a 16 cpu and 256 GB ram vm to make instant restore from 16 cpu and 256 gb server.

[foggy]

No, these parameters cannot be changed upon Instant Recovery.

[ChrisJ83Knights]

Does Instant VM Recovery just utilize the latest incremental backup or does it use the latest full and incremental?

[Mike Resseler]

Chris,

If you select the latest restore point (and it is an incremental) it will start the VM based on the needed data in the chain. That means it needs a full and 1 or more incrementals to become the VM again. With the incremental alone it won't have all the data needed to start the VM.

[george.jame]

I have a question about Instant recovery feature

Due to restore vm in instant recovery there are 2 options :
1 - Redirect write cache : As I understand while we select a datastore for redirect write cache just all of new data will be write on this datastore due instant recovery is running and that is prefer use a datastore with high iops disk such as SSD disk ?

2- vPower NFSDatastore: By default my path is : C:\ProgramData\Veeam\Backup\NfsDatastore on veeam server
2-1 - Is that recommend change this path and select a path that contain disks with high performance ?
2-2 : which of above paths are important due instant recovery that user don't sense low performance on latency on disks?

[george.jame]

Would you please help me about that ?

[Egor Yakovlev]

Hi George.
Redirected write IO will go to the selected datastore, so yes, faster it is - the better write performance will be on Instantly Restored VM.
Read IOs are coming from backup files, which reside on a Backup Repository storage subsystem, so faster backup storage - faster Read IO will Instantly Restored VM have.
Location\performance of vPower NFS cache folder is secondary in that scenario.
/Cheers!

[george.jame]

As I understand the write speed and performance is directly related to redirect write cache datastore that we select due instant recovery wizard

and Read performance and speed is directly related to as follow orders :
1- The repository that backup has been resided on that .
2- vPower NFS mount point that we selected.

Is that correct ?

[Egor Yakovlev]

That is correct.
Also note since it is NFS, network load should be tracked as well as it might become bottleneck(say you use 1g between vPowerNFS server and repository, your max throughput will never exceed 125MB\s with 100% network load, which never the case) and whole idea of faster storages\ssd caches diminishes.