Things to Consider:Cluster Shared Volumes

Cluster Shared Volume backups are fully supported in BackupChain Server Edition and Server Enterprise Edition.

It is recommended to limit read and write I/O speeds or to use separate network adapters for backup traffic, in order to keep the server network balanced.

You may need to use the domain administrator account for your iSCSI provider service in order to get the backup task to start successfully, depending on the iSCSI service you are using.

For live backups with VSS engagement (the recommended way to back up), you need to run BackupChain on the cluster node that actually hosts the VM you want to back up. You could back up virtual machines from another node as well using the file-based approach (discussed in previous section) but that approach “from a distance” does not involve VSS and hence will only give you a crash consistent live backup. A crash consistent backup is similar to a power loss event in a physical machine. Most production grade applications can handle a power loss event without data loss, such as a SQL database server. To achieve an application consistent live backup which will also notify the VM internally of the backup event, you need to run the backup on the same node that hosts the virtual machine you wish to back up. Application consistent backups require the VSS integration and this integration can only be managed from the VM’s host. VSS aware applications, such as database services and Exchange, prepare for live backup, flush their caches, and bring their file stores into a consistent state before the backup begins.

Do not perform a live migration while a backup is running because live backups cannot be processed when a VM switches hosts. Also, you need to configure BackupChain on the new cluster node when you reassign virtual machines to new hosts (select VM in Hyper-V tab table).

Note: You need to schedule CSV backups to run without overlaps because CSVs do not allow nodes to back up simultaneously.