ZCB can be used to take backups of an SQL Server cluster. However, because ZCB is not fully "cluster-aware", there are certain restrictions to be aware of and requirements that must be met.
ZCB must be installed and a matching backup set configured on all nodes in the cluster.
- Install ZCB on the node which is preferred (primary) owner for the SQL Cluster resource.
- A new registry key ClusterName (Type = String) must be created in HKLM\Software\Zmanda\ZWC\1.0\Engine\ . Key value must be name of SQL Cluster
- Configure a SQL Server backup set in ZCB
- Backups on the primary node can be configured as FULL and DIFFERENTIAL backups. Please see Differential Backups in a SQL Server Cluster below.
- Move SQL instance to another node and repeat ZCB install and configuration.
- Deactivate the new SQL backup set. Right click the backup set and select Deactivate.
- Configure only FULL backups on all other nodes. Please see Differential Backups in a SQL Server Cluster below.
- Repeat step 3 for all nodes in the cluster.
- Move SQL instance back to the preferred (primary) node.
Moving SQL Instance Between Cluster Nodes After Initial Setup
If you move SQL instance from the primary cluster node to another node after initial setup, you must also adjust your ZCB configuration, unless you are planning to move resource back before scheduled backup takes place.
- First, Deactivate the SQL backup set on the current node.
- Move SQL instance to the another node.
- Activate the backup set on the new node.
Differential Backups in a SQL Server Cluster
Because ZCB is not fully cluster-aware, you must take great care when using Differential backups in a clustered environment. Imagine the following scenario:
- Your first Full backup is taken on Node 1 (the preferred owner) at transaction/record 100. SQL Server records that Full backup is taken.
- This backup would contain transactions/records 1 - 100. Type = Full.
- Your next backup, still on Node 1, is a Differential backup taken at transaction 150. SQL Server records that Differential backup is taken.
- This backup would contain transactions 101 - 150. Type = Differential. Corresponding Full is 1-100
- Now you move SQL Server to Node 2 at transaction 200 and take a backup. ZCB on this node is not aware of the backups on the other node, so you must take another Full backup.
- This backup would contain transactions 1 - 200. SQL Server records that Full backup is taken at transaction 200
- At this point, you move SQL back to Node 1 and take a Differential backup at transaction 250. SQL Server has record that the last Full backup was at transaction 200.
- This backup would contain transactions 201 - 250.
- However, the last Full backup on this node only contains transactions 1 - 100.
- Now there is a problem. Transactions are missing from the backup chain. Only the Full backups can be restored.
- A restore of the Full backup on Node 1 would only contain records 1 - 100. The only Differential backup can be restored is the one containing transactions 101 - 150. Transactions 151 - 250 are lost.
- A restore of the Full backup on Node 2 would only contain records 1 - 200. The Differential backup from Node 1 cannot be restored to Node 2. Transactions 201 - 250 are lost.
To avoid issues such as the above, we recommend:
- Use Full or Differential backups only on the single primary node - i.e. on preferred owner of SQL instance cluster resource.
- Only use Full backups on all other nodes.
- If SQL data has been backed up, while residing on other then primary node, then, when you move SQL instance back to the primary node, the first backup taken must be a Full backup.