Unit 7.1: Resilience and Business Continuity

Introduction

Resilience is not a product you buy on IONOS; it is a property you compose. The platform gives you availability zones, a health-checking load-balancer tier, an anycast DNS service, point-in-time database recovery, and a backup service, but it does not sell a single "failover" button that orchestrates them. That absence is the central design fact of this unit. Your job as an architect is to translate a business continuity requirement into an arrangement of these primitives, and then to prove it works.

This unit closes by building the steering half of that arrangement in the Data Center Designer: a customer-orchestrated low-TTL Cloud DNS record pair across two zones, plus the validation step that confirms a failover actually moves traffic. Cloud DNS does not health-check on its own, so the health check driving that cutover is one you supply. The build reinforces what you provisioned in Units 3.6 and 3.7 (hybrid connectivity and DNS), now seen through a disaster-recovery lens. FinCorp, our German financial-services firm under GDPR and BSI obligations, anchors every decision: a payments-adjacent service whose continuity targets are dictated by a regulator, not by an engineering preference.

1. RTO, RPO, and the Three Recovery Strategies

Two numbers govern every continuity design, and the business owns both. Recovery Time Objective (RTO) is how long the service may be down before the outage becomes materially damaging. Recovery Point Objective (RPO) is how much data, measured in time, you can afford to lose. An architect who picks these numbers has made a business decision without authority. FinCorp's risk and compliance function sets them; you design to meet them and you state honestly what each target costs.

These two anchors select a recovery strategy. Three strategies span the cost-versus-speed spectrum, and each maps cleanly onto IONOS primitives.

The strategy is a budget decision as much as an availability decision. Active-active doubles the running footprint and demands the tightest data replication; backup-restore is cheap but slow to recover and loses the most data. FinCorp's payments-adjacent service cannot tolerate a multi-hour RTO, so backup-restore is disqualified as the primary strategy for that tier even though it remains the right answer for the firm's reporting and archive workloads. The realistic FinCorp design is pilot-light for the regulated core: an always-on database cluster with a standby node, compute that is pre-templated and scales up on failover, and DNS to redirect.

A critical platform truth threads through all three strategies. The Backup Service (Acronis) covers VMs and Block Storage; it does not back up managed databases, and it does not provide immutable backups. Database continuity is therefore a separate mechanism: point-in-time recovery within the cluster's retention window, plus dump and restore for anything beyond it. Treating the Backup Service as your database DR plan is the most expensive mistake in this space, because you discover the gap only during a real recovery. Snapshots compound the confusion: a Block Storage snapshot is a region-local, non-incremental, VM-level rollback, not a database-consistent backup. Plan the data-continuity plane around PITR and dump/restore for data tiers, and around the Backup Service only for the VMs and volumes it actually covers.

2. Multi-Zone Placement and the Auto-Zone Trap

Resilience starts with where things physically sit. IONOS exposes availability zones as the placement primitive, and the redundancy you get depends entirely on putting paired resources in different zones. The platform will not infer your intent.

Note an asymmetry that catches architects out. Compute availability zones are Zone 1, Zone 2, and Auto. Block Storage availability zones are Zone 1, Zone 2, Zone 3, and Auto. There is no compute Zone 3, so a volume placed in Zone 3 has no co-zoned server to attach in that same zone. For a redundant compute-plus-storage pair, design within the zones both planes share.

The trap sits in the word "Auto." Selecting the Auto availability zone is a single-AZ placement hint that lets IONOS choose a zone for you; it is not a multi-zone or "spread across zones" instruction. If you create two servers intended as an HA pair and leave both on Auto, there is no guarantee they land in different zones, and they may share one. A shared fault domain is exactly what an HA pair is supposed to eliminate. The rule is unambiguous: for any pair that must survive a zone failure, set explicit, different zones. Auto is acceptable for a single, non-paired resource where you have no zone preference; it is wrong for redundancy.

For FinCorp, this means the standby database node sits in an explicitly different zone from the primary, and the pilot-light compute template is provisioned to a named zone distinct from the production tier. Explicit-zone discipline is cheap to apply at design time and impossible to retrofit cleanly after an outage proves the pair was co-located.

3. Health-Based Steering: LB Health Checks, IP Failover, and Customer-Orchestrated DNS

IONOS does not sell a managed failover product. There is no orchestrator that watches a primary, declares it dead, and promotes a secondary across the whole stack, and no managed cross-zone or cross-site failover service. It is important to be precise about which primitive does the health-aware steering, because it is not Cloud DNS.

