Runtime Fabric High Availability and Disaster Recovery

High availability
HA keeps a system accessible when an individual component fails. On Runtime Fabric, it handles routine, localized failures—such as a node or zone going down—with no loss of service.

Disaster recovery
DR restores a system to an acceptable previous state after a broader disaster, such as flooding, power failures, server failures, or misconfigurations. It handles large-scale disruptions and usually incurs a brief loss of service while the DR plan runs.

Recovery Time Objective (RTO)
The maximum downtime a business tolerates. RTO is the time the system takes to recover after a disruption.

Recovery Point Objective (RPO)
The maximum data loss a business accepts after a disaster. RPO drives how often you back up data.

Multiple replicas
Deploy each application with a minimum of two replicas. See Deploying Mule Apps to Runtime Fabric Using Runtime Manager.

Availability zones
Runtime Fabric uses topology spread constraints to distribute Mule application replicas evenly across availability zones. CPU-based Horizontal Pod Autoscaling (HPA) adjusts the number of application replicas in response to load, but it doesn’t control where Kubernetes schedules them; the topology spread constraints keep the added replicas balanced across zones. HPA applies to Mule applications, not to the Runtime Fabric core software. See Configuring Horizontal Pod Autoscaling (HPA) for Runtime Fabric Deployments.

Failover
When a node or zone fails, Kubernetes reschedules replicas onto healthy nodes to maintain availability.

Externalized state
Persist data in object storage across application replicas and restarts, so that no state is lost when a replica reschedules.

Backups
Schedule regular backups with rtfctl, and store them on external storage outside the cluster. MuleSoft recommends hourly backups. The backup covers cluster configuration—services, secrets, ingress, and ConfigMaps—but it doesn’t cover application state, Ops Center data, or control-plane data. Application deployments aren’t part of the backup; Runtime Fabric reconciles them from the Anypoint Platform control plane on restore. See Backing Up and Restoring Runtime Fabric.

Restore targets
Restore to an existing Runtime Fabric cluster, or to a new Kubernetes cluster that uses the same configuration as the backed-up cluster.

Common scenarios
Use backup and restore for major infrastructure upgrades, cluster migrations (from on-premises to cloud, or between cloud providers), and failover to a standby cluster.

Anypoint configuration
Back up your own Anypoint configurations—such as VPN routes, private space firewall rules, connections, and queues—with the Anypoint CLI or Anypoint Platform APIs.

Concurrent instances
Don’t run two concurrent instances of the same Runtime Fabric through backup and restore. Running the original and a restored copy at the same time causes deployment conflicts.

Changes after backup
Application deployment changes are persisted in the Anypoint Platform control plane, not in the backup. When you restore the fabric, it synchronizes deployments from the control plane, so created and deleted applications are reconciled automatically. Changes that aren’t stored in the control plane—such as updated cluster configurations and agent upgrades—aren’t restored; reapply those manually.

Cluster and tooling consistency
Restore to the same cluster that the control plane lists, and use the same rtfctl version that you used to create the backup.

Keep your integrations stateless, and externalize state to an external store.

Run at least two replicas of each application, spread across availability zones.

Schedule regular backups, and store them on external storage.

Test your restore procedures regularly.

High Availability and Disaster Recovery

Backing Up and Restoring Runtime Fabric

Configuring Horizontal Pod Autoscaling (HPA) for Runtime Fabric Deployments

Hardening Runtime Fabric