September 2023
This document describes how Replicator responds to various Continuity of Operations Plan (COOP) and Disaster Recovery (DR) scenarios. Although Replicator can be configured similarly for both scenarios, we recommend a separate configuration between your primary farm and disaster recovery farm. The disaster recovery-specific configuration is described later in this document.
Continuity of Operations Plan (COOP)
Configuring Replicator for Disaster Recovery
Continuity of Operations (COOP) can be described through a variety of scenarios, but essentially it ensures that users have continuous access to up-to-date content. Replicator helps ensure the continuity of operations for organizations by providing up-to-date content to all end-users, regardless of geographic location. This is where geo-replication and COOP cross paths in terms of their purpose.
Disaster Recovery can be described as a tool, or safeguard, that ensures that the continuity of operations is maintained regardless of possible scheduled or unscheduled outages.
A scheduled outage can be anything that requires a planned data-center outage for an upgrade, a planned take down of a web front-end or an entire SharePoint farm.
An unscheduled outage includes any kind of fail-over scenario in which administration is not given the option to prepare or manually stop replication � this includes power outages, network issues, and natural disasters.
In the event of either a planned and unplanned outage, a Disaster Recovery environment is key to have in place, as it ensures that COOP is maintained. It is important to note that our recommendation is to set up a Disaster Recovery environment using one-way replication. A DR environment is strictly for the purpose of backing up and recovering all content in the event of a planned or unplanned outage.
Replication is initially set up using a one-way connection that replicates all content regularly from your main server to your DR environment. In the event of a planned or unplanned outage on this main server, pause the one-way connection from your main server to the DR server, and direct all of your users to your DR environment. Here end-users can continue to use SharePoint as per usual, where all changes will be replicated and placed in a queue. Once your main server is back up and running, set up a connection from your DR to your main server and then pushing the event queue with all changes back over.
There are various ways in which this can be done; the ultimate method of redirection is up to you.
The simplest solution in this scenario is to have your IT team send out a mass email, notifying all end-users that your main server is down, and that the backup or Disaster Recovery server should be accessed for all SharePoint use until further notice.
More advanced solutions include having a load-balancer set up between your main server farm, and your Disaster Recovery farm. The load balancer can detect that the primary site is unavailable and then automatically redirect all inbound users to the DR site.
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center