The platform's automated, health-based steering primitives are two. First, load-balancer health checks: the Managed Application Load Balancer actively health-checks its backend targets over TCP or HTTP, while the Managed Network Load Balancer health-checks its targets over TCP only (HTTP-aware health checks are an ALB-only capability); both support configurable interval and retries and steer traffic away from unhealthy targets within the load balancer's own backend pool. This is real automated failover, but it is region and LAN scoped: it moves traffic among targets inside one pool, not across zones or sites. Second, IP failover groups: a reserved IP shared across VMs on a LAN, for customer-built, application-level IP failover; it too is LAN-local. Multi-zone placement (section 2) is the third leg, but it is placement, not steering.

Cross-zone and cross-site failover sits above all of these, and here there is no native health-aware mechanism. Cloud DNS is not health-aware: it does not monitor endpoint health and does not change a record on its own. Cross-zone failover is therefore customer-orchestrated: your own health check (an external monitor or a signal derived from the load-balancer health state) detects that a zone's endpoint is down and calls the Cloud DNS API to re-point a low-TTL record at the healthy zone. Cloud DNS's contribution is that the record is anycast, SLA-backed, and can carry a very low TTL; the detect-and-re-point automation is yours. This is the failover substitution introduced in Unit 1.3, realised honestly: compose a health-aware primitive (the load balancer within a zone) with a customer-driven low-TTL DNS re-point across zones.

Cloud DNS is well suited to the DNS half of that composition. It runs on an anycast network across 14 points of presence, carries a per-service uptime SLA of 99.995 percent, and supports a TTL as low as 60 seconds. That TTL floor is the dominant RTO lever for any DNS-based failover, because a resolver will keep using a cached answer until the TTL expires. If your record carries a one-hour TTL, your DNS-driven recovery cannot beat one hour no matter how fast you detect the failure. Lower the TTL on records that participate in failover, and accept the modest increase in query volume as the price of a faster cutover.

Two honest constraints shape how you build this. First, DNS steers new connections only. A client that already holds a connection to the failed endpoint is not moved by a DNS change; it must reconnect, at which point it resolves the new address. This is why the application tiers behind a DNS failover must be stateless, with session and shared state externalised to the in-memory tier rather than held on the instance. Second, the health-checking capability lives on the load-balancer plane (or in your own external monitor), never in Cloud DNS: there is no health-check failover record type, because Cloud DNS does not check health at all. In practice you compose the planes: a load balancer determines health within a zone, and a customer-driven API call re-points the DNS record between zone-level endpoints. Because that cross-zone cutover must be driven by your monitoring or orchestration tooling rather than by Cloud DNS, treat the record update as an API-level design, not a point-and-click console wizard; the console path is zone-and-record management, and Cloud DNS never triggers the change itself.

4. Two Planes: Steering and Data Continuity

A durable resilience design keeps two concerns separate, because they fail and recover on different timescales and through different mechanisms.

The traffic-steering plane decides where requests go. It is built from Cloud DNS records, TTL settings, and the load-balancer health checks that determine endpoint health. Its job is to move new connections away from a failed location quickly. Its recovery speed is bounded by the TTL floor and by health-check intervals, not by how fast data can be copied.

The data-continuity plane decides whether the data at the destination is current and correct. It is built from database replication mode and PITR, the Backup Service for VMs and Block Storage, dump/restore for databases, and Object Storage as the archive tail. Its recovery characteristics are the RPO you can actually meet and how long a restore takes.

Conflating the two is a classic failure. Steering traffic to a standby in seconds achieves nothing if the standby's data is hours stale, and a perfectly current replica is useless if no mechanism redirects clients to it. Design each plane to its own target: the steering plane to RTO, the continuity plane to RPO. FinCorp's pilot-light design makes the separation concrete: load-balancer health checks plus a low-TTL Cloud DNS record that an external check re-points form the steering plane that meets the RTO, while the always-on standby database node and its PITR window form the continuity plane that meets the RPO. The two are wired together only at the moment of cutover.

5. Reconciling Dedicated VMware HA with Platform Multi-Zone

FinCorp runs a large VMware estate, and part of it lands on IONOS Private Cloud, the dedicated managed VMware SDDC. Hybrid estates therefore carry two different resilience models at once, and an architect must know where each applies.

