---
schema_version: "1"
id: aa11b90bbb0c7beb2726c2fa4c734f7ad8fd677fc37955f95a1eca65854003e4
title: High Availability and Disaster Recovery Across Deployment Models
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/hosting-home/hadr-guide.md
canonical_url: https://docs.mulesoft.com/hosting-home/hadr-guide
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 080fd805eaf6696eca21b0f98be5b804cd227414e75f506ad8a1ceec7bfbb2be
description: MuleSoft Documentation Site
latest: true
---
---
product: Hosting Options
---

# High Availability and Disaster Recovery Across Deployment Models

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

High availability (HA) and disaster recovery (DR) strategies protect your Mule applications from
downtime caused by infrastructure failures, disasters, or maintenance. The right approach depends on
how you deploy Mule runtime engine: managed platforms such as CloudHub 2.0 and CloudHub build in
much of the resilience for you, whereas deployments that you operate—Runtime Fabric, Hybrid
Standalone, and on-premises servers—require you to design clustering, failover, and backups
yourself.

## Understanding Downtime

Downtime strikes at any time, from any direction, and in any form, whether you plan for it or not.
Keeping an organization operational during a technology outage, a facility loss, a personnel loss,
or a third-party service failure prevents irreversible damage to the business. As organizations
shift to e-commerce models that depend on 24/7 uptime, HA and DR increasingly determine their
financial health.

Even small amounts of downtime add up and hurt an organization:

<table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Percentage Uptime</th><th>Percentage Downtime</th><th>Downtime Per Week</th><th>Downtime Per Year</th></tr></thead><tbody><tr><td><div><div><p>99%</p></div></div></td><td><div><div><p>1%</p></div></div></td><td><div><div><p>1.68 hours</p></div></div></td><td><div><div><p>3.65 days</p></div></div></td></tr><tr><td><div><div><p>99.9%</p></div></div></td><td><div><div><p>0.1%</p></div></div></td><td><div><div><p>10.1 minutes</p></div></div></td><td><div><div><p>8.75 hours</p></div></div></td></tr><tr><td><div><div><p>99.99%</p></div></div></td><td><div><div><p>0.01%</p></div></div></td><td><div><div><p>1 minute</p></div></div></td><td><div><div><p>52.5 minutes</p></div></div></td></tr><tr><td><div><div><p>99.999%</p></div></div></td><td><div><div><p>0.001%</p></div></div></td><td><div><div><p>6 seconds</p></div></div></td><td><div><div><p>5.25 minutes</p></div></div></td></tr></tbody></table>

## High Availability Versus Disaster Recovery

- **High availability (HA)** - Measures a system’s ability to remain accessible when a component
  fails. You implement HA by building multiple levels of fault tolerance and load balancing into a
  system.

- **Disaster recovery (DR)** - Restores a system to an acceptable previous state after a natural
  disaster (flooding, tornadoes, earthquakes, fires) or a man-made disaster (power failures, server
  failures, misconfigurations).

Both strategies increase overall availability, but they differ in one key way: HA generally
preserves the service with no loss, whereas DR preserves the data but usually incurs a brief loss of
service while the DR plan runs and the system restores.

## Creating Effective SLAs

A Service Level Agreement (SLA) defines what counts as acceptable service.

High availability means the service stays up, functions correctly, and processes requests and
responses properly. It doesn’t mean the service always runs at full capacity. Systems that you
design for high availability prevent outages and protect against interruptions. The SLA sets
expectations for every stakeholder.

An effective SLA does these things:

- Eliminates single points of failure

- Redirects and handles traffic

- Detects failures

For example, a basic service might define these SLAs:

- Normal operation handles 1,000 transactions per second with 1-second response times.

- Total downtime per year stays at or below 0.5 percent, or 1.83 days.

- Minimum acceptable service handles 100 transactions per second with 1-second response times for up
  to 2 hours a week.

For details, refer to:

