Une PME dispose de trois options proportionnées de reprise après sinistre : des sauvegardes dont la restauration est testée, un secours chaud dans une deuxième région, ou une conception actif-actif sur deux régions. La bonne option dépend de deux chiffres que l’entreprise peut défendre : combien de temps elle peut rester en panne, et combien de données récentes elle peut perdre. Pour la plupart des PME dont les contrats exigent une reprise en minutes, le secours chaud est la réponse proportionnée. Si l’entreprise peut tolérer des heures d’arrêt et que les restaurations sont prouvées, des sauvegardes testées suffisent, et actif-actif se justifie rarement à cette taille.
Cette comparaison s’adresse au chef de la technologie, au directeur des TI ou au fondateur qui vient de recevoir une clause de contrat, un questionnaire de sécurité ou un appel d’offres demandant des objectifs de reprise.
Que signifient RTO et RPO, et qui les fixe ?
L’objectif de temps de reprise (RTO, de l’anglais recovery time objective) est la durée maximale pendant laquelle le service peut rester en panne après un sinistre avant de fonctionner de nouveau. L’objectif de point de reprise (RPO, recovery point objective) est la quantité de données récentes que l’entreprise accepte de perdre, mesurée en temps. Un RPO d’une heure signifie que jusqu’à une heure d’écritures peut avoir disparu après la reprise.
Les deux chiffres sont des décisions d’affaires qui ont un prix technique. L’entreprise les fixe à partir du coût d’une panne, des conditions de ses contrats et de ce que ses clients acceptent. L’ingénierie indique ensuite quelle conception les atteint. L’article de la base de connaissances sur la façon de traduire RTO et RPO pour un PDG non technique propose une manière de mener cette conversation.
La reprise après sinistre, souvent abrégée DR (de l’anglais disaster recovery) et parfois appelée PRA (plan de reprise d’activité), couvre la perte d’un site ou d’une région au complet, ou la perte des données elles-mêmes. La haute disponibilité (HA) est un achat différent. La haute disponibilité maintient un service en marche quand un serveur tombe à l’intérieur d’une région, ce qui est le rôle d’un environnement cluster. Un cluster n’aide pas quand la région est inaccessible ou qu’une base de données est supprimée par erreur.
La reprise après sinistre gérée (DRaaS, disaster recovery as a service) signifie qu’un fournisseur conçoit, opère et teste ce dispositif de reprise pour vous.
Quelles sont les options de reprise après sinistre pour une PME ?
Une PME a trois conceptions réalistes de reprise après sinistre : des sauvegardes dont la restauration est testée, le secours chaud et actif-actif. La reconstruction depuis les sauvegardes s’appelle parfois secours froid ou sauvegarde et restauration.
| Option | Fonctionnement | Temps de reprise | Données à risque | Charge d’exploitation |
|---|---|---|---|---|
| Sauvegardes testées | Les sauvegardes sont copiées hors site. Après un sinistre, l’infrastructure est reconstruite et les données sont restaurées. | La durée d’une reconstruction et d’une restauration complètes. Mesurez-la. | Tout ce qui a été écrit depuis la dernière bonne sauvegarde | Faible : supervision des sauvegardes et tests de restauration planifiés |
| Secours chaud | Une deuxième région tourne à capacité réduite et reçoit les données répliquées en continu. Un runbook la promeut. | Des minutes, dans une conception répétée en exercice | Le délai de réplication au moment de la panne | Moyenne : supervision du délai, secours tenu au rythme des releases, exercices réguliers |
| Actif-actif | Deux régions servent le trafic réel en même temps. | Peut approcher zéro pour la perte d’une région | Dépend de la façon dont les écritures en conflit sont réconciliées | Élevée : deux piles actives, gestion des conflits, attention constante |
| Option | À choisir quand | À éviter quand |
|---|---|---|
| Sauvegardes testées | L’entreprise peut tolérer des heures d’arrêt et les restaurations sont prouvées | Un contrat nomme un RTO plus court que votre restauration mesurée |
| Secours chaud | Un contrat, un client ou le coût d’une panne exige une reprise en minutes | Personne ne sera responsable des exercices, si bien que le secours dérivera de la production |
| Actif-actif | Quelques minutes d’arrêt coûtent très cher et l’application a été conçue pour des écritures multi-régions | Le but est de satisfaire un questionnaire ou de bien paraître sur un diagramme |
Quand des sauvegardes testées suffisent-elles ?
Des sauvegardes dont la restauration est testée suffisent quand deux conditions sont réunies. L’entreprise peut tolérer le temps que prend une reprise complète, et quelqu’un a prouvé que la reprise fonctionne.
Une tâche de sauvegarde qui signale un succès ne dit rien sur la restauration des données ni sur le temps qu’elle prend. Le test est une restauration de bout en bout sur une cible propre, chronométrée et mise par écrit. L’article de la base de connaissances sur la vérification des sauvegardes de bases de données et la preuve que la restauration fonctionne décrit la méthode.
Le temps de restauration mesuré est votre RTO réel, et l’intervalle entre deux sauvegardes est votre RPO réel. Si les deux restent à l’intérieur de ce que vos contrats et vos clients acceptent, n’achetez pas de deuxième région. Consacrez l’effort aux copies hors site, aux tests de restauration planifiés et à un runbook écrit. Demandez à tout fournisseur de sauvegarde où se trouvent les copies et combien de temps elles sont conservées. Demandez-lui aussi si un attaquant ayant accès à la production pourrait les supprimer.
Quand une PME devrait-elle choisir le secours chaud ?
Une PME devrait choisir le secours chaud quand un contrat ou le coût d’une panne exige une reprise en minutes et que des sauvegardes testées n’y arrivent pas. Dans un secours chaud, la deuxième région est déjà provisionnée, la base de données s’y réplique en continu, et un signal documenté déclenche la promotion.
Trois éléments de conception sont à connaître avant d’en acheter un.
- La réplication est habituellement asynchrone. Le secours suit la région principale avec un léger délai supervisé, et des écritures récentes peuvent donc être perdues lors d’une bascule. Une bonne conception met par écrit quelles données restent en phase et lesquelles suivent avec un délai.
- Le secours est dimensionné pour le régime normal après une bascule, pas pour l’heure de pointe. Ce choix garde le coût d’opération raisonnable, et l’entreprise devrait l’accepter en connaissance de cause.
- Un secours jamais testé dérive. Les releases, la configuration et les secrets doivent atteindre les deux régions. Un exercice planifié qui exécute une vraie bascule est la seule preuve que le secours fonctionne encore.
Sur les plateformes qui offrent plusieurs zones de disponibilité dans une même région, un déploiement sur plusieurs zones est habituellement une première étape moins coûteuse. Il ne protège toutefois pas contre la perte d’une région. Consultez l’article de la base de connaissances sur le choix entre Multi-AZ et Multi-Région pour Amazon RDS et Aurora.
Quand actif-actif en vaut-il le coût, et quand ne le vaut-il pas ?
Actif-actif vaut son coût quand quelques minutes d’arrêt ont des conséquences graves et que l’application a été conçue pour accepter des écritures dans deux régions. Peu d’applications de PME répondent à la seconde condition.
Le coût tient autant à l’exploitation qu’à l’infrastructure. Deux régions actives créent un risque de split-brain, où chaque région se croit la principale. Les écritures qui arrivent dans les deux régions doivent être réconciliées. Les écritures qui attendent la confirmation de l’autre région sont ralenties par la distance entre les deux.
N’achetez pas une conception actif-actif pour satisfaire un questionnaire de sécurité. Un évaluateur demande des objectifs de reprise, un modèle de réplication et la date du dernier exercice. Un secours chaud documenté, avec une bascule manuelle répétée en exercice, répond aux trois. L’article sur les preuves d’infrastructure que les acheteurs attendent après un échec à un questionnaire de sécurité énumère les autres éléments que les évaluateurs examinent.
La bascule automatique est-elle sécuritaire ?
Pour la plupart des charges de travail de PME, la bascule automatique entre régions n’est pas le choix le plus sûr. La bascule automatique repose sur des signaux de santé, et les signaux de santé sont parfois faux. Des vérifications instables, des pannes partielles et de brèves coupures réseau peuvent déclencher une bascule qui n’était pas nécessaire. Une mauvaise bascule automatique est une panne en soi.
La solution de rechange courante est une confirmation humaine. La supervision déclenche l’alerte, une personne de garde confirme que la région principale est en panne, et un runbook écrit guide la promotion et le changement dans le système de noms de domaine (DNS). Le DNS est le levier habituel pour diriger le trafic vers le secours. La base de connaissances compare un service de répartition de charge infogéré et un répartiteur multi-région auto-hébergé pour cette couche.
Quels RTO et RPO sont réalistes pour une petite entreprise SaaS ?
Les chiffres réalistes sont ceux qu’un exercice a mesurés. Une entreprise de logiciel-service (SaaS) de 30 personnes ne devrait pas copier le chiffre d’un fournisseur dans un contrat.
Pour des sauvegardes testées, chronométrez une restauration complète et utilisez ce résultat. Pour un secours chaud avec une réplication asynchrone supervisée, une reprise en minutes est une cible de conception défendable. La page DR Multi-Région de Stack Harbor en donne une illustration. On y lit qu’un RTO autour de quinze minutes et un RPO autour de cinq minutes pour les données applicatives sont typiquement défendables, plus ou moins selon le niveau de données et la charge. La même page précise que les chiffres exacts sont cadrés à l’évaluation. Ces chiffres ne sont pas un engagement de Stack Harbor ni d’aucun autre fournisseur, et la réplication asynchrone ne donne pas un RPO de zéro.
Avant qu’un chiffre entre dans un contrat, un responsable désigné dans l’entreprise devrait l’avoir approuvé et un exercice devrait l’avoir mesuré. Le libellé devrait aussi correspondre à ce que dit l’accord du fournisseur lui-même.
Comment choisir la deuxième région ?
Choisissez la deuxième région selon les règles de résidence d’abord, la latence ensuite et l’empreinte cloud existante en troisième lieu.
Pour une charge de travail canadienne soumise à une exigence de résidence, le secours et les sauvegardes doivent habituellement rester au Canada eux aussi. Une organisation québécoise devrait noter qu’un secours hors du Québec place une copie hors de la province, ce que son responsable de la protection des renseignements personnels pourrait devoir évaluer. L’article sur ce qu’il faut exiger d’un hébergeur pour la résidence des données au Canada couvre les clauses à demander.
Quels facteurs déterminent le coût de la reprise après sinistre ?
Le coût de la reprise après sinistre vient de cinq facteurs, et la capacité de calcul dans la deuxième région n’est que l’un d’eux.
- La capacité de secours. Avec un secours chaud, l’entreprise paie des serveurs et des bases de données avant d’en avoir besoin.
- La réplication et le transfert de données. Bon nombre de plateformes cloud facturent les données transférées entre régions, et les données répliquées sont stockées deux fois.
- L’outillage en double. La supervision, la journalisation, la gestion des secrets et les pipelines de déploiement doivent atteindre les deux régions.
- Les modifications à l’application. Les sessions, les fichiers téléversés et les tâches planifiées qui présument une seule région doivent être retravaillés. Ce poste est facile à sous-estimer.
- Les exercices et le suivi d’exploitation. Chaque exercice prend du temps d’ingénierie, le runbook doit être révisé ensuite, et quelqu’un doit surveiller le délai de réplication entre les exercices.
Dans un scénario type, une mise en place de deux régions pour un SaaS canadien proche du milieu de la santé, le coût d’infrastructure a augmenté de 38 % avec l’exploitation d’une deuxième région. Ce mandat faisait tourner deux régions indépendantes pour la résidence des données, ce qui est plus lourd qu’un secours chaud. Le chiffre n’est donc pas un résultat typique. Le même scénario type rapporte que démêler tout ce qui présumait une seule région a pris plus de temps que bâtir la deuxième région.
Pour estimer votre propre coût, dressez la liste de chaque dépôt de données, de chaque système qui présume une seule région et des heures qu’un exercice prendrait. L’article sur la façon dont l’hébergement cloud infogéré est tarifé explique comment de tels facteurs deviennent un devis.
Qui devrait opérer le dispositif de reprise après sinistre ?
Une équipe interne est le bon opérateur quand l’entreprise a déjà des ingénieurs cloud de garde et fait des exercices selon un calendrier.
Un fournisseur de reprise après sinistre gérée (DRaaS) ou d’infrastructure infogérée convient quand personne à l’interne n’est responsable du runbook entre deux incidents. Demandez le rapport du dernier exercice, et consultez les critères à vérifier chez un fournisseur d’hébergement infogéré.
Un fournisseur infogéré est le mauvais choix quand des sauvegardes testées respectent déjà votre RTO contractuel. C’est aussi le mauvais choix quand le fournisseur ne peut pas opérer sur le cloud que votre charge de travail utilise déjà. Il en va de même quand vos clients exigent un rapport de certification que le fournisseur ne détient pas.
Une liste de vérification de reprise après sinistre à apporter à un appel avec un fournisseur
- Quels RTO et RPO la conception vise-t-elle, et qui les approuve de notre côté ?
- La réplication est-elle synchrone ou asynchrone, et quelles données suivent avec un délai ?
- Le secours est-il dimensionné pour le régime normal ou pour la charge de pointe ?
- Qui décide de basculer, et la bascule est-elle manuelle ou automatique ?
- À quand remonte le dernier vrai exercice de bascule, et pouvons-nous voir le rapport ?
- Comment les releases et les secrets atteignent-ils le secours ?
- Où se trouvent physiquement le secours et les sauvegardes ?
- Comment revenons-nous à la région principale, et que dit l’accord au sujet de la reprise ?
Un fournisseur qui répond aux huit questions par écrit vous a donné une posture de reprise que vous pouvez défendre.
Où se situe Stack Harbor
Stack Harbor est un fournisseur d’exploitation infonuagique gérée (MSP) de propriété canadienne pour les environnements de production, dont le siège est à Montréal. Elle sert des PME et des agences qui opèrent des systèmes de production sans avoir leur propre équipe d’opérations 24/7.
La solution DR Multi-Région de Stack Harbor retient le secours chaud comme conception par défaut. Son périmètre publié comprend une réplication asynchrone de la base de données, avec un délai supervisé par rapport au RPO, et un modèle écrit de cohérence des données. Il comprend aussi une bascule DNS avec un runbook de promotion manuelle soumis à une confirmation humaine. Un exercice est au calendrier chaque trimestre, et la page le décrit comme une vraie bascule de bout en bout, pas un exercice sur table. Les chiffres de RTO et de RPO sont cadrés à l’évaluation et approuvés par un responsable désigné chez le client. L’évaluation produit un sommaire de posture de reprise d’une page à remettre à un acheteur ou à un auditeur, et c’est l’évaluateur qui prend la décision.
La page de la solution décrit la conception comme indépendante de l’hôte : AWS, Virtuozzo ou des serveurs cPanel peuvent l’accueillir, et une charge de travail sur AWS peut donc rester sur AWS. L’infrastructure canadienne de Stack Harbor elle-même tourne dans deux centres de données à Montréal. Sur Cloud Compute, la bascule régionale est une opération infogérée, pas automatique.
L’accord de niveau de service (SLA) prévoit un engagement de 99,9 % de disponibilité mensuelle pour le réseau et l’infrastructure en tant que service (IaaS), avec un crédit de service comme recours. Il ne contient aucun engagement de RTO ou de RPO. La page Confiance et sécurité décrit les pratiques de sauvegarde, dont des tests de restauration vérifiés et une répétition de restauration trimestrielle, lorsque le périmètre les prévoit. Elle indique aussi que Stack Harbor ne détient aucun rapport SOC 2 en son nom. Stack Harbor ne publie pas de prix. Un devis fixe suit une évaluation, comme le décrit la page sur la façon dont Stack Harbor cadre les mandats.
Si des sauvegardes testées respectent votre RTO contractuel, gardez-les et continuez de les tester. Sinon, demandez une évaluation de reprise après sinistre et apportez la clause qui nomme vos objectifs de reprise.