Inside a Private Cloud cluster, fault tolerance is a VMware property, not a platform availability-zone property. vSAN (version 8.0, Enterprise edition per the Private Cloud documentation, on vSphere 8.0 Enterprise Plus) protects against host and disk failure through erasure coding and mirroring. The matrix lists three fault-tolerance methods: RAID-1 mirroring (minimum 3 hosts), RAID-5 erasure coding (minimum 4 hosts), and RAID-6 erasure coding (minimum 6 hosts). vSAN requires a minimum of 3 hosts to maintain RAID1 protection (two complete copies of the data), which is the minimum cluster size. vSphere HA restarts VMs on surviving hosts when a host fails. This is intra-cluster resilience: it keeps the SDDC running through hardware faults inside one cluster, and it is the native VMware operational model the estate already understands.

What vSAN and vSphere HA do not provide is cross-site resilience. They protect a workload against host loss within the cluster; they do not make a workload survive the loss of the whole site or cluster. Cross-site continuity for the VMware estate is a replication concern, handled by VMware Cloud Director Availability (VCDA, version 4.7.x), which performs asynchronous replication and failover between sites at roughly 50 EUR per protected VM per month. The honest boundary, stated in Unit 4.4 and carried forward to 7.4, is that the only VMware tooling IONOS lists for this is VCDA, NSX-T L2 VPN for Layer 2 extension, and intra-cluster vMotion. There is no cross-site live-mobility capability and no other VMware add-on to assume.

For a hybrid FinCorp design the two models compose rather than compete. Within the dedicated VMware core, lean on vSAN and vSphere HA for in-cluster fault tolerance. For the platform-native tier (standard compute, managed databases, containers), lean on explicit multi-zone placement, load-balancer health checks within a zone plus customer-orchestrated low-TTL DNS re-pointing across zones, and database PITR. Cross-site continuity for the VMware estate is VCDA replication; cross-zone continuity for the native estate is the DNS-plus-data-plane composition from sections 3 and 4. The reconciliation point is recognising that "HA" means different things on each side, and that neither side's mechanism substitutes for the other's.

DCD Implementation Walkthrough

You will wire a two-zone DNS failover for a FinCorp endpoint and validate that it steers traffic. The architecture goal is the steering plane from section 4: a name that resolves to a primary endpoint in one zone and can be moved to a standby endpoint in a different zone. This composes the Cloud DNS work from Unit 3.7 with the explicit-zone discipline from section 2. Prerequisites: two backend endpoints (for example, two load-balancer or server addresses) deployed in explicitly different availability zones, and the contract-administrator or "Access and manage DNS" privilege required to manage zones and records.

Build goal: Wire a customer-orchestrated low-TTL DNS failover record across a two-zone pair and validate, noting that Cloud DNS does not health-check on its own.

Steps (in the Data Center Designer):

1. Confirm the two endpoints are in different zones. Before touching DNS, verify in the DCD that the primary and standby resources carry explicit, different availability zones (not Auto). If either is on Auto, fix the placement first; a failover record in front of a co-located pair is theatre.
2. Open the DNS Manager and select Create primary DNS zone. Enter the zone name (the FinCorp domain or subdomain that will front the service). The zone is the container for the failover records.
3. After the zone provisions, open it from the Primary Zones list using Details & Records.
4. Create the primary record. Add a record (for example an A record) whose name is the service hostname and whose content is the primary endpoint's address in zone 1. Set the TTL low (at or near the 60-second floor) so that a later cutover propagates quickly; this TTL is your dominant RTO lever.
5. Note the standby endpoint's address in zone 2. You will point the same record name at this address during a failover. Keep the standby endpoint's details recorded so the cutover is a single, unambiguous edit.
6. Define the health source on the load-balancer plane. Because Cloud DNS does not expose a packaged health-check failover record, attach the health check where it lives: on the Managed ALB or NLB target group fronting each endpoint, configure the periodic health check so the balancer only serves healthy targets. This is the detection signal your failover will react to.
7. Wire the automated cutover at the API level. To make the failover automatic rather than operator-triggered, drive the record update from monitoring or orchestration: on a sustained unhealthy signal for zone 1, call the Cloud DNS API to update the record content to the zone-2 address. The console path is zone-and-record management; the automation is the API edit, so keep this sub-step design and API level rather than inventing a console wizard.
8. Validate by simulating failure. Take the primary (zone 1) endpoint out of service or fail its health check, then trigger or perform the record update to the standby address. From an external client, after the TTL elapses, confirm the name now resolves to the zone-2 address and that new connections reach the standby. Confirm an already-open connection does not move until it reconnects, which proves the stateless-tier requirement.

