If your looking to do a nightly backup with Veeam you will be fine. I personally have restored Veeam backed database servers no issues.
Now if your looking at Veeam Replication, spinning hard drives are to slow but using SSD is ok. Below I pasted a bit from Veeam Best Practice Guide.
As for VMotion. Works great. If you have brokers using -H -S and find they disconnect you need to add extra configuration to the core switch.
Lynn
)(I attemtped to add the links for the content below however the site blocked me due to not having any Likes :{
Impact of Snapshot Operations
Veeam Backup & Replication leverages the vSphere functionality for snapshots to create backups of VMs.
When Veeam Backup & Replication begins the backup of a VM, it communicates with vSphere to request a snapshot of the VM, and after the backup of the VM is complete, Veeam requests that the snapshot be removed. The creation and removal of snapshots in vSphere creates a significant impact on the environment that must be taken into account. Here we will discuss the various factors that should be considered regarding this process, and recommend techniques to minimize the impact of snapshot operations.
As a concept, vSphere snapshots are a simple technology. A VM generally contains at least one virtual disk, which is represented by a VMDK file. When a snapshot is taken, VMware continues to read blocks from the file as normal, however, for any new blocks that are written to the disk, these writes are redirected to a new “thin” VMDK file called the delta file. Since the original VMDK file is only being used for reads, it provides a consistent view of the blocks that made up the VM at the time the “snapshot” was taken - this allows Veeam Backup & Replication to read this based disk as a consistent image for backup and replication. When the snapshot is removed, the blocks that were written to the delta file are read and written back into the original VMDK, and finally the delta file is discarded.
As with many things in technology, although the concept is simple, the actual implementation is a little more involved. The following is a quick look at the impact of various operations on the VM and underlying infrastructure.
Snapshot Creation
The actual operation of creating a snapshot generally has only a minor impact: the snapshot file has to be created, and there is a very short “stun” of the VM. This is generally short enough so that it is rarely an issue except for the most time-sensitive applications.
Note For normal snapshot operation, try to keep the size of the vmdk disk under 1.98 TB, otherwise snapshot creation may fail due to known VMware limitations. For details, please refer to VMware Knowledge Base article 1012384.
Snapshot Open
Simply having a snapshot open for a running VM involves some performance penalty on the VM, the ESX(i) host and the underlying storage. The host has to track the I/O, split writes to the snapshot file, update the snapshot file metadata. This extra overhead, in turn, impacts the host (primarily, with slower I/O). This is generally most notable for VMs with significant write load, and has less impact on read performance.
From a storage perspective, VMs running with an open snapshot require the additional space to store the snapshot data, and additional I/O load on the datastore. Once again, this is generally more noted on systems with significant write I/O load.
Note Also, remember that vMotion cannot be performed for VMs with an open snapshot.
Snapshot Removal
This is the most impactful step from a performance perspective. I/O load increases significantly, due to the extra R/W operations required to commit the snapshot blocks back to the original VMDK. This eventually leads to the VM “stun” required to commit the final bits of the snapshot. The “stun” is typically a short pause usually only a few seconds or less, where the VM is unresponsive ("lost ping") while the very last bits of the snapshot file are committed. VMware uses a “rolling snapshot” method to minimize the impact and duration of the stun as outlined below:
1. The ESX(i) host takes a second, “helper” snapshot to hold new writes.
2. The ESX(i) host reads the blocks from the original snapshot and commits them to the original VMDK file.
3. The ESX(i) host checks the size of the “helper” snapshots, if over the threshold size, repeat step 1.
4. Once all helper snapshots are determined to be under the threshold size, “stun” the VM and commit the last bits of the snapshot.
This “stun” period can be less than 1 second for small VMs with light load, or several seconds for larger VMs with significant load. To external clients this small stun simply looks like the server is “busy” and thus might delay a response for a few seconds. However, applications that are very sensitive to delays may experience issues with this short period of unresponsiveness.
Please refer to VMware Knowledge Base article 1002836 for explanation of snapshot removal issues.
