As described in Cluster modes, disaster recovery (DR) is typically deployed in a WAN. The two nodes are in different subnets and geographic locations. After an event such as a natural disaster or power outage causes the primary node to fail, an administrator can manually recover replicated data from the secondary node (known as the DR node) at the unaffected site. Replicated data includes configuration data, security content updates, and if enabled, aggregated alert data. A reasonable amount of downtime is expected to restore the primary node and allow for a safe and stable recovery of services.
A DR deployment is typically running in maintenance mode. The purpose of the DR node is to store a copy of the replicated data, not to become the primary node and take over the management of appliances. To prevent the primary node from failing over to the DR node, you disable automatic failover on both nodes. You typically also disable the replication of alert data to optimize the performance of the low-bandwidth WAN link.
The following procedures recover the primary node after a failure:
Temporarily enable automatic failover on the DR node. This allows the DR node to become primary and transfer configuration data to the original primary node when it is restored.
Join the restored or replaced original primary node to the DR node to re-form the cluster.
Fail over the replicated data to the original primary node.
Disable automatic failover on the DR node to put it back into maintenance mode.
Configuring disaster recovery
Perform the following procedures to initially configure the nodes for a DR deployment.
Note
Automatic failover is a local configuration, so it must be performed on both nodes. Alert replication is a global configuration, so it only needs to be configured on one node.
Configure the primary node:
Log in to the CLI of the primary node.
Enable the CLI configuration mode:
node1-hostname > enable node1-hostname # configure terminalDisable automatic failover:
node1-hostname (config) # no ha node failover auto(Optional) Disable the replication of alert data:
node1-hostname (config) # no ha replicate alerts enableVerify your changes:
node1-hostname (config) # show ha configurationSave your changes:
node1-hostname (config) # write memory
Configure the DR node:
Log in to the CLI of the secondary node.
Enable the CLI configuration mode:
node2-hostname > enable node2-hostname # configure terminalDisable automatic failover.
node2-hostname (config) # no ha node failover autoVerify your changes:
node2-hostname (config) # show ha configurationSave your changes:
node2-hostname (config) # write memory
Recovering the primary node and restoring the configuration
Perform the following procedures to recover the primary node, and restore the configuration and other replicated data.
Temporarily enable automatic failover on the DR node:
Log in to the DR node.
Enable the CLI configuration mode:
node2-hostname > enable node2-hostname # configure terminalEnable automatic failover:
node2-hostname (config) # ha node failover autoVerify the status:
node2-hostname (config) # show ha configurationSave your changes:
node2-hostname (config) # write memory
Restore the primary node and join it to the cluster:
Restore or replace, and configure the primary node that failed.
Join the node to the cluster.
Wait until the cluster is formed and running:
node1-hostname (config) # show ha status
Fail over the configuration data:
Return to the DR node CLI session.
Fail over the configuration data:
node2-hostname (config) # ha engine failoverWait until failover is complete and the DR node is synchronized with the primary node.
node2-hostname (config) # show ha status
Return the DR node to maintenance mode:
Prevent automatic failover :
node2-hostname (config) # no ha node failover autoVerify your change:
node2-hostname (config) # show ha configurationSave your change:
node2-hostname (config) # write memory