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 http://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
- 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
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
- 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.
- Managing a Failover
- For additional information about backing up
and restoring failover clusters, see http://go.microsoft.com/fwlink/?LinkId=92360.
- For additional operations information for
failover clusters, see http://go.microsoft.com/fwlink/?LinkId=137835.
- For troubleshooting information for failover
clusters, see http://go.microsoft.com/fwlink/?LinkId=137836.