Backing Up and Restoring the Failover Cluster Configuration Using VSS
Failover clustering uses the Volume Shadow Copy Service (VSS) for backing up and restoring the failover cluster configuration.
While a node is not part of a cluster or the cluster is down, the cluster configuration file (ClusDb) can be treated like any other registry hive. If the cluster is running, ClusDb will have to be committed on reboot as part of the registry. For information on handling registry backups and restores under VSS, see Registry Backup and Restore Operations Under VSS.
Because of the distributed nature of clusters, backing up a ClusDb is not sufficient to ensure that the full cluster state has been saved. This state is contained in the quorum resource or database.
For a backup application to successfully save the state of a clustered system, at a minimum it will need to perform the following steps:
- Detect whether the system is a clustered system and determine its current state.
- Select a clustered node for backup.
- Back up the clustered database and registry in a checkpointed form.
Backing Up the Cluster State Using VSS
The first step in backing up or recovering a clustered system is to detect clustering services and determine their state using the GetNodeClusterState function.
If clustering services are installed and running, backup applications (requesters) should choose to treat the system as a cluster. If clustering services are installed but not running, backup applications should treat the system as a stand-alone server.
If clustering services are detected, a backup application can display the cluster by name for backup. The cluster name can be determined by passing either the machine name or NULL to the OpenCluster function and retrieving a handle to the cluster to which the current node running the backup application belongs.
It is best to pass "machine name" as a parameter to the OpenCluster function if possible because this will ensure that the client is connected to the cluster even if the cluster service stops on the node to which the client is initially connected.
After the application has a handle to the cluster, the GetClusterInformation function will provide information about the cluster, including its name.
Now, ClusDb can be backed up using VSS.
Restoring the Cluster State Using VSS
There are two parts to restoring the cluster state:
Restoring the node. This is completely taken care of in a system state restore on that particular node.
If the rest of the cluster is running and you do not want to restore the cluster, stop at this point and restart the node; it should rejoin the cluster.
If the cluster needs to be restored or rolled back in time, you will need to do an authoritative restore and restore the cluster.
Restoring the cluster. To perform such a restore, the cluster service has to be installed but not necessarily running on the node being restored. All other nodes in the cluster must have the cluster service stopped. The IVssComponentEx2::SetAuthoritativeRestore method is used to indicate that an authoritative restore is being performed.
The Cluster VSS Writer will specify a restore method of VSS_RME_RESTORE_STOP_START to indicate that the specified service is to be stopped and restarted. For more information, see the description of the VSS_RME_RESTORE_STOP_START enumeration value in the VSS_RESTOREMETHOD_ENUM enumeration topic. After the cluster service has been started, the other nodes on the cluster can have their cluster service restarted.
Details on the Failover Cluster VSS Writer
Writer Name: Cluster Database
Writer ID: 41e12264-35d8-479b-8e5c-9b23d1dad37e
Related topics