Reprise Après Sinistre Pour Les Petites Équipes

Dans une petite équipe, la reprise après sinistre tient d’ordinaire en une seule ligne, dans un document que personne n’a jamais ouvert : les sauvegardes sont activées. L’affirmation est exacte et elle ne répond à rien, parce qu’elle ne dit ni quel serait l’âge des données récupérées, ni combien de temps prend une restauration, ni si quiconque en a déjà mené une jusqu’au bout.

C’est dans l’écart entre avoir des sauvegardes et savoir restaurer que la plupart des pannes se transforment en incidents. Une sauvegarde qui existe, qui est à jour et qui n’a jamais été restaurée reste une hypothèse, et le moment où vous la vérifiez est le plus mauvais moment possible pour découvrir qu’elle était fausse.

Deux chiffres transforment une opinion en plan. Combien de données pouvez-vous vous permettre de perdre, et combien de temps pouvez-vous vous permettre d’être à l’arrêt ? Ce sont votre objectif de point de reprise et votre objectif de temps de reprise. Tant que personne du côté métier ne les énonce, toute discussion technique sur la fréquence des sauvegardes reste indécidable, faute d’un critère auquel se confronter.

RPO et RTO en termes simples

Le recovery point objective, ou RPO, correspond à la quantité de données que vous pouvez perdre. Des sauvegardes nocturnes signifient un RPO de 24 heures : une panne à 17 h emporte tout ce qui a été produit depuis la nuit précédente. Si ce n’est pas acceptable, alors le calendrier de sauvegarde est faux, et aucun soin apporté ailleurs ne viendra compenser cela.

Le recovery time objective, ou RTO, correspond au temps pendant lequel vous pouvez rester à l’arrêt. Il englobe tout : détecter, décider, provisionner, restaurer, vérifier et rebasculer le trafic. Les équipes estiment l’étape de restauration et oublient les cinq autres, et c’est exactement pour cela qu’une reprise réelle prend plusieurs fois plus de temps que prévu.

Les deux relèvent de décisions métier et non techniques, et les deux coûtent de l’argent à mesure qu’ils se resserrent. Un RPO de cinq minutes exige une réplication continue. Un RTO d’une heure exige une infrastructure reconstructible automatiquement, parce que personne ne configurera un serveur à la main en moins d’une heure sous pression.

La conversation productive porte sur l’arbitrage. Dites au métier ce que coûte chaque niveau et laissez-le choisir, plutôt que de fixer un chiffre côté ingénierie en espérant qu’il corresponde à des attentes que personne n’a jamais formulées.

Une sauvegarde jamais testée n’est pas une sauvegarde

Les défaillances qui font mal sont rarement l’absence de sauvegardes. Ce sont les sauvegardes qui se révèlent inutilisables au moment précis où l’on en a besoin.

Les causes habituelles, toutes invisibles avant la restauration : le job échoue silencieusement depuis des semaines parce que personne ne surveille les succès aussi bien que les échecs. Le dump a capturé le schéma mais pas les données, ou bien un sous-ensemble de tables que quelqu’un a un jour ajouté à une liste d’exclusion. Le fichier est chiffré avec une clé stockée sur la machine qui vient de mourir. La sauvegarde vit dans le même compte ou la même région que ce qu’elle protège.

Ce dernier point pèse plus lourd qu’auparavant. Une sauvegarde placée dans le même environnement que la production est protégée contre la panne matérielle et contre rien d’autre. Elle ne survit ni à la compromission d’un compte, ni à une suppression accidentelle au niveau du compte, ni à un rançongiciel qui atteint tout ce que les mêmes identifiants peuvent atteindre.

Le seul moyen de savoir qu’une sauvegarde fonctionne est de la restaurer. Planifiez-le, faites-le au minimum une fois par trimestre, et chronométrez l’opération. Ce chronomètre est votre vrai RTO, par opposition à celui qui figure dans le document.

Ce que la reprise après sinistre doit couvrir

Les données sont la partie évidente et rarement la partie lente. Ce qui allonge une reprise, ce sont presque toujours les éléments que personne n’avait inventoriés.

La base de données, dont tout le monde se souvient. Les fichiers téléversés, qui vivent ailleurs et n’ont souvent aucune sauvegarde. La configuration et les secrets, qui n’existent fréquemment que sur la machine en fonctionnement. Le DNS et les certificats, impossibles à recréer rapidement si le compte qui les héberge est précisément ce que vous avez perdu. L’infrastructure elle-même, c’est-à-dire les serveurs, les réseaux et les règles, rapide à reconstruire si elle est définie sous forme de code, et pénible si elle a été créée à coups de clics.

Et la connaissance de la façon dont tout cela s’assemble, qui est de loin le premier déterminant du temps de reprise dans une petite équipe. Un système qu’une seule personne sait reconstruire de mémoire a un temps de reprise égal à la disponibilité de cette personne, ce qui ne constitue pas un plan.

