Il y a une phrase que j’ai mis des années à comprendre, et c’est en exploitant des nœuds de blockchain que je suis tombé dessus, presque par accident.
On ne restaure pas depuis une sauvegarde.
Pas « on ne devrait pas ». On ne peut pas, parce que la notion n’a aucun sens dans ce contexte. Je l’ai raconté brièvement dans mon billet sur Lambs on Acid et j’aimerais y consacrer le temps qu’il faut, parce que ce cas extrême dit quelque chose de vrai sur des systèmes qui n’ont rien à voir avec le web3.
Le renversement
En informatique ordinaire, le modèle mental est simple et on ne le questionne jamais : vos données sont la vérité, elles sont sur vos disques, et votre travail est de les protéger. Sauvegarde, réplication, rétention, restauration testée. Tout l’outillage découle de là.
Sur un nœud de blockchain, ce modèle s’effondre. La vérité est sur le réseau. Ce que j’ai sur disque n’en est qu’une projection locale, obtenue en rejouant des blocs qui existent ailleurs, chez des centaines d’autres gens. Si je perds mon disque, je n’ai rien perdu d’unique. Le réseau ne s’en aperçoit même pas.
Ce que j’ai perdu, c’est le temps qu’il faudra pour refabriquer cette projection. Cinq ans d’histoire à revalider, plusieurs jours de calcul.
Alors on arrête de protéger la donnée, et on se met à protéger le délai pour la reconstituer. Ce n’est pas une nuance de vocabulaire, ça change tout l’outillage : au lieu de sauvegardes, on garde des instantanés récents ; au lieu d’une politique de rétention, on a une fraîcheur ; au lieu d’un plan de restauration, on a un temps de reconstruction qu’on mesure.
Et là, on regarde ses propres systèmes
Le cas de la blockchain est extrême. C’est ce qui le rend utile : il pousse à bout une distinction qui existe partout ailleurs, mais qui est trop discrète pour qu’on la remarque.
Séparez ce que vous exploitez en deux tas.
Dans le premier, ce qui est originel : ça n’existe qu’ici, personne ne peut le refabriquer, et si ça disparaît c’est perdu. Les commandes de vos clients. Les fichiers qu’ils ont déposés. Les écritures comptables. Le contenu qu’on a écrit.
Dans le second, ce qui est dérivé : ça a été calculé à partir d’autre chose, et cette autre chose existe toujours. Un index de recherche. Un cache. Une image de conteneur. Un entrepôt analytique alimenté depuis les bases sources. Un modèle réentraîné chaque nuit. Une table agrégée. Un cluster Kubernetes, qui ne contient rien que ses manifestes ne décrivent.
Maintenant regardez ce que vous sauvegardez. Dans la plupart des systèmes que j’ai vus, on sauvegarde les deux tas de la même façon, avec la même politique, le même coût et la même diligence. C’est une erreur des deux côtés à la fois.
Les deux erreurs symétriques
Sur le dérivé, la sauvegarde est du gaspillage — et souvent plus lente que le recalcul. Sauvegarder un index de recherche de deux téraoctets, le stocker, payer pour ça tous les mois, tester la restauration… alors que le réindexer complet prend quatre heures depuis la base source. On dépense de l’argent et de l’attention pour un chemin plus long que celui qu’on n’a pas voulu mesurer.
Il y a pire. Une sauvegarde de dérivé restaure un état incohérent avec sa source. Si vous restaurez l’index d’hier et la base de ce matin, vous obtenez un système qui répond, qui a l’air normal, et qui ment. Un recalcul, lui, est cohérent par construction. C’est ce qui rend la sauvegarde du dérivé non seulement inutile, mais activement trompeuse.
Sur l’originel, l’inverse. Là, il n’y a pas de recalcul possible et la sauvegarde est le seul filet. C’est aussi là qu’il faut mettre l’argent, la rétention longue, la copie hors site, le chiffrement, et surtout la restauration testée pour de bon. Et c’est presque toujours un périmètre beaucoup plus petit qu’on ne croit : une base de données, un espace de fichiers. Le protéger sérieusement coûte moins cher que de tout protéger tièdement.
Ce que vous devriez pouvoir dire de chaque composant
Pas un tableau de plus. Une phrase, pour chaque brique de votre plateforme :
« Si ceci disparaît maintenant, ça revient comment, et en combien de temps ? »
Il n’y a que trois réponses acceptables, et aucune n’est « je crois qu’on a une sauvegarde ».
« Ça se recalcule, en N minutes, et voici la commande. » Alors ne le sauvegardez pas. Surveillez plutôt que la commande fonctionne encore, parce que c’est elle votre plan de reprise, et une commande qu’on ne lance jamais pourrit exactement comme une sauvegarde qu’on ne restaure jamais.
« Ça se restaure, en N heures, et on l’a fait le mois dernier. » Alors c’est de l’originel, et c’est bien. Gardez la date de la dernière restauration réussie ; elle vaut plus que la taille du dépôt de sauvegarde.
« On ne sait pas. » C’est la seule réponse qui demande du travail, et c’est la plus fréquente.
Le chiffre que personne n’a
On connaît tous le RPO et le RTO, on les a écrits dans un document, et on les cite en réunion. Mais dans la pratique, l’énorme majorité des équipes peut vous dire à quelle fréquence elle sauvegarde, et personne ne peut vous dire combien de temps il faut pour que le service réponde à nouveau.
C’est pourtant le seul chiffre que vos utilisateurs ressentiront. La fréquence de sauvegarde décrit ce que vous perdrez ; le temps de reconstruction décrit combien de temps vous serez absent. Le second se mesure en le faisant, et c’est précisément pour ça qu’il manque.
Le lien avec l’infrastructure qu’on reconstruit régulièrement est direct : c’est le même exercice, vu depuis l’autre bout. Reconstruire régulièrement fournit le chiffre. Le chiffre justifie de reconstruire régulièrement.
Et c’est aussi, une fois de plus, le même chiffre que celui de la réversibilité — souverain ne veut rien dire, réversible si. Combien de temps pour revenir. Combien de temps pour partir. C’est la même question posée à deux occasions différentes, et une équipe qui sait y répondre a réglé les deux d’un coup.
Ce qu’il en reste
Le berger de Lambs on Acid ne sauvegardait rien. Il vendait du temps : la différence entre cinq jours d’attente et deux heures. Tout son métier tenait dans un seul chiffre, le délai de reconstitution, et il n’avait rien d’autre à protéger.
C’est un cas limite et c’est très bien : les cas limites servent à voir clair. Le vôtre est un mélange, avec un petit noyau irremplaçable et une grande périphérie recalculable, et vous les traitez probablement de la même façon.
Faites le tri. Il est plus rapide que vous ne le pensez, et il finit presque toujours par une sauvegarde de moins et un chronomètre de plus.
Sauvegarder ce qui se recalcule, c'est payer pour un chemin plus long.