Backing Up and Restoring Clustered Environments

As you might have already guessed, backing up a server cluster is not exactly the same as backing up and restoring a stand-alone server. You have other dependencies, namely the cluster database and the registry settings for clustering.

More Info

For more information on the objects listed in this section, consult Chapter 5, Designing Highly Available Microsoft Windows Servers.

Backing Up a Standard Server Cluster

In terms of backing up the necessary components to perform an eventual restore, you need to understand how backup programs interact with clustering. If you choose to only back up the system state data (as seen in Figure 10-15), only the quorum disk and the system state data will be backed up ”nothing else. A backup that contains this information has the following:

• \Mscs\Chkxxxx.tmp These are the cluster database snapshot files.

  Tip

  If there is more than one of these files, you might have had some problems on your cluster, and should evaluate before backing up potential corruptions.

• \Mscs\Quolog.log The cluster log file.

• \Mscs\ < GUID of resource > The registry checkpoint files for the .cpt resource (identified by GUID).

• \Mscs\ < GUID of resource > The crypto checkpoint files for the .cpr resource (identified by GUID).

• \Mscs\Clusbackup.dat A read-only, hidden file that is 0 bytes in size , and is the backup completion marker file.

  Important

  When you elect to back up the system state data, the local node s cluster registry hive, also known as clusdb (\Mscs\Chkxxx.tmp is a binary copy of clusdb), is not backed up because the quorum, which is the master, is backed up. Because the file is open and locked, you might see some errors such as Completed with Skipped Files and Examining the NTBackup log, both Clusdb and Clusdb.log failed to be backed up. You can ignore these errors because \Mscs on the quorum drive has been backed up.

  Important

  Back up the system state data only on the node that owns the quorum; otherwise you will encounter errors. Also, you need to back up the quorum s system state data only once because it will take care of the entire cluster. Do not move the quorum resource to each node when backing up system state data.

After you have backed up the system state data, you should back up each individual node s files, software, and system state data. Remember that each node of the server cluster that does not own the quorum drive in a standard server cluster will not back up anything on the quorum drive.

Note

If you understand the technology behind a server cluster, you might conclude that you hardly ever need a backup because there are always at least three copies on the cluster at any given time. However, to full cluster-aware applications such as SQL Server, checkpoints are important, and you might want to use tools specifically designed for this and other purposes such as CLUSTOOL and CLUSDIAG. At the time of the launch of Windows Server 2003, CLUSDIAG was only available for that version, but will be released for Windows 2000 at a later date.

Third-Party Backup Software and SQL Server 2000 Failover Clustering

Ensure that when you evaluate enterprise-class third-party backup software, it works properly in a cluster and is truly cluster-aware. As discussed in Chapter 6, Microsoft SQL Server 2000 Failover Clustering, you do not want resources to depend on any SQL Server resources that do not need to be there. Some third- party backup packages technically work in a cluster; however, to be able to operate , they add their own resources into your SQL Server virtual server s resource group and make them dependencies of the disks with the data and log files. This is otherwise known as a generic application in a server cluster.

Warning

If you must implement backup software that is not fully cluster-aware on your cluster that must have dependencies placed on SQL Server resources, you must check to see that the Do Not Affect The Group option is selected on the Properties tab of the added third- party generic resources. After configuring this option, if that resource fails, it will not take your SQL Server disks offline, which will in turn take your SQL Server instance offline and cause a failover that you did not want. Some third-party programs also do not contain any logic to handle clustered situations and simply restart all of that day s backup jobs from scratch after a failover. Because you do not want to restart all backup jobs, you might also want to disable the Restart option on the Properties tab in addition to selecting Do Not Affect The Group.