Please enter search query.
Search <product_name> all support & community content...
Best Practices for managing System Recovery (SR) within a Microsoft Windows Failover Cluster Environment
Article: 100029828
Last Published: 2025-05-07
Ratings: 0 0
Product(s): System Recovery
Problem
Best Practices for managing System Recovery (SR) within a Microsoft Windows Failover Cluster or Server Cluster Environment
Solution
This document describes the use of Veritas System Recovery with Microsoft Windows Failover Cluster or Server Clusters.
Recovery points of servers in a Windows cluster environment can be captured using System Recovery. SR enables the quick restore of the servers for the proper working order in the event of a failure. However, to ensure success, proper steps need to be taken when creating and restoring recovery points of a server in a cluster environment.
Capturing Recovery Points
Best practices for capturing recovery point images with System Recovery in a Windows server cluster environment include the following:
- Installing System Recovery on all nodes within the Microsoft Windows server cluster.
- The System Recovery Disk (SRD) may not be able to identify the shared storage volume when booted in pre-OS mode. Hence, recovery points of a cluster node should not be stored on a shared-storage volume. This can be tested first by booting a node in the cluster with the SRD. In most cases recovery points of the operating system should be stored on a volume other than the shared-storage, such as local disk drives, separate Windows server shares, or NAS devices that are not shared by the cluster.
Restoring a Single Node in Cluster
To restore recovery points of a node in the cluster, perform the following steps:
1. Boot the System Recovery Disk on the node that needs to be restored.
2. It can be difficult to determine which physical volume to restore to since drive letters are likely assigned differently than they are in Windows. If there is any confusion about if the volume is local to the node that is being restored, then temporarily disconnect any external storage.
3. Restore the recovery point of the operating system volume. Make sure that the option to recover the original disk signature is selected so that the drive letter mappings will be preserved. If the option is available select the option to restore the domain trust token.
4. Start the server into Windows OS.
Verify that connections to the shared storage are active.
Restoring an Entire Cluster
To restore recovery points of an entire cluster, perform the following:
1. Take all the cluster nodes offline.
2. Restore one cluster node from the System Recovery Disk as per the above steps.
1. Boot the System Recovery Disk on the node that needs to be restored.
2. It can be difficult to determine which physical volume to restore to since drive letters are likely assigned differently than they are in Windows. If there is any confusion about if the volume is local to the node that is being restored, then temporarily disconnect any external storage.
3. Restore the recovery point of the operating system volume. Make sure that the option to recover the original disk signature is selected so that the drive letter mappings will be preserved. If the option is available select the option to restore the domain trust token.
4. Start the server into Windows OS.
Verify that connections to the shared storage are active.
Restoring an Entire Cluster
To restore recovery points of an entire cluster, perform the following:
1. Take all the cluster nodes offline.
2. Restore one cluster node from the System Recovery Disk as per the above steps.
3. Boot the cluster node into Windows, and restore the Quorum volume to its original location on the shared storage (note that a Microsoft Quorum volume can only exist on a basic disk).
4. Either restart into Windows to restore the shared storage volumes(s) or restore them from the SRD. Note that the data volumes are easier to identify in Windows.
5. In Windows re-establish the shared storage connections.
6. Restore the remaining nodes using the System Recovery Disk.
7. Verify that the cluster is running properly.
What is supported?
Supported Operations
In a server cluster environment for Microsoft Windows, System Recovery provides support for the following operations:
4. Either restart into Windows to restore the shared storage volumes(s) or restore them from the SRD. Note that the data volumes are easier to identify in Windows.
5. In Windows re-establish the shared storage connections.
6. Restore the remaining nodes using the System Recovery Disk.
7. Verify that the cluster is running properly.
What is supported?
Supported Operations
In a server cluster environment for Microsoft Windows, System Recovery provides support for the following operations:
- Creation and Restoration of an active node OS Recovery Point in a multi-node cluster.
- Creation and Restoration of a passive Node OS Recovery Point in a multi-node cluster.
- Creation and Restoration of a Quorum Disk volume recovery Point. Restoration of Quorum Disk volume recovery points should be done within Windows, due to volume order and driver letter assignments being unpredictable when booting to the SRD.
The creation and restoration of the
shared-storage volume images (
Note: A proper presentation of the shared-storage volume must be available in Windows Disk Management before the restoration). To achieve this, the shared-storage volume recovery must be performed within Windows on an active node.
Operations Not Supported
System Recovery does not support the following operations in Microsoft Windows Failover Cluster or Server Cluster environments:
Operations Not Supported
System Recovery does not support the following operations in Microsoft Windows Failover Cluster or Server Cluster environments:
- The creation and restoration of operating system images where the operating system resides on a shared-storage volume.
- Restoring a quorum volume image to a different drive mapping than the original that existed before the recovery.
- Restoring a Quorum volume from the System Recovery Disk (SRD).
- The schedules after a failover. Currently, schedules after a failover become non functional.
Was this content helpful?
Translated Content
Please note that this document is a translation from English, and may have been machine-translated. It is possible that updates have been made to the original version after this document was translated and published. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.