VM Instant Recovery Limitations

The VMware Single Item Restore feature uses the Bacula BVFS interface to list files and directories. The Bacula BVFS interface is known to have some performance issues with MySQL catalog backend due to internal MySQL limitations with indexes on TEXT colums. For VMware and Exchange Single Item Restore there should not be too much impact on performances (the backup structure is usually quite small) but we advise using the PostgreSQL backend for the best experience.
The VMware Single Item Restore performance may vary depending on various factors. For example, Bacula will have to read more data if the Volume was created with a large number of concurrent jobs.
The Storage Daemon where the VMware Single Item Restore is installed should be have a CPU with the VT-x/EPT extensions. If these extensions are not available, the performance will be degraded. (From 20s to 10mins in our lab).
The VMware Single Item Restore is compatible with file based devices (cloud, dedup, aligned, file, etc..). Tape devices are not supported.
To perform VM Instant Recovery from a Copy/Migration job make sure destination Pool has Maximum Volume Jobs set to 1. Note that when you use MaximumVolumeJobs = 1 in the Pool resource, you must use MaximumConcurrentJobs = 1 in the Device resource(s).
The Instant Recovery hot migration only works with the VMware vMotion technology.
All volumes needed for the VMware Single Item Restore must reside on the single Storage Daemon instance where the SIR session is started. A storage group policy can conflict with this requirement.
To avoid heavy network traffic and prevent jobs from failing, do not run the vSphere plugin along the FD running on the SD with a storage group.
Client side PKI Encryption is currently not compatible with vSphere IR features. Use the Volume Encryption feature if needed.