Disaster recovery is one of those projects that stays in the backlog until an auditor, a customer questionnaire or an actual outage forces the issue. For teams running on OVHcloud, the question is usually framed as "we need a second region" — but a second region is an outcome, not a design. What you actually need is a tiered recovery plan with explicit RTO/RPO targets per workload, an architecture that matches those targets, and a budget you can defend.
This article walks through how to design and cost a multi-region DR plan on OVHcloud Public Cloud and Hosted Private Cloud, with the trade-offs that matter in practice.
Start with tiers, not with regions
RTO (how long you can be down) and RPO (how much data you can lose) are business decisions, not engineering ones. The engineering job is to translate them into architecture and tell the business what each tier costs. Before touching Terraform, build an application inventory with four columns: criticality, RTO, RPO, and upstream/downstream dependencies.
A workable default classification looks like this:
| Tier | Example workloads | Target RTO | Target RPO | Pattern |
|---|---|---|---|---|
| 0 — Critical revenue path | Checkout, payment API, auth | Minutes | Near zero | Active/active or hot standby |
| 1 — Core business | Back office, core APIs | 1–4 hours | Minutes | Warm standby |
| 2 — Supporting | Reporting, internal tooling | Within a day | Hours | Pilot light |
| 3 — Non-critical | Dev/test, sandboxes | Best effort | Last backup | Backup & restore |
The single most common mistake is declaring everything Tier 0. The second most common is forgetting that a Tier 0 application inheriting a Tier 2 dependency (an identity provider, a shared message broker, a licence server) is effectively Tier 2.
OVHcloud building blocks for a multi-region design
OVHcloud operates multiple independent regions in Europe and North America — Gravelines, Strasbourg, Roubaix, Frankfurt, London, Warsaw, Beauharnois and others — plus 3-AZ regions in some locations. Three properties shape DR architecture more than anything else:
- vRack gives you a private L2 network that can span multiple datacentres and regions, so a standby site can talk to production without exposing replication traffic to the public internet.
- Public Cloud outbound traffic is included in OVHcloud's model rather than metered per gigabyte. Continuous cross-region replication, which is often the budget killer on hyperscalers, becomes a predictable cost rather than a variable one. Verify the specifics for your services and regions, but the structural difference is real.
- Object Storage is S3-compatible, with storage classes ranging from high-performance to Cold Archive, which lets you tier your backup retention instead of paying standard rates for seven years of data.
What you do not get for free: managed services are region-scoped. A Managed Kubernetes cluster, a Managed Database instance, a Load Balancer or a Private Network lives in one region. Multi-region means you build and operate two of everything, and you own the data replication path between them. Plan for that explicitly.
Four patterns, four price points
| Pattern | What runs in the second region | Realistic RTO | Realistic RPO | Relative cost |
|---|---|---|---|---|
| Backup & restore | Nothing (objects in a second-region bucket) | Hours to a day | Backup interval (1–24h) | Lowest — storage only |
| Pilot light | Data replicated continuously, compute scaled to zero/minimal | 30 min – 2h | Minutes | Low — storage + small control plane |
| Warm standby | Full stack running at reduced capacity | 5–30 min | Seconds to minutes | Significant — roughly 30–50% of prod |
| Active/active | Full capacity, both regions serving traffic | Near zero (failover is traffic shift) | Near zero if the datastore allows it | Highest — 2x prod plus complexity |
Pilot light is the sweet spot for most mid-sized platforms. The data is already there, the infrastructure is described in code, and recovery is "apply the Terraform, scale the node pool, flip DNS". Going from pilot light to warm standby typically multiplies DR compute cost several-fold for a gain measured in tens of minutes — worth it for Tier 0, hard to justify elsewhere.
Data replication is where the RPO is actually decided
Everything else is replaceable; data is not. Three layers to handle:
Object storage
Use a bucket in a second region and keep it in sync. If your OVHcloud Object Storage offer exposes bucket replication, use it. Otherwise a scheduled rclone or aws s3 sync job driven from a small VM or a Kubernetes CronJob is perfectly adequate for RPOs measured in minutes:
rclone sync \
ovh-gra:prod-assets ovh-sbg:prod-assets-dr \
--transfers 16 --checkers 32 \
--s3-no-check-bucket \
--log-level INFO --stats 1mEnable versioning and object lock on the DR bucket. A replication job faithfully replicates ransomware encryption too — immutability is what turns a copy into a backup.
Databases
Managed database services give you automated backups and point-in-time recovery within their region. For cross-region, you have two honest options:
- Backup shipping + PITR: export backups to a second-region bucket and restore on demand. RPO equals your backup/WAL shipping interval; RTO includes restore time, which for a multi-hundred-gigabyte database is measured in hours. Measure it — do not guess.
- Logical or physical replication to an instance you operate in the standby region, over vRack. This gets you an RPO of seconds, at the cost of running and monitoring that replica yourself. For PostgreSQL, logical replication is the usual route when the managed source allows it:
-- on the standby instance
CREATE SUBSCRIPTION dr_sub
CONNECTION 'host=10.10.0.20 dbname=app user=repl password=... sslmode=require'
PUBLICATION app_pub
WITH (copy_data = true, streaming = true);
-- monitor the lag, alert on it
SELECT subname, latest_end_lsn, latest_end_time FROM pg_stat_subscription;Whatever you choose, export replication lag as a metric and alert on it. An unmonitored replica silently drifting for three weeks is worse than no replica, because you will plan your failover around a number that is false.
Kubernetes state
Velero to an OVHcloud Object Storage bucket covers cluster objects and, with CSI snapshots, persistent volumes:
velero install \
--provider aws \
--plugins velero/velero-plugin-for-aws:v1.10.0 \
--bucket velero-dr \
--secret-file ./credentials-ovh \
--backup-location-config \
region=gra,s3ForcePathStyle=true,s3Url=https://s3.gra.io.cloud.ovh.net \
--use-volume-snapshots=falseNote that block storage snapshots are region-local: a snapshot in Gravelines does not help you if Gravelines is unreachable. For cross-region volume recovery you need the data in object storage, either via Velero's filesystem backup (restic/kopia) or an application-level dump.
Making the failover actually happen
The technical switch is usually DNS. Keep TTLs on failover records low — 60 seconds is a reasonable compromise — and know that some resolvers and HTTP clients ignore TTLs anyway. Combine DNS with a health-checked entry point, and make sure your client applications have sane connection timeouts and retry logic; a 300-second socket timeout will hold your RTO hostage regardless of how fast DNS converges.
Two operational rules matter more than the tooling choice:
- Automate the decision inputs, keep the decision human for Tier 1 and below. Automatic failover on a flapping health check causes more outages than it prevents. Make the runbook one command, not one judgement call.
- Write the failback plan at the same time as the failover plan. Returning to the primary region after the standby has accumulated writes is the genuinely hard part, and it is always discovered during the drill rather than during the design.
Infrastructure as code is the DR plan
If your standby region is built by hand, it is not a DR plan, it is a snapshot of someone's afternoon. Parameterise the region and instantiate the same module twice:
module "platform_primary" {
source = "./modules/platform"
service_name = var.project_id
region = "GRA11"
node_count = 6
}
module "platform_dr" {
source = "./modules/platform"
service_name = var.project_id
region = "SBG7"
node_count = 1 # pilot light: scale up on failover
}Keep the DR module continuously applied in CI. Infrastructure code that has not run in four months will fail on an unavailable flavour, a renamed image or a provider upgrade — on the worst possible day.
Budgeting without fantasy numbers
Rather than quoting prices that change, model the drivers. A multi-region DR budget on OVHcloud is roughly:
| Cost driver | Scales with | Lever to reduce it |
|---|---|---|
| Standby compute | Pattern chosen (0% → 100% of prod) | Pilot light; scale node pools on failover |
| Replicated block storage | Volume size, not usage | Thin volumes, move cold data to object storage |
| Backup object storage | Retention × change rate | Lifecycle rules to Cold Archive beyond 30–90 days |
| Cross-region traffic | Write volume | Structurally favourable on OVHcloud (included egress) |
| Licences (VMware, Veeam, Zerto…) | Hosts/VMs protected | Protect only tiered workloads |
| Operational effort | Number of patterns in use | Standardise on two patterns maximum |
Present the budget as a menu: here is Tier 2 for X, here is Tier 0 for 5X, choose per application. Engineering teams that present a single all-or-nothing figure usually get "later".
The compliance angle: DR as evidence
For regulated sectors, a DR plan is a document before it is an architecture. DORA requires financial entities to test their resilience and document the results; NIS2 pushes business continuity obligations onto a much broader set of organisations; HDS and SecNumCloud frameworks come with their own continuity expectations. Sovereignty-driven customers choosing OVHcloud for jurisdictional reasons will also expect the DR site to stay within the same legal perimeter — a detail worth checking when you pick the standby region.
Practically, that means keeping: a dated inventory with tiers and RTO/RPO targets, the architecture diagram per tier, the runbooks, and — most importantly — the drill reports with measured recovery times. Measured, not targeted. An untested DR plan is a hypothesis, and the Strasbourg fire of 2021 was a very public reminder that customers who had treated backups and a second region as optional discovered it at the worst possible moment.
Test it, or do not claim it
Schedule drills quarterly for Tier 0/1, annually for the rest. Each drill produces three numbers: measured RTO, measured RPO, and the number of manual steps. Drive the third one down over time — it is the best predictor of whether the plan survives contact with a real incident at 3 a.m., executed by someone who did not design it.
Start small: one Tier 2 application, a second-region bucket, a restore runbook, one timed drill. The gap between your assumed recovery time and the measured one will tell you more about your real resilience posture than any architecture diagram.