Un incident majeur peut arriver à n'importe quelle application : panne d'infrastructure, corruption de données, cyberattaque, erreur humaine. Sans plan de reprise d'activité (PRA), la durée et l'impact de l'incident sont imprévisibles. Avec un PRA testé et documenté, la reprise est organisée et les délais sont maîtrisés.
Nticstudio prépare et teste les PRAs pour les applications maintenues dans le cadre de l'offre Run.
RTO et RPO : les deux métriques fondamentales
RTO (Recovery Time Objective) : délai maximum acceptable entre l'incident et la reprise du service. Si votre RTO est de 4 heures, votre PRA doit permettre de remettre l'application en production en moins de 4 heures dans tous les scénarios couverts.
RPO (Recovery Point Objective) : perte de données maximale acceptable en cas d'incident. Un RPO de 1 heure signifie que les backups doivent être réalisés au minimum toutes les heures, car vous acceptez de perdre au maximum 1 heure de données.
Ces deux métriques définissent les exigences techniques du PRA. Un RTO de 1 heure et un RPO de 0 demandent une architecture coûteuse (réplication en temps réel, infrastructure de bascule immédiate). Un RTO de 24 heures et un RPO de 24 heures sont beaucoup plus simples et moins coûteux à atteindre.
Stratégies de backup
Les backups de base de données sont le premier élément d'un PRA. Les options par niveau de protection : snapshot quotidien (RPO = 24h, adapté aux applications sans contrainte forte), backup toutes les heures (RPO = 1h), ou réplication continue (RPO ≈ 0 mais coût élevé).
Les backups doivent être : chiffrés, stockés dans une localisation différente de l'infrastructure principale, et testés régulièrement (un backup non testé peut être inutilisable au moment critique). Le test de restauration est souvent oublié — c'est la partie la plus importante.
Scénarios couverts par le PRA
Un PRA doit couvrir les scénarios réalistes pour votre application : panne du serveur principal (bascule vers un serveur de remplacement), corruption de données (restauration depuis backup), indisponibilité de l'hébergeur (migration vers un autre hébergeur), et compromission de l'application (isolement et restauration depuis une version saine).
Chaque scénario a sa propre procédure documentée avec les étapes, les responsables, et les critères de décision (quand déclenche-t-on le PRA ?).
Tests réguliers du PRA
Un PRA non testé n'est pas un PRA — c'est un document. Les tests de PRA doivent être planifiés au moins annuellement et après chaque modification significative de l'infrastructure. Ils couvrent : le test de restauration des backups, la simulation d'une bascule d'infrastructure, et la mesure des RTO/RPO réels (souvent différents des RTO/RPO théoriques).
Les résultats des tests sont documentés et servent à améliorer le PRA. Un test qui révèle un problème est un succès : il vaut mieux découvrir la faille en test qu'en incident réel.