Récupération après corruption de données
Un arbre de décision pas à pas pour la corruption de données (erreurs de checksum de bloc/page, tables illisibles, RDB/AOF corrompus) : confirmez d'abord l'étendue de la corruption, puis choisissez correctement entre récupération au niveau bloc, restauration complète/PITR depuis une sauvegarde et outils de réparation de dernier recours.
Quelle est l'étendue de la corruption ?
Lancez d'abord un contrôle d'intégrité pour déterminer jusqu'où la corruption s'est propagée. Seuls quelques blocs/pages sont-ils corrompus, un seul objet (table/index) est-il touché, ou la corruption est-elle généralisée ? Analysez avec les commandes ci-dessous pour déterminer l'étendue, puis choisissez la branche appropriée.
RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE; -- then: SELECT file#, block#, blocks, corruption_type FROM v$database_block_corruption;- Seuls quelques blocs / pages sont corrompus
- Un seul objet (table/index) est touché
- Corruption généralisée / nombreux objets
- Les outils de contrôle ne fonctionnent pas, la base ne s'ouvre pas
- La corruption se répète (cause racine suspectée)
Cause racine : corruption limitée de blocs/pages → récupération ciblée
Si seuls quelques blocs/pages sont corrompus, inutile de restaurer toute la base. Minimisez la perte de données en ne réparant que les parties corrompues depuis la sauvegarde/les journaux grâce à la fonctionnalité de récupération au niveau bloc/page du moteur.
Cause racine : corruption au niveau objet/généralisée → restauration complète ou PITR depuis une sauvegarde
Si la corruption s'est propagée à un ou plusieurs objets, la voie la plus sûre est de restaurer depuis une bonne sauvegarde et, si possible, d'avancer jusqu'au moment de la corruption (PITR). Cela évite la perte de données qu'entraîneraient les outils de réparation.
Pas de sauvegarde / la base ne s'ouvre pas — passer au dernier recours ?
Les outils de réparation (REPAIR_ALLOW_DATA_LOSS, innodb_force_recovery, --fix) PEUVENT ENTRAÎNER UNE PERTE DE DONNÉES et rompre les contraintes d'intégrité. Ils ne sont qu'un dernier recours lorsqu'aucune sauvegarde exploitable n'existe et que la base ne peut pas être ouverte. Assurez-vous d'abord qu'il n'existe vraiment aucune sauvegarde exploitable.
- J'ai trouvé une bonne sauvegarde, je restaure
- Aucune sauvegarde, un outil de réparation est la seule option
Dernier recours : outils de réparation avec risque de perte de données
Ces outils écartent les lignes/pages corrompues pour rendre la base ouvrable. Ne les utilisez que s'il n'existe aucune sauvegarde et après avoir copié les fichiers existants. Objectif : l'ouvrir juste assez pour exporter les données, puis les transférer vers une copie saine.
Cause racine : matériel/infrastructure → corrigez la source et activez les checksums
Si la corruption se répète, la cause réelle est très probablement le disque, le contrôleur, la mémoire (RAM) ou une couche de stockage instable. Récupérer les données ne suffit pas ; si vous ne corrigez pas la source, la corruption reviendra. Activez aussi la vérification par checksum/intégrité pour une détection précoce.