Une migration peut modifier des millions d’enregistrements, alimenter des processus actifs et générer des effets en dehors de la base de données. Si une transformation échoue à mi-parcours, restaurer une sauvegarde complète n’est pas toujours sûr ni acceptable : de nouvelles données ont peut-être été écrites depuis la sauvegarde, ou le système ne peut pas être arrêté pendant la durée nécessaire à la restauration.
C’est pourquoi un plan de retour arrière pour les migrations de données ne doit pas se réduire à une commande pour revenir à l’état antérieur. Il doit définir comment identifier l’état affecté, quelles opérations peuvent être annulées, lesquelles nécessitent une compensation et quand il est préférable de réparer ou de reprendre le traitement. Cette décision se prépare avant l’exécution de la migration, à partir de critères que l’équipe peut vérifier sous pression.
Pourquoi restaurer une sauvegarde n’est pas toujours une solution de retour arrière viable
Une sauvegarde permet de récupérer des données après certains incidents, mais sa restauration peut supprimer des modifications légitimes apportées depuis sa création. Elle peut aussi entraîner une indisponibilité, la reconstruction d’index ou la perte d’écritures transmises à d’autres systèmes. En présence de réplications, de files d’attente, d’exportations ou d’intégrations, la récupération d’une base de données n’annule pas automatiquement ces effets.
Il convient de distinguer trois actions. Restaurer consiste à récupérer une sauvegarde ou un état à un instant donné ; revenir en arrière consiste à tenter d’annuler les modifications de la migration ; compenser consiste à appliquer de nouvelles opérations qui en corrigent les effets. Ces actions ne sont pas équivalentes : une compensation peut laisser un historique différent de l’original, même si elle rétablit les règles métier.
Le choix dépend de l’étendue de l’échec, des écritures effectuées depuis et des objectifs de reprise. Avant de commencer, déterminez quelle perte de données est tolérable, combien de temps l’interruption peut durer et qui autorise une opération de reprise. Si ces limites ne sont pas définies, l’équipe ne dispose d’aucun critère opérationnel pour prendre une décision.
Classer chaque transformation selon sa capacité de récupération
Décrivez chaque étape de la migration et classez-la selon le mode de récupération prévu :
- Réversible : une opération inverse fiable existe. Par exemple, la valeur d’origine est conservée avant la normalisation d’un champ et peut être restaurée sans écraser les modifications ultérieures.
- Compensable : il est impossible de reconstruire exactement l’état antérieur, mais une nouvelle opération peut corriger l’effet conformément à une règle métier. La compensation doit être explicite, auditable et, si possible, idempotente.
- Irréversible : des informations sont supprimées ou un effet est produit sans qu’il soit possible de l’annuler de façon garantie. Il faut alors décider explicitement d’accepter le risque, de conserver les données sources et d’effectuer des validations supplémentaires.
Cette classification ne doit pas reposer uniquement sur le type d’instruction SQL. Une mise à jour massive peut être réversible si la valeur précédente est enregistrée et si la concurrence est contrôlée ; elle peut ne pas l’être si d’autres processus modifient les mêmes lignes pendant son exécution. Tenez également compte des effets secondaires tels que les notifications, les appels d’API, les paiements ou les messages dans les files d’attente. Il est souvent préférable de séparer ces actions de la transformation des données.
Définir l’état initial et les invariants
Avant l’exécution, consignez le périmètre de la migration : entités incluses, filtres, version de l’application et règles appliquées. Définissez une référence initiale à l’aide de décomptes pertinents et, lorsque cela présente un intérêt, d’agrégats ou d’empreintes de jeux de données stables. Consignez la date et l’heure de référence ainsi que la source de ces données. Un chiffre dépourvu de périmètre et de contexte ne permet pas de vérifier une récupération.
Les invariants sont des conditions qui doivent rester vraies pendant et après la migration. Ils peuvent inclure les relations entre tables, l’unicité, les états autorisés, les montants à préserver ou la correspondance entre les enregistrements de la base de données et ceux des systèmes connectés. Associez à chacun une requête ou une procédure reproductible et un seuil d’acceptation. Si les données évoluent légitimement pendant l’exécution, définissez comment distinguer cette activité des effets de la migration.
Dans une application PHP, les transformations peuvent être implémentées dans des commandes en ligne de commande ou des processus de travail, plutôt que de dépendre d’une longue requête web. Ce choix ne supprime ni les risques de concurrence ni les limites transactionnelles : déterminez quelle unité peut être exécutée de manière atomique et que faire si le processus s’arrête entre deux opérations.
Concevoir des lots, des points de contrôle et une exécution reprenable
Divisez le travail en lots dont les limites sont explicites, par exemple à l’aide d’une clé stable et ordonnée. Évitez la pagination par décalage si des lignes peuvent être modifiées ou supprimées pendant le processus ; un marqueur de reprise fondé sur une clé est généralement plus prévisible. La taille des lots doit trouver un équilibre entre la durée des transactions, la charge sur la base de données et la facilité de détection des échecs.
Après chaque lot, enregistrez un point de contrôle avec l’identifiant de la tâche, la plage traitée, l’état, l’heure et les résultats des validations. La mise à jour des données et l’avancement du point de contrôle doivent être coordonnés pour éviter de déclarer traité un lot qui n’a pas été validé. Si ces deux opérations ne peuvent pas faire partie d’une même transaction, concevez un mécanisme de rapprochement qui détecte cette situation intermédiaire.
Une migration reprenable ne réapplique pas les modifications à l’aveugle. Chaque opération doit tolérer les nouvelles tentatives ou vérifier si son effet est déjà présent. En PHP, cela peut reposer sur des transactions, des contraintes d’unicité et des opérations idempotentes, selon le moteur et le modèle de données. Testez également des interruptions délibérées : un déploiement, une exception ou une perte de connexion ne devrait pas laisser le travail sans moyen connu de le poursuivre.
Consigner les modifications pour localiser les effets et auditer les décisions
Attribuez un identifiant unique à chaque exécution et consignez au minimum la transformation, le périmètre, les lots, les lignes affectées, les erreurs et les décisions de récupération. Pour les modifications susceptibles d’être compensées, conservez les données antérieures nécessaires ou une référence sécurisée vers celles-ci. N’inscrivez pas sans discernement des informations sensibles dans les journaux ; limitez l’accès, la durée de conservation et le contenu à ce qui est nécessaire à la récupération et à l’audit.
Le journal doit permettre de répondre à des questions précises : quelles lignes a-t-on tenté de traiter, lesquelles ont été validées, lesquelles ont échoué et quelle opération ultérieure les a modifiées ? Associez les journaux techniques à un historique des modifications métier si nécessaire. Ne confondez pas traçabilité et sauvegarde : le journal doit être suffisamment détaillé pour remplir son rôle et doit également être protégé contre la perte ou l’altération.
Choisir entre reprendre, compenser ou restaurer
Définissez à l’avance les signaux et les réponses à apporter, au lieu de décider uniquement à l’intuition lorsqu’une erreur survient :
- Reprendre : si l’échec est temporaire, que les invariants sont respectés et que les lots validés sont identifiés. Effectuez un nombre limité de nouvelles tentatives et surveillez les erreurs ainsi que la charge.
- Compenser : si les modifications appliquées sont connues et qu’une opération corrective a été testée. Arrêtez d’abord les nouvelles écritures incompatibles et vérifiez que la compensation n’écrasera pas des modifications valides.
- Restaurer : si la corruption est étendue, que la récupération à partir d’une sauvegarde a été validée et que les conséquences de la perte ou de la reconstruction des modifications ultérieures sont acceptables. Coordonnez la récupération avec les réplicas et les intégrations.
- Arrêter et faire remonter le problème : si l’état ne peut pas être déterminé, si les décomptes divergent sans explication ou si la compensation risque d’aggraver les dommages. Préservez les éléments de preuve avant toute intervention.
Définissez des seuils pour suspendre le travail, par exemple un taux d’erreur supérieur à la limite autorisée, un invariant non respecté ou un écart dans les décomptes. Précisez qui peut autoriser la reprise et qui décide d’une restauration. Dans certains cas, la solution la plus sûre consiste à isoler le flux affecté et à maintenir le système dans un état contrôlé pendant l’enquête.
Valider et clôturer la migration à l’aide d’une liste de contrôle
La fin du processus ne prouve pas que les données sont correctes. Comparez les décomptes avant et après en tenant compte du périmètre attendu, exécutez les règles métier et vérifiez les relations ainsi que les valeurs extrêmes. Utilisez des échantillons pour examiner des cas précis, mais pas à la place de vérifications exhaustives lorsque celles-ci sont réalisables. Si des consommateurs externes existent, vérifiez également leur état et convenez de la manière de rapprocher les écarts.
Avant l’exécution : classez les transformations, confirmez la sauvegarde et les procédures de récupération, testez les lots et les nouvelles tentatives avec des données représentatives, définissez les invariants, les seuils d’arrêt, les responsables et la fenêtre opérationnelle. Assurez-vous que l’équipe peut consulter le journal des modifications et que les procédures de compensation ou de restauration ont été testées.
Après l’exécution : validez les décomptes et les règles, examinez les erreurs et les effets externes, conservez le journal d’exécution et documentez toute exception. Gardez les informations de récupération à disposition pendant la période convenue et supprimez-les de manière sécurisée lorsqu’elles ne sont plus nécessaires. La migration n’est clôturée que lorsque les résultats peuvent être vérifiés et qu’une décision explicite a été prise concernant les écarts en suspens.
