• 

General Tips for VMware and Hyper-V:

• Use Veeam ONE!! Veeam ONE tracks the underlying backup change rates that generate “suspicious incremental backup size” alerts.
• pCPU to vCPU ratio 2:1, recommended 1:1
• Size the Exchange VM in a way, that it can run within a single NUMA node.
• Use thick provisioning for the disks for better performance
• Do not enable deduplication or compression on your primary storage that runs the virtualized Exchange workload.
• Use virtualization infrasturcture anti-affinity rules to avoid that members of the same DAG run on the same virtualization host.
• Exchange Server usually uses a lot of memory. Don´t forget to plan enough disk space for the Pagefiles.
• Do not use Dynamic Memory
• Reserve 2 physical Cores for the Host OS

Exchange DAG backup Tips:

• Reduce total amount of disks (.vmdk’s) for primary node if possible, reducing impact of snapshot operations.
• Microsoft Exchange hosted Virtual enviroment, it’s recommended to create a single job and add all the DAG node in the same node for the better deduplication and compression.
• Also, to avoid performances impact it’s recommended to have passive only Exchange node for backup.

To avoid failover during the backup you should adjust cluster timeouts:

Adjust Microsoft settings for failover sensitivity (in bold, run from command line): cluster /prop SameSubnetDelay=2000:DWORD (Default: 1000) cluster /prop CrossSubnetDelay=4000:DWORD (Default: 1000) cluster /prop CrossSubnetThreshold=10:DWORD (Default: 5) cluster /prop SameSubnetThreshold=10:DWORD (Default: 5)

• Use Network (NBD) mode setting on Source Backup Proxy as opposed to Appliance (hotadd) mode for your backup and/or replication jobs in Veeam
• Disable all background scanning and/or maintenance tasks occurring in Exchange, or any other tools that are being leveraged against the system at the time of backup such as Email Archiving, anti virus scanning etc.
• Do not use vRDM. Sometimes architect think that the last bit of performance enhancement is really needed but forget that there are several downsides of that decisions. Specifically if the VM run in Snapshot mode all writes will go to snapshot files that are usually placed next to the vmx file. You can change the folder by changing the work dir to another storage area, but overall all disks will have the snapshot file in the same folder on same storage. You will see a write performance reduction during backup (or during manual created snapshots) and snapshot commit is hell when fast IOs are neeed with low latency.  => Use vmdks as the snapshot files are placed in the same storage area.
• To reduce Snapshot commit time (and to reduce data in the snapshot), try to avoid any changes at the backup time window (User, Background processes, Antivirus, ….).
• To reduce backup time window and snapshot lifetime, use Direct SAN or Direct NFS Mode. If you can not use one of them, use NBD-Network mode for Exchange backups. Avoid in any way HotAdd processing with NFS Datastores
• Delete all existing VM Snapshots before you start. Existing SnapShot can slow I/O at Storage processes like Snapshot commit. As well existing snapshots will make it impossible to enable VMware Change Block Tracking. This could lead into  100% data read at any backup(Snap and Scan Backup), which cause longer Snapshot lifetimes with longer snapShot commit phases.
• If the VM resides on a datastore backed by NFS storage, consider migrating the VM to VMFS storage.