This page describes how Content Router can be used for disaster recovery, backup, and archiving.
In these scenarios, it may be necessary to recover lost content data from a remote cluster. The recovery process and the ease and speed in which it occurs will depend somewhat on your network topology.
Administrative Disaster Recovery
If your network topology involves a one-way connection between the primary and DR clusters, then recovering from a disaster that causes data loss must involve an administrative process to reverse the data flow. This is because the primary cluster in such a topology is running only a Publisher service, which moves data from the primary cluster to the DR. If one or more nodes in the primary cluster were destroyed and you needed to move data in the other direction for recovery purposes, the primary cluster (and perhaps the DR cluster) must be reconfigured to run one or more Replicators, allowing the DR site to reconstitute lost data in the primary. Any lost data will be unavailable until the loss is discovered and corrected by the two Content Router nodes.
Note: Administrators who temporarily install a Replicator or Publisher service on a Content Router node as part of a DR event should plan to uninstall the temporary service when all of the original objects are replicated back to the source cluster. Otherwise, the temporarily-installed service may unintentionally create a mirrored configuration when the cluster returns to normal because both services will be installed on the same server.
In a mirrored architecture where the primary and DR clusters are both running paired Publishers and Replicators, the Content Router nodes will ensure that all appropriate data exists in both clusters at all times. If there is a disaster in the primary cluster, the data can be repopulated using the Republish function in the DR Publisher admin console.
In the administrative disaster recovery and content mirroring scenarios, the data loss can be corrected. However, the recovered data will be unavailable to applications in the primary cluster until the Content Router nodes complete the recovery process. If these applications are made aware of the presence and address of the remote DR cluster, and if they have visibility and access to the remote, then the applications can automatically fail-over to the remote cluster in the event a stream is not currently accessible in the primary.