La sauvegarde est votre filet de sécurité, pas votre stratégie de migration
Votre équipe vient d'exécuter une migration de base de données qui a supprimé la table orders_archive. Les données avaient été déplacées vers une nouvelle table, donc tout semblait propre. Mais un ancien système dont personne ne se souvenait lisait encore cette table. Maintenant, la table a disparu, les données aussi, et la nouvelle migration pour la recréer n'a rien à restaurer.
Ou peut-être avez-vous changé une colonne price de INTEGER à DECIMAL, et un job batch qui s'exécute toutes les heures continue d'écrire des entiers dans cette colonne, corrompant silencieusement les enregistrements.
Dans ces moments, l'instinct est compréhensible : « Nous avons des sauvegardes. Restaurons simplement la base de données à l'état d'avant la migration. »
Cela semble raisonnable. Mais les conséquences sont souvent pires que le problème initial.
À quoi servent vraiment les sauvegardes
Les sauvegardes existent pour les scénarios catastrophiques. Un incendie dans la salle des serveurs. Une panne de baie de stockage. Un disque corrompu. Un administrateur qui supprime accidentellement une table critique. Dans ces situations, restaurer à partir d'une sauvegarde est la bonne décision. Vous n'avez pas d'autre option, et le coût de ne pas restaurer est une perte totale de données.
Mais une migration échouée n'est pas une catastrophe. C'est un événement opérationnel courant. Et la traiter comme un désastre crée de nouveaux problèmes.
Les deux problèmes du rollback basé sur la sauvegarde
Perte de données
Une sauvegarde est un instantané de vos données à un moment précis. Si vous avez effectué la sauvegarde à 2h00 du matin et que la migration échoue à 10h00, vous avez huit heures d'activité utilisateur qui n'existent que dans votre base de production. Commandes passées. Profils mis à jour. Tickets de support créés. Modifications de configuration effectuées.
Lorsque vous restaurez la sauvegarde de 2h00, toutes ces données disparaissent. Il n'y a aucun moyen de les récupérer à moins d'avoir une autre source. Cet écart se creuse à mesure que le temps entre la sauvegarde et la restauration s'allonge. Même si vous utilisez la restauration à un instant précis (point-in-time recovery) et restaurez à 9h59, vous perdez toujours ce qui s'est passé dans cette dernière minute.
Temps d'arrêt
Restaurer une base de données n'est pas instantané. Pour des bases de données de plusieurs centaines de gigaoctets, la restauration peut prendre des heures. Pendant ce temps, votre application ne peut pas servir le trafic normalement. Les données sont incohérentes, partiellement chargées ou verrouillées par le processus de restauration.
Comparez cela à une approche de roll-forward, où vous exécutez une nouvelle migration qui prend quelques minutes. Ou un script compensatoire qui ajuste les données sans arrêter l'application. Le rollback basé sur la sauvegarde force votre équipe à choisir entre perte de données et temps d'arrêt prolongé, souvent les deux.
La restauration à un instant précis réduit le problème mais ne le résout pas
Certaines équipes utilisent la restauration à un instant précis (PITR) pour réduire l'écart de données. Au lieu de restaurer la dernière sauvegarde complète, elles restaurent à une position spécifique du journal des transactions, par exemple une minute avant l'exécution de la migration.
Cela aide. Vous perdez moins de données. Mais vous en perdez toujours. Les transactions terminées dans les secondes précédant la migration sont perdues. Et la restauration elle-même prend encore du temps. La PITR est meilleure qu'une restauration complète, mais ce n'est pas un mécanisme de rollback propre.
Où la sauvegarde se situe dans votre hiérarchie de récupération
La sauvegarde a un rôle clair dans la récupération de base de données : c'est le dernier recours. Le filet de sécurité pour quand tout le reste a échoué et que vous êtes prêt à accepter la perte de données et le temps d'arrêt parce que l'alternative est pire.
Dans une équipe mature, les sauvegardes sont effectuées régulièrement et testées périodiquement. Mais quand une migration tourne mal, l'équipe ne se tourne pas d'abord vers la sauvegarde. Elle travaille selon une hiérarchie :
Le diagramme suivant résume ce processus de décision :
- Roll-forward : Écrire une nouvelle migration qui annule le changement ou ajoute l'élément manquant.
- Script compensatoire : Exécuter un script qui ajuste les données sans migration complète.
- Restauration par sauvegarde : Seulement après avoir évalué les compromis en termes de perte de données et de temps d'arrêt.
Une checklist pratique avant d'envisager la sauvegarde
Avant de restaurer à partir d'une sauvegarde, posez-vous ces questions :
- Pouvons-nous écrire une migration qui rajoute la table ou la colonne supprimée ?
- Pouvons-nous exécuter un script compensatoire qui reconstruit les données perdues à partir des journaux ou d'autres sources ?
- Combien de données allons-nous perdre si nous restaurons à partir de la dernière sauvegarde ?
- Combien de temps la restauration prendra-t-elle, et l'entreprise peut-elle accepter ce temps d'arrêt ?
- Existe-t-il un moyen de maintenir l'application partiellement en fonctionnement pendant que nous réparons les données ?
Si la réponse aux deux premières questions est « oui », vous n'avez pas besoin d'une restauration par sauvegarde. Si la réponse aux trois dernières questions est « inacceptable », vous devez trouver une autre solution.
L'essentiel à retenir
La sauvegarde est votre filet de sécurité pour les catastrophes, pas votre stratégie de rollback de migration. Quand une migration échoue, commencez par le roll-forward ou les scripts compensatoires. N'envisagez la sauvegarde que lorsque ces options sont épuisées et que vous avez accepté le coût de la perte de données et du temps d'arrêt. Une équipe qui traite la sauvegarde comme le plan de rollback par défaut est une équipe qui perdra des données de production et du sommeil.