| Niveau (proposé) | Disponibilité | Modèle | RPO / RTO |
|---|---|---|---|
| Standard | 99,7% | Base de données multizone à haute disponibilité, sauvegardes isolées du réseau | Zone : RPO ≈ 0. Région : restauration à partir du coffre-fort. |
| Live DR | 99,9% | Une deuxième région fonctionne en direct | RPO secondes, RTO ≤ 15 min |
| Live DR Premium | 99,95% | Trafic prioritaire 24h/24 et 7j/7 dans les deux régions | RPO secondes, RTO ≤ 5 min |
Le taux d'indisponibilité est de 95 %. La disponibilité est mesurée mensuellement à l'entrée TRANXACT, hors période de maintenance convenue (4 heures par mois proposées).
Définissez le niveau avant le dimensionnement. La reprise après sinistre en direct (Live DR) correspond à une deuxième région complète et double approximativement le coût de l'infrastructure d'exécution ; indiquez-la sur une ligne distincte, en regard du coût d'indisponibilité qu'elle élimine.
Vivez, ne soyez pas passif
Un système de secours passif reste inactif, son bon fonctionnement est vérifié une fois par an, voire jamais, et il prend le relais par restauration et mise à l'échelle. Un système de reprise après sinistre Live DR exécute un cluster complet et une base de données répliquée en continu, assurant les lectures, la génération de rapports, les requêtes ASK et les publications synthétiques 24 h/24 et 7 j/7. Le basculement est instantané : aucune reconstruction n'est nécessaire, et son bon fonctionnement est vérifié à chaque minute.
| Test | Impact | À quelle fréquence | Catégorie |
|---|---|---|---|
| Vérification continue — écritures synthétiques, alertes de retard, somme de contrôle des registres interrégionaux | Aucun | Chaque minute | Norme (TO_4.10.01) |
| Exercice de basculement planifié : pause écriture, promotion, changement de poste, vérification ; inversion des rôles | L'écriture est interrompue pendant quelques secondes. | Trimestriel | Norme (TO_4.10.03) |
| Exercice de basculement supplémentaire | L'écriture est interrompue pendant quelques secondes. | Sur demande, 2 semaines à l'avance | Supplémentaire (TO_4.10.04) |
| Foreuse isolée — un clone délimité avec intégrations désactivées | Aucun en production | Sur demande, 2 semaines à l'avance | Supplémentaire (TO_4.10.05) |
| test de restauration en salle blanche | Aucun en production | Annuel | Norme (TO_4.9.07) |
| Validation commerciale après un exercice | Effort du client | Chaque exercice | Exclu (TO_4.10.06) |
Sauvegardes
| Base de données de production | Base de données hors production | |
|---|---|---|
| Pris | Instantané quotidien + journaux continus | Aperçu quotidien |
| Récupérer | À tout moment dans les 30 jours | Dernière capture d'écran, il y a 14 jours |
| Copie du coffre-fort | Quotidien, immuable, 90 jours | Hebdomadaire, immuable, 30 jours |
Les documents sont versionnés en continu et copiés quotidiennement dans le coffre-fort pour la production. L'infrastructure en tant que code et la configuration y sont également stockées, ce qui permet de reconstruire l'environnement d'exécution à partir du code plutôt que de le restaurer.
Pourquoi la chambre forte ?
La réplication protège contre les interruptions de service, et non contre la corruption de données. Les ransomwares et les données corrompues sont répliqués en quelques secondes sur le serveur de secours et dans la région de reprise après sinistre. Le coffre-fort est un compte distinct, doté d'identités et de clés séparées, sans aucun accès réseau à la production. La durée de conservation des données est limitée à une seule écriture, même pour les administrateurs, et la suppression nécessite une double approbation. Les restaurations s'effectuent dans un environnement isolé : analyse, réconciliation, puis déploiement. Elles ne sont jamais effectuées directement sur le système de production.
Une période de conservation ne peut être réduite une fois définie. Prolongez-la dès le départ si un audit ou une obligation légale l'exige, et dimensionnez les copies à long terme en fonction de la croissance du grand livre et du volume de documents, et non de la taille actuelle de la base de données.
Calderwood a opté pour Live DR à 99,9 % dans une seconde région Azure de la même juridiction. Un premier exercice de basculement et une restauration en salle blanche sont prévus avant la mise en production, afin de garantir la conformité des systèmes. Ses partenaires bancaires et de paie sont intégrés au plan de basculement pour que leurs terminaux suivent le gestionnaire de trafic.
Essayez-le Un traitement par lots a corrompu 4 000 factures Calderwood à 14h05. Live DR est opérationnel, avec un délai de 2 secondes. Le basculement vers le système de PRA est-il la solution ?
Non. La corruption a été répliquée sur le système de secours et sur le site de reprise après sinistre quelques secondes après sa survenue ; le basculement vous ramène donc aux mêmes données corrompues. La solution consiste à effectuer une restauration à un point précis dans le temps, à 14 h 04 (TO_4.9.05, Standard), ou, si l’historique lui-même est suspect, une restauration complète à partir du coffre-fort (TO_4.9.06), les données restaurées devant être validées par le responsable financier (TO_4.9.11).