Écrivez l’inventaire avant le plan. La plupart des équipes découvrent au moins un composant sans aucune sauvegarde en dressant cette liste, et le découvrir ainsi coûte considérablement moins cher que l’alternative.

Un plan qui tient sur une page

Les longs documents ne sont pas lus pendant un incident. Visez quelque chose qu’une personne épuisée puisse suivre à trois heures du matin sans avoir à réfléchir.

Il lui faut : qui décide que la reprise a commencé, car hésiter sur la question de savoir si l’on est bien face à un sinistre est une source de retard très courante. Où se trouvent les sauvegardes et comment y accéder, y compris des identifiants qui ne dépendent pas du système tombé. Les étapes de restauration dans l’ordre, assez précises pour être suivies sans improvisation. Comment vérifier que cela a fonctionné, c’est-à-dire un contrôle concret plutôt que le sentiment que le site se charge. Et qui prévenir, en interne comme à l’extérieur.

Conservez-le dans un endroit qui survit à la panne. Un plan de reprise stocké uniquement dans le système qu’il est censé restaurer est une erreur récurrente et parfaitement évitable.

Le même raisonnement vaut pour les accès. Si une seule personne détient les identifiants du compte d’hébergement, votre temps de reprise est borné par le fait qu’elle réponde ou non au téléphone. Notre guide de durcissement d’un serveur Linux couvre les contrôles d’accès dont tout cela dépend.

Proportionné, pas parfait

Une petite équipe n’a pas besoin d’un site de secours actif dans une seconde région. Le coût est réel et la complexité introduit ses propres modes de défaillance.

Ce dont la plupart des petites équipes ont besoin coûte nettement moins cher : des sauvegardes dans un compte séparé, avec des identifiants que la production ne peut pas utiliser, une restauration testée et chronométrée à intervalles réguliers, une infrastructure définie sous forme de code pour être recréée sans archéologie, et un plan d’une page que quelqu’un a réellement lu.

Cet ensemble couvre la panne matérielle, la suppression accidentelle, la compromission de compte et le rançongiciel, c’est-à-dire l’essentiel de ce qui arrive vraiment. Tout ce qui va au-delà est une décision sur la valeur d’une réduction supplémentaire du temps d’arrêt, et cette question relève du métier et non de l’ingénierie.

Mecanik audite et met en place tout cela dans le cadre de son analyse de sécurité serveur . La première question est toujours la même, et elle ne porte pas sur la technologie : combien de temps pouvez-vous rester à l’arrêt, et qui a décidé de ce chiffre ?

Articles en relation: Des SLA de disponibilité qui ont un sens , Sécurité de la chaîne logicielle pour petites équipes , Agents IA en entreprise : coûts et échecs et Développement fintech au Royaume-Uni : FCA, rails et coût .

Questions fréquentes

Que signifient RPO et RTO ? Le recovery point objective désigne la quantité de données que vous pouvez vous permettre de perdre, donc des sauvegardes nocturnes impliquent un RPO de 24 heures. Le recovery time objective désigne la durée pendant laquelle vous pouvez rester à l’arrêt, ce qui inclut détecter, décider, provisionner, restaurer, vérifier et rebasculer le trafic. Les deux sont des décisions métier, et les deux coûtent plus cher à mesure qu’ils se resserrent.

Pourquoi une sauvegarde jamais testée n’est-elle pas une sauvegarde ? Parce que les modes de défaillance n’apparaissent qu’à la restauration. Les jobs échouent en silence pendant des semaines quand personne ne surveille les succès autant que les échecs, les dumps capturent le schéma sans les données ou omettent les tables exclues, les clés de chiffrement dorment sur la machine qui vient de mourir, et les copies vivent dans le même compte que ce qu’elles protègent. Restaurez chaque trimestre et chronométrez.

Où faut-il stocker les sauvegardes ? Dans un compte ou une région séparés, avec des identifiants que la production ne peut pas utiliser. Une sauvegarde dans le même environnement protège contre la panne matérielle et contre rien d’autre : elle ne survit ni à la compromission du compte, ni à une suppression au niveau du compte, ni à un rançongiciel qui atteint tout ce que les mêmes identifiants peuvent atteindre.

Qu’oublie-t-on d’inclure dans la reprise après sinistre ? Les fichiers téléversés stockés à part de la base de données, la configuration et les secrets qui n’existent que sur la machine en fonctionnement, le DNS et les certificats détenus dans un compte qui peut lui-même être perdu, l’infrastructure créée à coups de clics au lieu d’être définie sous forme de code, et la connaissance de l’assemblage quand une seule personne la détient.

Une petite équipe a-t-elle besoin d’un site de secours actif ? En général non. Le coût est réel et la complexité ajoutée apporte ses propres modes de défaillance. Des sauvegardes dans un compte séparé, une restauration testée et chronométrée, une infrastructure définie sous forme de code et un plan d’une page que quelqu’un a lu couvriront la panne matérielle, la suppression accidentelle, la compromission de compte et le rançongiciel, soit l’essentiel de ce qui arrive.