Récupération à un instant donné vs snapshots : ce que vous perdez
La récupération à un instant donné et les snapshots se résument à un seul chiffre : la quantité de données que vous pouvez vous permettre de perdre. Comprenez le RPO, quand les snapshots nocturnes suffisent et quand ils ne suffisent discrètement plus.
Quelqu’un exécute un DELETE sans clause WHERE à 16 h 15. Votre sauvegarde la plus récente date de 3 h 00. Tout ce qui s’est passé entre ces deux moments est perdu, et aucune restauration ne pourra le récupérer.
Cet intervalle porte un nom — recovery point objective, ou RPO — et le choix entre récupération à un instant donné et snapshots consiste entièrement à déterminer l’ampleur de l’intervalle que vous êtes prêt à accepter.
Les deux modèles
Les snapshots capturent l’état de vos données à un instant donné. Ils s’exécutent selon une planification, généralement chaque nuit. En restaurer un vous ramène exactement à l’état qui était le vôtre au moment où il a été créé, et tout ce qui suit est perdu.
La récupération à un instant donné combine une sauvegarde de base avec un flux continu de journaux write-ahead de la base de données. Comme chaque modification est enregistrée dans l’ordre, vous pouvez rejouer les opérations jusqu’à n’importe quel moment couvert par les journaux conservés — y compris 16 h 14, soit une minute avant la suppression.
La différence n’est pas progressive. C’est la différence entre « nous avons perdu une journée » et « nous avons perdu une minute ».
Le chiffre qui permet de trancher
Posez-vous honnêtement une question : que se passe-t-il si vous perdez tout ce qui a été écrit au cours des douze dernières heures ?
Pour un projet personnel, un site de documentation ou un outil interne dont les données peuvent être recréées : pas grand-chose. Les snapshots nocturnes sont réellement la bonne réponse, et payer pour un archivage continu serait du gaspillage.
Pour tout ce qui reçoit des données saisies par des clients, la réponse ressemble généralement à ceci : « nous devrions écrire aux utilisateurs pour leur expliquer ». Des commandes qui n’existent plus. Des fichiers importés qui ont disparu. Des messages qui ont été envoyés et qui ne sont désormais plus là. Le coût du support à lui seul dépasse généralement en moins d’un an la différence de dépenses d’infrastructure.
L’erreur n’est pas de choisir les snapshots. L’erreur consiste à les choisir par défaut, sans jamais se demander combien coûterait un trou de douze heures.
Ce que les snapshots font réellement bien
Ce n’est pas une solution de second ordre. Les snapshots couvrent des défaillances que le PITR ne couvre pas :
- Perte complète du disque. Un snapshot stocké séparément restaure tout, y compris les fichiers qui ne sont pas gérés par la base de données.
- Retour en arrière rapide et global. Annuler une migration ratée dans un environnement de staging est plus rapide avec un snapshot qu’en rejouant un journal.
- Coût. Stocker une copie par jour coûte moins cher que de stocker chaque écriture.
- Simplicité. Avoir moins de composants est un véritable avantage opérationnel, en particulier pour une petite équipe.
Le piège consiste à les considérer comme suffisants pour une base de données qui reçoit des écritures en continu.
Ce que le PITR vous coûte
Ce n’est pas gratuit, et ses coûts méritent d’être explicités :
- Stockage. Vous conservez la sauvegarde de base ainsi que chaque écriture pendant toute la durée de rétention.
- Complexité. L’archivage doit fonctionner en continu. Un archivage qui échoue silencieusement depuis une semaine signifie que votre fenêtre de récupération s’arrête il y a une semaine — raison pour laquelle surveiller l’archive est aussi important que la configurer.
- Durée de restauration. Rejouer un journal prend plus de temps que restaurer un snapshot. Votre RPO s’améliore ; votre RTO, lui, se dégrade généralement.
Ce dernier compromis prend souvent les équipes au dépourvu. Le PITR signifie que vous perdez moins de données, pas que vous êtes de nouveau opérationnel plus rapidement.
La réponse à plusieurs niveaux dont la plupart des équipes ont réellement besoin
En pratique, il ne s’agit pas de choisir entre deux solutions. Les bases de données de production ont généralement besoin de trois niveaux, parce qu’elles peuvent tomber en panne de trois façons différentes :
Snapshots quotidiens, conservés une à deux semaines. Une assurance peu coûteuse contre la perte de la machine. C’est également ce qui couvre les fichiers qui ne sont pas liés à la base de données et qui se trouvent sur le même volume.
Exports logiques quotidiens, conservés en dehors de l’hôte. Un pg_dump est portable et cohérent par construction. Il peut être restauré sur une autre version majeure, chez un autre fournisseur ou sur un ordinateur portable — exactement ce qu’il faut lorsque le problème vient de la plateforme plutôt que des données.
Archivage continu, lorsque les données concernent des clients. C’est la couche qui transforme « nous avons perdu aujourd’hui » en « nous avons perdu une minute ».
Chaque couche couvre ce que les autres ne couvrent pas. Un snapshot ne vous aide pas à changer de fournisseur. Un export logique ne vous aide pas à récupérer un fichier qui ne se trouvait pas dans la base de données. Aucun des deux ne vous aide à annuler une suppression datant de quatre heures.
La place de Dockup
Dockup vous fournit les deux couches qui couvrent les défaillances les plus courantes, et il est utile de préciser lesquelles.
Snapshots de volume, à la demande ou selon une planification avec un nombre de versions conservées :
dockup volume snapshot <volumeId> my-project/my-api
dockup volume schedule <volumeId> my-project/my-api --daily --retention 7
dockup volume restore <volumeId> <snapshotId> my-project/my-api
Sauvegardes logiques de bases de données, transmises directement vers un stockage objet et chiffrées pendant le transfert :
dockup db backup my-project/main-db --json
dockup db backups my-project/main-db --json
Deux propriétés de cette seconde solution sont importantes pour la récupération. La sauvegarde n’est jamais déposée sur l’hôte de la base de données : elle est transmise au stockage au fur et à mesure que pg_dump la produit, et ne partage donc pas le même destin que le disque d’origine. De plus, un export qui se termine avec un code différent de zéro ou qui produit zéro octet est supprimé et enregistré comme ayant échoué, au lieu de rester dans la liste et de ressembler à une sauvegarde valide.
Dockup ne prend pas encore en charge l’archivage continu pour vous. Si votre RPO doit réellement se compter en minutes, vous devez le savoir avant de faire votre choix. Il est tout à fait raisonnable de l’exécuter vous-même sur une base de données managée tout en utilisant la plateforme pour le reste.
L’exercice à faire cette semaine
Notez deux chiffres pour votre base de données de production :
- RPO — la quantité de données que vous pouvez perdre. Il se mesure en temps.
- RTO — la durée pendant laquelle vous pouvez rester indisponible. Il se mesure également en temps.
Vérifiez ensuite ce que votre configuration actuelle offre réellement, en restaurant quelque chose. Si les chiffres que vous avez notés et ceux que votre configuration fournit sont différents, vous avez trouvé une décision à prendre alors que rien ne brûle — et c’est le seul bon moment pour la prendre.
Foire aux questions
Quelle est la différence entre le RPO et le RTO ? Le RPO correspond à la quantité de données que vous perdez — l’intervalle entre le dernier moment récupérable et la défaillance. Le RTO correspond à la durée nécessaire à la récupération. Les snapshots vous donnent un RPO élevé et un RTO court ; le PITR inverse généralement cette relation.
Puis-je récupérer des lignes supprimées il y a une heure à partir d’un snapshot nocturne ? Non. Un snapshot restaure l’état qui existait au moment où il a été créé. Tout ce qui a été écrit après ne s’y trouve pas. Pour récupérer un instant arbitraire, vous devez disposer d’un archivage continu.
Un snapshot de volume est-il la même chose qu’une sauvegarde de base de données ? Non. Un snapshot capture le disque, y compris l’état intermédiaire dans lequel se trouvait la base de données pendant une écriture. Un export logique est cohérent en interne et portable vers d’autres versions et d’autres fournisseurs. La plupart des environnements de production ont besoin des deux.
Combien de temps faut-il conserver les sauvegardes ? Assez longtemps pour détecter un problème. Une corruption ou une migration défectueuse n’est souvent découverte que plusieurs jours plus tard ; une seule journée de rétention signifie donc fréquemment que les seules sauvegardes dont vous disposez contiennent déjà les dégâts.