Leçon15 min

Haute disponibilité ≠ continuité ≠ reprise

Trois dispositifs, trois menaces

DispositifMenace traitéeMenace non traitée
Haute disponibilité (cluster, redondance locale)Panne d'un composantDestruction du site, corruption des données
Continuité (site distant, réplication)Perte d'un siteCorruption logique répliquée, compromission d'identité
Reprise (sauvegarde, restauration)Corruption, destruction, rançongicielRien — mais elle est lente

La colonne de droite est celle qui compte. Chaque dispositif a un angle mort, et l'angle mort du précédent est la raison d'être du suivant.

Le scénario qui traverse les trois

Prenons une corruption logique : une écriture applicative erronée, propagée dans la base de production à 14 h 00.

  • La haute disponibilité ne voit rien : les nœuds sont sains, le service répond.
  • La réplication vers le site distant transporte fidèlement la corruption. À 14 h 00 et une seconde, les deux sites sont corrompus.
  • Seule la sauvegarde permet de revenir à 13 h 00. Elle est lente, elle fait perdre une heure de données, et c'est la seule option.

C'est pourquoi une architecture qui investit tout dans la disponibilité et néglige la sauvegarde est structurellement fragile : elle est excellente contre la panne matérielle, qui est devenue rare, et sans défense contre la corruption et le rançongiciel, qui sont devenus fréquents.

Dériver les objectifs techniques

Le RTO technique n'est jamais égal au RTO métier : il doit lui laisser de la place.

RTO métier = détection + décision + RTO technique + vérification + reprise des opérations

Un RTO métier de 4 heures, avec 30 minutes de détection, 45 minutes de décision, 45 minutes de vérification et 30 minutes de reprise des opérations, laisse 1 h 30 de RTO technique.

Beaucoup d'architectures sont dimensionnées sur 4 heures alors qu'elles disposent en réalité d'une heure et demie. L'écart n'apparaît qu'au premier exercice mesuré.

Le RPO applicatif n'est pas le RPO du stockage

Un stockage répliqué toutes les quinze minutes ne garantit pas un RPO de quinze minutes pour l'application. Trois facteurs s'y ajoutent :

  • Les transactions en vol au moment de la coupure, qui peuvent laisser des états incohérents ;
  • Les flux entre applications : l'application A est à jour, l'application B a quinze minutes de retard, les référentiels divergent ;
  • Les fichiers déposés par des tiers, qui ne suivent pas le cycle de réplication de la base.

Le RPO réel se mesure à la cohérence fonctionnelle rétablie, pas à l'horodatage du dernier bloc répliqué.

À retenir

  • La haute disponibilité traite la panne, pas la destruction ni la corruption
  • La corruption logique se réplique à la vitesse de la réplication
  • Un cluster local et une sauvegarde isolée répondent à deux menaces distinctes