Understanding Backup and Recovery Basics for a Failover Cluster
Applies To: Windows Server 2008 R2
This topic outlines some basic guidelines for backing up and restoring a failover cluster. For more information about backing up and restoring a failover cluster, see https://go.microsoft.com/fwlink/?LinkId=92360.
Backing up a failover cluster
When you back up a failover cluster, you can back up the cluster configuration, the data on clustered disks, or both.
Backing up the cluster configuration
When you back up the cluster configuration, take note of the following:
For a backup to succeed in a failover cluster, the cluster must be running and must have quorum. In other words, enough nodes must be running and communicating (perhaps with a disk witness or file share witness, depending on the quorum configuration) that the cluster has achieved quorum.
For more information about quorum in a failover cluster, see Understanding Quorum Configurations in a Failover Cluster.
Before putting a cluster into production, test your backup and recovery process.
If you choose to use Windows Server Backup (the backup feature included in Windows Server 2008 R2), you must first add the feature. You can do this in Initial Configuration Tasks or in Server Manager by using the Add Features Wizard.
When you perform a backup (using Windows Server Backup or other backup software), choose options that will allow you to perform a system recovery from your backup. For more information, see the Help or other documentation for your backup software.
Backing up data on clustered disks
When you back up data through a cluster node, notice which disks are Online on that node at that time. Only disks that are Online and owned by that cluster node at the time of the backup are backed up.
Restoring to a failover cluster from backup
When you restore to a failover cluster from backup, you can restore the cluster configuration, the data on clustered disks, or both.
Restoring the cluster configuration from backup
The Cluster service keeps track of which cluster configuration is the most recent, and it replicates that configuration to all cluster nodes. (If the cluster has a disk witness, the Cluster service also replicates the configuration to the disk witness). Therefore, when you restore a single cluster node from backup, there are two possibilities:
Restoring the node to normal function, but not rolling back the cluster configuration: This is called a "non-authoritative restore." In this scenario, the reason you use the backup is only to restore a damaged node to normal function. When the restored node begins functioning and joins the cluster, the latest cluster configuration automatically replicates to that node.
Rolling back the cluster configuration to the configuration stored in the backup: This is called an "authoritative restore." In this scenario, you have determined that you want to use the cluster configuration that is stored in the backup, not the configuration currently on the cluster nodes. By specifying appropriate options when you restore the backup, you can cause the cluster to treat the restored configuration as the "most recent." In this case, the Cluster service will not overwrite the restored configuration, but instead will replicate it across all nodes. For details about how to perform an authoritative restore, see the Help or other documentation for your backup software.
Restoring data to clustered disks from backup
When you restore backed-up data through a failover cluster node, notice which disks are Online on that node at that time. Data can be written only to disks that are Online and owned by that cluster node when the backup is being restored.
For additional information about backing up and restoring failover clusters, see https://go.microsoft.com/fwlink/?LinkId=92360.
For additional operations information for failover clusters, see https://go.microsoft.com/fwlink/?LinkId=137835.
For troubleshooting information for failover clusters, see https://go.microsoft.com/fwlink/?LinkId=137836.