Sitecore Experience Manager

The HADR basic process

Abstract

Learn about the process involved in recovering your data with HADR basic.

If an outage occurs in the primary datacenter, Sitecore creates a completely new production environment in a secondary datacenter. While the secondary environment is being created, customers will see a basic outage page so they are aware that your site is temporarily down.

The HADR basic recovery option has the longest recovery time objective (RTO), but is the least expensive because Sitecore must create a completely new environment in a secondary datacenter.

Sitecore Managed Cloud uses the Sitecore Disaster Recovery service to offer the following three options to maintain a high availability disaster recovery (HADR) service:

The HADR basic recovery option has the longest recovery time objective (RTO), but is the least expensive because Sitecore must create a completely new environment in a secondary datacenter.

HADR_Basic.PNG

With HADR basic, the Sitecore Managed Cloud disaster recovery service sets a process in to action in the event of an outage. The steps of this process include:

  1. Scheduling a reoccurring backup, that occurs every 3 hours, of the following assets into the secondary database of the recovery point objective (RPO):

    • The databases.

    • The web applications.

    • The connection strings, (for the credentials).

    • The sizes/tiers of the resources.

  2. Arranging an outage page for customers to see while your site is down.

  3. Setting the traffic manager to switch between the primary Content Delivery (CD) server and the outage page.

  4. Setting up email alerts to notify the Managed Cloud Operations team if the availability tests fail.

When a disaster occurs, Sitecore immediately requests confirmation from you to run the full recovery process. With confirmation, Sitecore triggers a recovery process. The steps of this process include:

  1. Deploying a new Sitecore environment to the secondary datacenter.

  2. Restoring the web applications from the previous backup.

  3. Restoring the databases from the previous backup.

  4. Updating the connection strings with the credentials from the primary Sitecore instance.

  5. Re-indexing the content and xDB indexes.

  6. Switching the traffic manager over to the secondary Sitecore instance.

After Sitecore has enacted the failover process, and the cause of the disaster has been fixed, you and the Managed Cloud Operations team will agree on a time to to return to the primary datacenter.

At this point, the data in the primary datacenter is stale, therefore Sitecore will repeat the failover steps to export the secondary instance into the primary datacenter and update the the data in the primary instance.