Le PRA fait partie de ces chantiers qui restent dans le backlog jusqu'à ce qu'un auditeur, un questionnaire client ou un incident réel force la décision. Pour les équipes qui opèrent sur OVHcloud, la question est souvent posée ainsi : « il nous faut une seconde région ». Mais une seconde région est un résultat, pas une conception. Ce dont vous avez réellement besoin, c'est d'un plan de reprise hiérarchisé, avec des objectifs RTO/RPO explicites par application, une architecture qui correspond à ces objectifs, et un budget défendable devant la direction.
Cet article détaille la conception et le chiffrage d'un PRA multi-région sur OVHcloud Public Cloud et Hosted Private Cloud, avec les arbitrages qui comptent vraiment.
Commencer par les paliers, pas par les régions
Le RTO (durée d'indisponibilité acceptable) et le RPO (volume de données que l'on accepte de perdre) sont des décisions métier, pas techniques. Le travail de l'ingénierie consiste à les traduire en architecture et à chiffrer chaque palier. Avant d'ouvrir Terraform, construisez un inventaire applicatif avec quatre colonnes : criticité, RTO, RPO, dépendances amont/aval.
| Palier | Exemples | RTO cible | RPO cible | Pattern |
|---|---|---|---|---|
| 0 — Chaîne de revenu | Tunnel d'achat, API de paiement, SSO | Minutes | Quasi nul | Actif/actif ou hot standby |
| 1 — Cœur métier | Back-office, API métier | 1 à 4 h | Minutes | Warm standby |
| 2 — Support | Reporting, outillage interne | Sous 24 h | Heures | Pilot light |
| 3 — Non critique | Dev/test, bacs à sable | Best effort | Dernière sauvegarde | Backup & restore |
L'erreur la plus fréquente consiste à classer toutes les applications en palier 0. La deuxième : oublier qu'une application de palier 0 qui dépend d'un composant de palier 2 (fournisseur d'identité, bus de messages mutualisé, serveur de licences) est de fait en palier 2.
Les briques OVHcloud pour un design multi-région
OVHcloud exploite plusieurs régions indépendantes en Europe et en Amérique du Nord — Gravelines, Strasbourg, Roubaix, Francfort, Londres, Varsovie, Beauharnois, entre autres — ainsi que des régions 3-AZ sur certaines localisations. Trois propriétés structurent le PRA plus que tout le reste :
- Le vRack fournit un réseau privé de niveau 2 pouvant s'étendre sur plusieurs datacentres et régions : le site de secours dialogue avec la production sans exposer le trafic de réplication sur Internet.
- Le trafic sortant du Public Cloud est inclus dans le modèle OVHcloud plutôt que facturé au gigaoctet. La réplication continue inter-région, qui plombe souvent le budget PRA chez les hyperscalers, devient un coût prévisible plutôt qu'une variable. Vérifiez les conditions exactes pour vos services et régions, mais la différence structurelle est réelle.
- L'Object Storage est compatible S3, avec des classes allant du haute performance au Cold Archive : la rétention longue se paie au tarif de l'archive, pas à celui du stockage chaud.
Ce que vous n'obtenez pas gratuitement : les services managés sont régionaux. Un cluster Managed Kubernetes, une base managée, un Load Balancer ou un réseau privé vivent dans une région. Le multi-région, c'est construire et opérer deux fois chaque brique — et assumer vous-même le chemin de réplication des données. Prévoyez-le explicitement dans la charge.
Quatre patterns, quatre niveaux de prix
| Pattern | Ce qui tourne en région de secours | RTO réaliste | RPO réaliste | Coût relatif |
|---|---|---|---|---|
| Backup & restore | Rien (objets dans un bucket de la 2e région) | Quelques heures à 1 jour | Intervalle de sauvegarde (1–24 h) | Le plus bas — stockage seul |
| Pilot light | Données répliquées en continu, compute réduit au minimum | 30 min – 2 h | Minutes | Faible — stockage + petit socle |
| Warm standby | Stack complète à capacité réduite | 5 – 30 min | Secondes à minutes | Significatif — ~30 à 50 % de la prod |
| Actif/actif | Capacité pleine, les deux régions servent du trafic | Quasi nul (bascule de trafic) | Quasi nul si le datastore le permet | Le plus élevé — 2× la prod + complexité |
Le pilot light est le point d'équilibre pour la majorité des plateformes de taille moyenne : les données sont déjà là, l'infrastructure est décrite en code, et la reprise se résume à « appliquer le Terraform, scaler le node pool, basculer le DNS ». Passer du pilot light au warm standby multiplie en général le coût compute du PRA pour un gain qui se compte en dizaines de minutes : justifié en palier 0, difficile à défendre ailleurs.
La réplication des données décide réellement du RPO
Tout le reste est reconstructible ; les données, non. Trois couches à traiter.
Stockage objet
Utilisez un bucket dans une seconde région et maintenez-le synchronisé. Si votre offre Object Storage OVHcloud expose la réplication de bucket, utilisez-la. Sinon, un job rclone ou aws s3 sync planifié depuis une petite VM ou un CronJob Kubernetes suffit largement pour un RPO de quelques minutes :
rclone sync \
ovh-gra:prod-assets ovh-sbg:prod-assets-dr \
--transfers 16 --checkers 32 \
--s3-no-check-bucket \
--log-level INFO --stats 1mActivez le versioning et l'object lock sur le bucket de secours. Un job de réplication réplique aussi fidèlement un chiffrement par rançongiciel : c'est l'immuabilité qui transforme une copie en sauvegarde.
Bases de données
Les services de bases managées fournissent sauvegardes automatiques et PITR dans leur région. Pour l'inter-région, deux options honnêtes :
- Export des sauvegardes + PITR : envoyer les sauvegardes vers un bucket d'une autre région et restaurer à la demande. Le RPO est égal à l'intervalle d'expédition ; le RTO inclut le temps de restauration, qui pour une base de plusieurs centaines de Go se compte en heures. Mesurez-le, ne l'estimez pas.
- Réplication logique ou physique vers une instance que vous opérez dans la région de secours, via vRack. RPO de quelques secondes, au prix d'exploiter et de superviser ce réplica vous-même. En PostgreSQL, la réplication logique est la voie habituelle quand la source managée l'autorise :
-- sur l'instance de secours
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);
-- superviser le retard, et alerter dessus
SELECT subname, latest_end_lsn, latest_end_time FROM pg_stat_subscription;Quel que soit le choix, exportez le lag de réplication en métrique et posez une alerte. Un réplica non supervisé qui dérive silencieusement depuis trois semaines est pire que pas de réplica du tout : vous planifierez votre bascule sur un chiffre faux.
État Kubernetes
Velero vers un bucket Object Storage OVHcloud couvre les objets du cluster et, avec les snapshots CSI, les volumes persistants :
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=falseAttention : les snapshots de block storage sont locaux à la région. Un snapshot à Gravelines ne vous sauve pas si Gravelines est injoignable. Pour une reprise de volumes inter-région, la donnée doit être dans le stockage objet — via la sauvegarde filesystem de Velero (restic/kopia) ou via un dump applicatif.
Réussir la bascule
Techniquement, la bascule passe généralement par le DNS. Gardez des TTL courts sur les enregistrements concernés — 60 secondes est un compromis raisonnable — en sachant que certains résolveurs et clients HTTP ignorent les TTL. Combinez DNS et point d'entrée avec health check, et vérifiez que vos clients applicatifs ont des timeouts de connexion et une logique de retry saines : un socket timeout de 300 secondes prendra votre RTO en otage quelle que soit la vitesse de convergence DNS.
Deux règles opérationnelles pèsent plus que le choix d'outillage :
- Automatiser les signaux, garder la décision humaine jusqu'au palier 1 inclus. Une bascule automatique sur un health check instable provoque plus de pannes qu'elle n'en évite. Faites en sorte que le runbook soit une commande, pas un jugement.
- Écrire le plan de retour arrière en même temps que le plan de bascule. Revenir sur la région principale après que le secours a accumulé des écritures est la vraie difficulté — et elle se découvre toujours pendant l'exercice, jamais pendant la conception.
L'Infrastructure as Code est le PRA
Si votre région de secours est construite à la main, ce n'est pas un PRA, c'est la photographie d'un après-midi de travail. Paramétrez la région et instanciez deux fois le même module :
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 : scaler à la bascule
}Maintenez le module DR appliqué en continu depuis la CI. Un code d'infrastructure qui n'a pas tourné depuis quatre mois échouera sur un flavor indisponible, une image renommée ou une montée de version du provider — le pire jour possible.
Budgéter sans chiffres fantaisistes
Plutôt que des tarifs qui évoluent, modélisez les inducteurs de coût. Un budget PRA multi-région sur OVHcloud se décompose ainsi :
| Inducteur | Varie avec | Levier de réduction |
|---|---|---|
| Compute de secours | Pattern retenu (0 % → 100 % de la prod) | Pilot light, scaling des node pools à la bascule |
| Block storage répliqué | Taille des volumes, pas l'usage | Volumes dimensionnés juste, données froides en objet |
| Stockage objet de sauvegarde | Rétention × taux de changement | Règles de cycle de vie vers Cold Archive au-delà de 30–90 j |
| Trafic inter-région | Volume d'écritures | Structurellement favorable chez OVHcloud (sortie incluse) |
| Licences (VMware, Veeam, Zerto…) | Hôtes / VM protégés | Ne protéger que les workloads classifiés |
| Charge d'exploitation | Nombre de patterns en production | Standardiser sur deux patterns maximum |
Présentez le budget sous forme de menu : voici le palier 2 à X, voici le palier 0 à 5X, arbitrez application par application. Les équipes qui présentent un chiffre unique « tout ou rien » obtiennent en général un « on verra plus tard ».
Le volet conformité : le PRA comme preuve
Dans les secteurs régulés, un PRA est un document avant d'être une architecture. DORA impose aux entités financières de tester leur résilience et d'en documenter les résultats ; NIS2 étend les obligations de continuité à un périmètre d'organisations beaucoup plus large ; les référentiels HDS et SecNumCloud portent leurs propres exigences de continuité. Les clients qui choisissent OVHcloud pour des motifs de souveraineté attendront en outre que le site de secours reste dans le même périmètre juridique — un point à vérifier au moment de choisir la région de repli.
Concrètement, il faut conserver : un inventaire daté avec paliers et cibles RTO/RPO, le schéma d'architecture par palier, les runbooks, et surtout les comptes rendus d'exercices avec les temps de reprise mesurés. Mesurés, pas visés. Un PRA non testé n'est qu'une hypothèse — et l'incendie de Strasbourg en 2021 a rappelé publiquement que les clients ayant traité la sauvegarde et la seconde région comme optionnelles l'ont découvert au pire moment.
Testez, ou ne le revendiquez pas
Planifiez des exercices trimestriels pour les paliers 0 et 1, annuels pour le reste. Chaque exercice produit trois chiffres : RTO mesuré, RPO mesuré, nombre d'étapes manuelles. Faites décroître le troisième dans le temps : c'est le meilleur prédicteur de la survie du plan face à un incident réel, à 3 heures du matin, exécuté par quelqu'un qui ne l'a pas conçu.
Commencez petit : une application de palier 2, un bucket dans une seconde région, un runbook de restauration, un exercice chronométré. L'écart entre le temps de reprise supposé et le temps mesuré vous en apprendra plus sur votre résilience réelle que n'importe quel schéma d'architecture.