• Suppose cluster nodes A and B are configured to use the same disks for their operation. If both of them are enrolled for protection, along with their shared disk configuration, only the cluster node that is currently using the shared disks can be backed up. If you attempt to back up the cluster node that does not have access to the shared disks, the backup will fail. Because the IP address of all the cluster nodes in the host table are set to the IP address of the cluster, any passive node in the cluster will indicate a RED status and backups will fail.

• When you start a cluster RN, you must select the RN for the node that was active at the time your desired backup was generated. For example, if you want the most recent data, then select the node with the most recent backup.The RN for the other nodes will contain stale information. If you want to roll back to a previous backup, you must select the RN that was active at that point in time.

• Recovery Node disks used in this context are basic disks, each with a maximum size limit of 2TB. The logical volume size for these disks is not expandable.

• If the PN configuration is switched between a standard and a cluster, the RN will be reinitialized and rebuilt.

• A cluster node that is protected with this configuration whose RN is brought in production can only be configured to work with virtual SAN. Registry modifications are done in the RN from the information provided in the onQ Portal for the specific node.

• A cluster node protected with this configuration is not suitable for a Bare Metal Restore as cluster service configurations are modified on the RN to work with a virtual SAN. Also, the failover cluster node is evicted from the configuration while preparing the RN. Only application data (SQL database, for example) can be retrieved/restored.

• There are additional cluster limitations if the PNs are agent‑less. Go to Agent‑less PN Enrollment Limitations.