Une sauvegarde permet de récupérer des données, mais la restaurer directement sur la base active peut supprimer des modifications légitimes effectuées après la date de la sauvegarde. Lorsque le problème concerne un enregistrement ou un ensemble limité, l’objectif consiste généralement à récupérer les informations perdues et à conserver le reste de l’état actuel. Cela exige de traiter la récupération comme une opération de comparaison et de rapprochement, et non comme un simple remplacement.
La stratégie appropriée dépend du moteur de base de données, du schéma, de la disponibilité de journaux d’audit et de l’étendue des dommages. Dans une application PHP, il est préférable de séparer la logique de récupération de l’application en production, de documenter les décisions et de tester les validations avant d’écrire des données. S’il est impossible de déterminer quelles modifications peuvent être appliquées sans risque, s’arrêter et préparer un rapprochement manuel présente généralement moins de risques que d’automatiser un écrasement.
Définir ce que signifie récupérer les données
Une restauration complète remplace une base, un schéma ou un vaste ensemble de données par le contenu d’un point de récupération. Une récupération sélective, en revanche, vise à rétablir des lignes précises ou certaines valeurs sans modifier les autres données actives. Avant de choisir, décrivez précisément le résultat attendu : quelle entité est manquante ou a été altérée, quels champs doivent être récupérés et quelles modifications ultérieures doivent être conservées.
Délimitez le périmètre à l’aide d’identifiants stables, comme la clé primaire, et pas seulement de valeurs susceptibles d’avoir changé, comme le nom ou l’adresse e-mail. Précisez également si l’incident concerne des enregistrements associés : une commande peut, par exemple, dépendre de lignes, de paiements, d’adresses et d’événements d’état. Ne récupérer que la ligne principale peut laisser une entité incohérente ; récupérer tout le groupe peut inclure des modifications valides qui ne doivent pas être annulées.
- Consignez le symptôme, l’intervalle de temps approximatif et la personne qui a signalé le problème.
- Identifiez les tables, les clés primaires, les clés étrangères et les contraintes pertinentes.
- Définissez quels champs doivent retrouver une valeur antérieure et lesquels doivent rester inchangés.
- Déterminez qui approuvera l’opération et quelles vérifications permettront de la considérer comme terminée.
Choisir un point de récupération et reconstituer le contexte
Sélectionnez un point de récupération qui permette de reconstituer l’état requis, pas nécessairement une sauvegarde antérieure aux dommages. Selon l’incident, il peut être nécessaire de comparer plusieurs sauvegardes, des journaux de transactions et des données d’audit afin de déterminer quelles informations doivent être récupérées et quel contexte ultérieur doit être conservé. Une récupération à un instant donné peut produire une base temporaire utile pour extraire des données, mais cela ne signifie pas qu’il est sûr de transférer l’intégralité de son contenu en production.
Vérifiez la date et le fuseau horaire, la couverture de la sauvegarde, le schéma utilisé lors de sa création et le résultat des vérifications d’intégrité disponibles. Une sauvegarde non vérifiée ne doit pas être considérée par défaut comme une source fiable. Vérifiez également si les identifiants ont pu être réutilisés ou si des processus écrivent dans les tables concernées pendant l’investigation.
Restaurez la sauvegarde dans une instance isolée, à accès restreint et sans connexion en écriture vers la production. L’application ne doit pas pointer accidentellement vers cette instance ni y exécuter de tâches planifiées. Si les données contiennent des informations personnelles ou sensibles, limitez l’accès et appliquez les mesures de protection prévues pour ces données. L’environnement isolé permet de comparer les états sans accroître les risques pour la base active.
Comparer sans supposer que la sauvegarde reflète la vérité actuelle
Comparez les lignes candidates de la sauvegarde aux lignes actuelles à l’aide de leurs clés stables. Pour chacune, distinguez trois situations : l’enregistrement n’existe plus, il existe mais certains champs ont été modifiés, ou il ne présente aucune différence pertinente. Si des horodatages de mise à jour, un historique des événements ou des journaux d’audit sont disponibles, utilisez-les pour comprendre quand et pourquoi la modification a eu lieu. Un horodatage à lui seul ne prouve pas quel utilisateur a effectué la modification ni s’il faut la conserver.
La récupération sélective exige une précaution essentielle : ne pas copier automatiquement une ligne ancienne dans son intégralité lorsque certains de ses champs ont évolué de manière légitime. La comparaison peut, par exemple, montrer qu’un enregistrement a perdu un champ descriptif, alors que son état, son propriétaire ou sa relation avec une autre entité a changé depuis. Récupérer uniquement le champ manquant peut être plus sûr que de remplacer toute la ligne, à condition que les règles métier le permettent.
Vérifiez également les conflits d’unicité, les clés étrangères, les colonnes obligatoires, les valeurs par défaut et les règles appliquées par l’application. Dans les systèmes utilisant la suppression logique, vérifiez si l’enregistrement est marqué comme supprimé plutôt que simplement absent. Les tables participant à une même opération métier peuvent nécessiter un rapprochement conjoint afin d’éviter des soldes, des états ou des références incohérents.
Appliquer une opération délimitée et vérifiable
Préparez un plan indiquant l’ensemble exact des clés et des colonnes à modifier. Avant de l’exécuter, conservez une copie de l’état actuel de ces lignes ou prévoyez un mécanisme équivalent de retour arrière. Testez le plan sur une copie récente de la base active et comparez le résultat à celui attendu. Le test doit inclure les contraintes et les dépendances réelles, et pas seulement l’importation de lignes isolées.
Lorsque le moteur et l’opération le permettent, exécutez les modifications dans une transaction. Une transaction ne remplace pas la vérification : certaines opérations de restauration ou d’importation peuvent avoir un comportement propre au moteur, et des processus externes peuvent mettre à jour des données de manière concurrente. Utilisez des conditions permettant de détecter les modifications inattendues entre la comparaison et l’écriture. Si la ligne ne correspond plus à l’état examiné, interrompez l’opération et réanalysez-la au lieu de l’écraser silencieusement.
Dans une application PHP, une tâche contrôlée ou une commande de maintenance peut valider les entrées, limiter les clés concernées et consigner les résultats. Évitez de construire des instructions SQL en concaténant des valeurs. Utilisez des requêtes paramétrées et le mécanisme transactionnel de la couche d’accès aux données employée par l’application. Gardez l’opération hors des routes publiques et n’exposez pas d’identifiants ni de sauvegardes dans des journaux en texte brut.
Avant de valider les modifications, vérifiez le nombre de lignes affectées, les contraintes et les relations pertinentes. Ensuite, contrôlez les valeurs récupérées et le comportement de l’application dans les opérations métier associées. Si une validation échoue avant la validation d’une transaction, annulez celle-ci. Si la transaction a déjà été validée ou si des effets irréversibles existent, n’improvisez pas une nouvelle écriture : déclenchez le plan de retour arrière ou de récupération approuvé avant l’exécution, en suivant la procédure testée pour rétablir l’état accepté et le vérifier. Si le plan ne permet pas de rétablir un état cohérent, interrompez toute nouvelle modification, conservez les éléments de preuve et soumettez la décision aux personnes responsables.
Consigner la décision et déterminer quand ne pas automatiser
Consignez l’incident, le point de récupération utilisé, les clés examinées, les champs restaurés et les modifications ultérieures préservées. Indiquez qui a examiné et approuvé l’opération, quand elle a été exécutée, quelles validations ont été effectuées et quel en a été le résultat. N’incluez pas de données sensibles inutiles dans le journal. Cette traçabilité permet d’expliquer la décision et facilite une investigation ultérieure.
Optez pour un rapprochement manuel si les clés fiables font défaut, si des opérations métier sont en conflit, s’il est impossible de distinguer une modification accidentelle d’une modification légitime ou si la récupération concerne des relations dont la signification dépend du contexte. Une restauration complète peut être appropriée en cas de corruption étendue, mais il faut en évaluer l’impact, l’interruption, la perte des modifications ultérieures et la procédure de récupération. Elle ne doit pas être choisie au seul motif qu’elle est plus simple à exécuter.
- Récupération sélective : les dommages sont bien délimités, les clés sont fiables et les différences peuvent être vérifiées.
- Rapprochement manuel : des modifications concurrentes ou des règles métier exigent un jugement humain.
- Restauration complète : les dommages sont étendus et un plan approuvé permet de gérer l’indisponibilité et les modifications qui seraient perdues.
Liste de contrôle avant de clôturer la récupération
- Préparation : le périmètre, les clés, les dépendances et le résultat attendu sont-ils identifiés ? Un point de récupération approprié a-t-il été choisi et vérifié ?
- Environnement et approbation : la sauvegarde a-t-elle été restaurée dans un environnement isolé, l’accès limité et la procédure testée ? Les personnes responsables ont-elles approuvé l’opération et le plan de retour arrière ou de récupération ?
- Exécution : l’état actuel des lignes concernées est-il conservé, l’écriture est-elle limitée aux clés et aux champs prévus, et les modifications concurrentes sont-elles détectées ?
- Vérification : les lignes affectées, les contraintes, les références et le comportement métier ont-ils été vérifiés ? Si une vérification échoue, les nouvelles écritures ont-elles été interrompues et la procédure approuvée déclenchée ?
- Traçabilité : la décision, l’exécution, les validations, les modifications préservées et le résultat ont-ils été consignés, sans inclure de données sensibles inutiles ?
Si vous ne pouvez pas répondre par l’affirmative aux points pertinents, reportez l’écriture en production. Le choix entre récupération sélective, rapprochement manuel et restauration complète doit reposer sur l’étendue des dommages, la fiabilité des éléments disponibles, l’impact opérationnel et la possibilité réelle de rétablir un état cohérent.
