# Disaster Recovery & Business Continuity

> Source: https://agilitycms.com/docs/owners-admins/disaster-recovery-and-business-continuity

Agility CMS is built on Microsoft Azure's resilient infrastructure, with automated backups and multi-region recovery capability for the content platform. In a regional outage, the management platform and content APIs can be recovered to a secondary Azure region, while the static/edge delivery layer continues serving already-published content to end users (see *SLA & Uptime*). Backups are taken automatically and retained so that an instance can be restored to a recent point in time. The platform's recovery objectives (RTO/RPO) are defined commitments; the implementation partner remains responsible for the disaster-recovery posture of the customer's own front-end application and hosting.

## Resilience model

Two distinct layers determine continuity, and they fail independently:

1. **Management & content-authoring layer** (Content Manager, Management/Fetch APIs, database). This is the system of record on Azure and is the focus of DR planning below.
2. **Delivery layer** (edge/CDN and the customer's statically generated or cached front end). Because published content is distributed to the edge and customer front ends are typically statically generated, **end users can continue to be served already-published content even during an origin/management-layer event.** This decoupling is central to Agility's business-continuity story.

## Multi-region disaster recovery

Agility leverages Azure's regional architecture for recovery. Each instance has a primary region (the selected data region — see *Data Residency & Data Regions*). For disaster recovery, data and services can be recovered in a secondary Azure region.

Agility maintains **defined Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets** as part of its documented business-continuity and disaster-recovery program, along with a defined secondary-region recovery model. **The specific recovery objectives, secondary-region pairings, and replication details are available on request** — including under NDA as part of an RFP or security review. [Contact Agility](https://agilitycms.com/contact-agility-cms) for the current figures.

## Backup model

Agility's content is backed up automatically and can be restored to a recent point in time. Because Agility runs as a managed cloud service on Microsoft Azure, disaster recovery is concerned with data, applications, and deployments rather than physical hardware restoration.

At the content level, Agility's **version history** is a complementary first line of recovery: editors can restore a prior version of any content item or page themselves, which addresses everyday editorial mistakes without a platform-level restore.

**Backup replication stays within the same broader regional (country) boundary** — for example, an instance in Canada Central is replicated within Canada (to Canada East). This means disaster-recovery replication does **not** move data out of the residency boundary: Canadian data stays in Canada. (See *Data Residency & Data Regions*.) Specific backup retention and restore-time details are available on request (including under NDA) — [contact Agility](https://agilitycms.com/contact-agility-cms).

## Failover and restore process

![Primary/secondary region failover: in normal operation traffic routes to the active primary region replicating in-country to a standby secondary, with the edge serving cached published content; on failure, routing swings automatically to the secondary with no change to customer URLs, and the edge keeps serving published content throughout.](https://cdn.aglty.io/agility-cms-docs/images/owners-admins/diagram-region-failover.svg)

Agility's services run on Microsoft Azure with **automated failover across multiple regions** — the platform is pre-configured to redirect to a secondary region if the primary becomes unavailable, and content/API and asset delivery continue serving (cached) content throughout. In the rare case of a simultaneous multi-region outage, Agility's recovery process redeploys the service into an available region. Agility maintains a documented **Business Continuity & Disaster Recovery Plan** with defined activation triggers, roles, and communications, and **tests disaster recovery (including backup restoration) at least annually**.

Failover is **transparent to customer applications: API URLs and endpoints do not change** when a failover occurs, so no client-side reconfiguration is required. During an incident, Agility notifies affected customers (with regular updates) through its support channels per the BC/DR plan.

The detailed runbook, activation criteria, most recent DR test results, and recovery-time figures are available on request — including under NDA — by [contacting Agility](https://agilitycms.com/contact-agility-cms).

## Business continuity during an event

Because the delivery layer is decoupled from the management layer, this is built into Agility's documented continuity procedures. Per the BC/DR plan, if the **Content Manager** is unavailable, **customer websites, API services, and asset delivery remain unaffected** — editors may be temporarily unable to log in or publish, but end users keep receiving already-published content. Likewise, during a single-region Azure event, API and asset delivery continue **serving cached content** while failover completes.

- **Published content keeps serving.** Statically generated/edge-cached front ends continue delivering the last-published content to end users even if the management layer is degraded.
- **Authoring may pause.** During a management-layer event, content editing/publishing may be temporarily unavailable until recovery completes; this does not affect live end-user delivery of already-published content.

This separation is why public-facing availability can remain high even during a content-platform incident — see *SLA & Uptime* for how this produces effective five-nines end-user availability.

## Shared responsibilities

| Area | Agility | Implementation partner / customer |
| --- | --- | --- |
| Platform backups & multi-region recovery | ✅ Automated backups; recovery of management/API layer to secondary region | — |
| Platform RTO/RPO | ✅ Defines and meets stated objectives | Aligns its own continuity plan to these objectives |
| Front-end app & hosting DR | — | ✅ Designs the website/app for resilience (static generation, multi-region hosting, its own CDN failover) |
| Content-level recovery | ✅ Provides version history + platform restore | ✅ Uses version history to recover from editorial mistakes; defines internal restore-request process |
| Incident response coordination | ✅ Detects, declares, communicates platform incidents | ✅ Monitors its own app; defines internal comms and runbook |