Common mistakes:

• Leaving paired endpoints on the Auto availability zone. Auto is a single-AZ hint, not a spread-across-zones instruction; set explicit, different zones for both members of the pair before building the failover.
• Setting a long TTL on the failover record. A high TTL caps your achievable RTO at the TTL value because resolvers keep the cached answer; lower it to near the 60-second floor on records that participate in failover.
• Assuming Cloud DNS has a managed failover or native health-check record. It does not; detection lives on the load-balancer health checks and the automatic cutover is an API-driven record update. Do not wait for a console button that does not exist.
• Expecting DNS to move live connections. DNS steers new connections only; if the app tier holds session state on the instance, those sessions break. Externalise state to the in-memory tier so the tier is genuinely stateless.
• Treating the Backup Service as the database DR plan. It covers VMs and Block Storage, not managed databases; database continuity is PITR plus dump/restore. Validate the data-continuity plane separately from the steering plane.

A short API-level illustration of the cutover edit (the architectural point is that the DNS half of failover is a customer-driven record-content update, not a managed policy and not something Cloud DNS triggers on its own):

# On a sustained zone-1 unhealthy signal, repoint the record to the zone-2 standby.
ionosctl dns record update --zone-id "$ZONE_ID" --record-id "$RECORD_ID" \
  --content "$STANDBY_ZONE2_ADDRESS"

Summary

Resilience on IONOS is composed, not purchased. You start from business-owned RTO and RPO, pick one of three recovery strategies, place redundant pairs in explicit different zones, and separate the traffic-steering plane (load-balancer health checks within a zone, plus a customer-orchestrated low-TTL Cloud DNS re-point across zones) from the data-continuity plane (database PITR and dump/restore, the Backup Service for VMs and Block Storage, Object Storage archive). There is no managed failover product and no managed cross-zone orchestrator. The platform's health-aware steering is the load balancer (within its pool) and IP failover groups (within a LAN); cross-zone failover is a customer-driven API record update that Cloud DNS serves but does not trigger, because Cloud DNS is not health-aware. For hybrid estates, dedicated VMware vSAN and vSphere HA cover in-cluster fault tolerance while platform multi-zone, the LB-plus-DNS composition, and VCDA cover cross-zone and cross-site continuity respectively.

Key Points:

• RTO and RPO are business decisions; the architect designs to them and states what each costs. The three strategies (backup-restore, pilot-light, active-active) trade cost against recovery speed.
• Availability-zone placement must be explicit for any redundant pair. Auto is a single-AZ hint, and Block Storage has a Zone 3 that compute does not.
• The platform's health-aware steering primitives are load-balancer health checks (within the LB backend pool) and IP failover groups (within a LAN); there is no managed cross-zone orchestrator.
• Cloud DNS (anycast, 14 PoPs, 99.995 percent SLA, 60-second TTL floor) is not health-aware and performs no automated failover. Cross-zone failover is a customer-orchestrated low-TTL record re-point that Cloud DNS serves but does not trigger; the TTL floor is the dominant RTO lever and DNS steers new connections only.
• Keep the steering plane and the data-continuity plane separate; the Backup Service does not cover managed databases, whose continuity is PITR plus dump/restore.
• Inside Private Cloud, vSAN (RAID-1/5/6, minimum 3 hosts for RAID1) and vSphere HA give in-cluster fault tolerance; cross-site continuity is VCDA, and there is no cross-site live mobility.

Important Terminology:

• RTO (Recovery Time Objective): the maximum tolerable duration of an outage; the steering plane is designed to meet it.
• RPO (Recovery Point Objective): the maximum tolerable data loss measured in time; the data-continuity plane is designed to meet it.
• Auto availability zone: a single-AZ placement hint letting IONOS pick a zone, not a multi-zone redundancy instruction.
• TTL floor: the lowest record time-to-live (60 seconds on Cloud DNS); it bounds the best achievable DNS-driven RTO.
• VCDA (VMware Cloud Director Availability): the VMware-native asynchronous replication and failover tool for cross-site continuity of the dedicated VMware estate.

Further Reading

• Unit 3.7: DNS and Failover Routing (the zone and record build this unit reuses)
• Unit 3.6: Hybrid Connectivity (the gateways that link sites during failover)
• Unit 5.7: Data Protection and Lifecycle (the data-continuity plane in depth)
• Unit 4.4: Private Cloud (Dedicated VMware) and Unit 7.4: Migration and Hybrid Cutover (VCDA and the VMware estate)