"Que se passe-t-il quand votre datacenter brûle ?" était jusqu'à l'incendie de Strasbourg d'OVH en mars 2021 une question largement théorique. Maintenant c'est un item de checklist procurement. Avec trois datacenters français — Paris, Marseille, Lyon — FranceVPS vous laisse construire une vraie redondance géographique sans quitter la juridiction française.
Ce que "désastre" signifie réellement
"Désastre" en planification DR n'est pas juste l'incendie. Cela inclut :
- Coupure d'alimentation site-wide
- Isolation réseau (coupures fibre, BGP)
- Pannes corrélées matériel
- Erreur humaine (rm -rf production)
- Incidents sécurité (ransomware)
- Destruction physique
Les quatre paliers de topologie
Palier 1 : Datacenter unique avec backups
Production dans un datacenter (Paris FR-PAR-1). Backups vers FR-PAR-2 et un tiers (Hetzner, Backblaze). Recovery exige restauration sur VPS frais.
Survit : panne hardware, suppression accidentelle, ransomware (si backups immutables)
Ne survit pas : perte immédiate de disponibilité durant un incident Paris-wide
Coût : 1× production + storage backup. Adapté aux workloads non-critiques.
Palier 2 : Actif-passif sur deux villes
Production à Paris, warm standby à Marseille. Base répliquée en continu, serveurs apps prêts. Failover via DNS et promotion DB. RTO : 5-15 minutes.
Coût : ~1,6× single-site.
Palier 3 : Actif-actif sur deux villes
Les deux sites servent du trafic en continu, load-balancés via DNS. Exige que l'application soit stateless ou que l'état soit répliqué cross-site. RTO effectivement zéro.
Coût : 2× production + investissement engineering important.
Palier 4 : Actif-actif sur trois villes
Le mode DR complet : Paris, Marseille, Lyon tous tournants avec décisions par quorum. Survit à toute perte de site unique sans downtime. Utilisé par services financiers, telcos.
Coût : 3× production. Justifiable pour infrastructure critique.
Ce qui marche sur FranceVPS
- Paris ↔ Marseille : 750 km, grilles séparées, ~8ms latence
- Paris ↔ Lyon : 465 km, ~4ms latence — supporte la réplication synchrone
- Quorum trois sites : Paris + Lyon + Marseille = vraie redondance triangulaire
Stratégies de réplication DB
Réplication streaming asynchrone PostgreSQL : simple, mais perte de secondes-à-minutes lors du failover.
Réplication synchrone : commit bloque jusqu'à confirmation des deux sites. Zéro perte mais limité par la latence inter-site.
Réplication logique / multi-master : plusieurs sites acceptent les écritures. Conflit de résolution = votre problème.
Considérations applicatives
Au-delà de la DB :
- Serveurs apps stateless (ou état session dans cache partagé Redis)
- Configuration externe (Consul, Vault)
- Health checks distinguant "ce serveur est cassé" de "ce datacenter est cassé"
- DNS avec TTLs bas (60-120s)
- Réplication object storage
Tester le DR
Un plan DR non testé est du théâtre. Tests :
- Trimestriels minimum
- Réels, pas sur papier — failover réellement, tournez sur le standby une heure, fail back
- Documentés, runbook mis à jour
La première fois où vous failover en production ne devrait pas être pendant un vrai incident.
L'économie
Pour la plupart des SaaS, le Palier 2 (actif-passif sur deux villes) est la bonne réponse. ~1,6× single-site, RTO significatif, atteignable avec outillage standard. L'erreur la plus commune : payer pour la capacité Palier 2 ou 3 mais ne jamais tester le failover.