- [Defining SLA Tiers](https://docs.mulesoft.com/api-manager/latest/defining-sla-tiers)

- [Rate Limiting and Throttling - SLA-Based Policies](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla)

## Disaster Recovery

**How quickly can your company get back to work after an IT emergency?**

Disaster recovery (DR) restores a system to an acceptable previous state after a natural or man-made
disaster. To drive your DR plan, use measurable business requirements such as Recovery Time
Objective (RTO) and Recovery Point Objective (RPO).

DR centers on your RPO and RTO. RPO is the point you return to after a disaster. For example, if you
back up the system every 24 hours, your RPO is at most the previous 24 hours. RTO is how quickly you
restore to your RPO and resume business, which includes the time to bring backup infrastructure or
applications online when your primary environment fails.

Backups form a major component of a solid disaster recovery program. How much of your backup
environment runs before a disaster determines your standby type, and each type trades cost for
recovery time:

Cold standby

Nothing runs in the backup environment, which keeps your expense to a minimum. Your cold standby is
a plan or script that, after you detect an outage, starts or creates the backup infrastructure,
deploys and starts your Mule applications, and routes traffic to them. Cold standby costs the least
but has the longest RTO.

Warm standby

You fully set up the backup infrastructure and deploy your Mule applications, but no Mule
applications run. After you detect an outage, you start them and route traffic to them. Warm standby
has a shorter RTO than cold standby.

Hot standby (active-passive)

You install, configure, and fully run the backup environment, including your Mule runtimes and
applications, but it doesn’t process requests until you detect an outage. Your RTO covers only the
time to route traffic to the backup environment.

Active-active

Two or more environments run and process traffic at the same time. When one environment fails, the
others keep serving requests with no downtime. Active-active costs the most.

How each deployment model implements these types depends on what you manage. For example, in an
on-premises deployment, a cold standby leaves the operating system stopped, whereas in CloudHub 2.0,
a cold standby is a plan or script to create the private space and deploy your applications in the
backup region. See the HA and DR page for your deployment model.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Term</th><th>Definition</th><th>Example</th></tr></thead><tbody><tr><td><p>Recovery Time Objective (RTO)</p></td><td><p>How quickly do you need to recover this asset?</p></td><td><p>1 min? 15 min? 1 hr? 4 hrs? 1 day?</p></td></tr><tr><td><p>Recovery Point Objective (RPO)</p></td><td><p>How fresh must the recovery be for the asset?</p></td><td><p>Zero data loss, 15 mins out of date?</p></td></tr></tbody></table>

## High Availability and Disaster Recovery by Deployment Model

HA mechanisms and DR responsibilities differ depending on how you deploy Mule. Each deployment model
has a primary HA mechanism, a DR strategy and responsibility split, and a level of cross-region
support. Use these differences to pick the right approach for how you run Mule.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Deployment Model</th><th>Primary HA Mechanism</th><th>DR Strategy and Responsibility</th><th>Cross-Region DR (Runtime Plane)</th><th>When to Use</th></tr></thead><tbody><tr><td><div><div><p>CloudHub 2.0</p></div></div></td><td><div><div><p>MuleSoft runs multiple replicas across availability zones automatically.</p></div></div></td><td><div><div><p>You own the multiregion strategy and provide a bring-your-own (BYO) global load balancer. MuleSoft manages in-region resilience.</p></div></div></td><td><div><div><p>Supported through the Global Deployment entitlement, which MuleSoft provides.</p></div></div></td><td><div><div><p>Fully managed, multi-replica resilience on AWS.</p></div><div><p>See <a href="https://docs.mulesoft.com/cloudhub-2/ch2-ha-dr">CloudHub 2.0 High Availability and Disaster Recovery</a></p></div></div></td></tr><tr><td><div><div><p>CloudHub</p></div></div></td><td><div><div><p>MuleSoft runs multiple workers across availability zones automatically.</p></div></div></td><td><div><div><p>You own cross-region failover. MuleSoft manages in-region resilience.</p></div></div></td><td><div><div><p>Not built in. You design and run cross-region failover.</p></div></div></td><td><div><div><p>Fully managed, multi-worker resilience on AWS.</p></div><div><p>See <a href="https://docs.mulesoft.com/cloudhub/cloudhub-hadr">CloudHub High Availability and Disaster Recovery</a></p></div></div></td></tr><tr><td><div><div><p>Runtime Fabric</p></div></div></td><td><div><div><p>You run a minimum of two replicas across availability zones, with optional Horizontal Pod Autoscaling (HPA).</p></div></div></td><td><div><div><p>You own backup, restore, and failover to a standby cluster.</p></div></div></td><td><div><div><p>Not built in. You fail over to a standby cluster in another region.</p></div></div></td><td><div><div><p>Kubernetes-based clusters that you operate.</p></div><div><p>See <a href="https://docs.mulesoft.com/runtime-fabric/latest/rtf-ha-dr">Runtime Fabric High Availability and Disaster Recovery</a></p></div></div></td></tr><tr><td><div><div><p>Hybrid Standalone</p></div></div></td><td><div><div><p>You cluster runtimes to share memory and fail over automatically.</p></div></div></td><td><div><div><p>You own backup, restore, and DR. MuleSoft provides control-plane availability and best practices.</p></div></div></td><td><div><div><p>You design and run cross-region recovery. Not built in.</p></div></div></td><td><div><div><p>You control the servers, which are managed through Anypoint Platform.</p></div><div><p>See <a href="https://docs.mulesoft.com/hybrid-standalone/hybrid-standalone-hadr">Hybrid Standalone High Availability and Disaster Recovery</a></p></div></div></td></tr><tr><td><div><div><p>On-Premises</p></div></div></td><td><div><div><p>You cluster Mule runtime servers for automatic failover, using active-active, fault-tolerant, or zero-downtime topologies.</p></div></div></td><td><div><div><p>You own the HA architecture, backup, restore, and DR for your servers and data.</p></div></div></td><td><div><div><p>Not built in. You design and run cross-region recovery.</p></div></div></td><td><div><div><p>On-premises clustering that you operate yourself.</p></div><div><p>See <a href="https://docs.mulesoft.com/on-premises/latest/on-premises-hadr">High Availability and Disaster Recovery for On-Premises Mule Runtime Engine</a></p></div></div></td></tr></tbody></table>

MuleSoft keeps the Anypoint Platform control plane resilient. In the managed runtime models,
MuleSoft also keeps in-region infrastructure resilient; in self-managed and on-premises models, you
own the infrastructure. In every model, you own any runtime strategy that spans regions.

> [!NOTE] Cross-region DR in this matrix applies to Mule runtime regions only, not to the Anypoint
> Platform control plane.

## Best Practices

Follow these general design principles for high availability and disaster recovery:

- Keep your integrations stateless.

- Don’t share transactional information between client invocations or scheduled executions.

- When the middleware must retain data because of a system limitation, persist it in an external
  store, such as a database or a messaging queue, rather than in the middleware infrastructure or
  memory.

- As the system scales—especially in the cloud—keep each worker or node’s state and resources
  independent of the other workers, which delivers better performance, scalability, and reliability.

## See Also

- [CloudHub 2.0 High Availability and Disaster Recovery](https://docs.mulesoft.com/cloudhub-2/ch2-ha-dr)

- [CloudHub High Availability and Disaster Recovery](https://docs.mulesoft.com/cloudhub/cloudhub-hadr)

- [Runtime Fabric High Availability and Disaster Recovery](https://docs.mulesoft.com/runtime-fabric/latest/rtf-ha-dr)

- [Hybrid Standalone High Availability and Disaster Recovery](https://docs.mulesoft.com/hybrid-standalone/hybrid-standalone-hadr)

- [High Availability and Disaster Recovery for On-Premises Mule Runtime Engine](https://docs.mulesoft.com/on-premises/latest/on-premises-hadr)