Vérification de l'intégrité des données après restauration

Restaurer une base, c'est pas toujours finger in the nose : parfois tout a l'air OK, mais ensuite tu vois des erreurs dans les logs, des tables qui disparaissent ou des données cheloues. Voilà pourquoi c'est super important de toujours vérifier si tout roule vraiment après une restauration.

Parfois, une partie des données ne revient pas — genre si le backup était corrompu. Il arrive aussi que la structure des tables parte en vrille : des foreign keys qui sautent, des index qui disparaissent ou des valeurs bizarres qui poppent. Et même si tout semble normal au premier coup d'œil, les logs peuvent te souffler que la base n'est pas si saine que ça.

La vérification d'intégrité, c'est comme un contrôle technique après une réparation. Mieux vaut prendre un peu de temps pour checker que tout marche, plutôt que de se prendre un bug en prod sans prévenir.

Analyse des logs de restauration

Quand tu restaures des données avec pg_restore, PostgreSQL te sort forcément un log. Ce log contient plein d'infos utiles sur le process de restauration, y compris des warnings et des erreurs. Voilà un exemple de commande avec un fichier log :

pg_restore -U username -d database_name backup_file.dump > restore_log.txt 2>&1

Check bien le > restore_log.txt 2>&1 — ça balance à la fois la sortie standard et les erreurs dans un seul fichier.

Quoi chercher dans les logs ?

1. Erreurs. Sois attentif aux mots-clés comme "ERROR" ou "FATAL". Exemple :

   ERROR:  relation "étudiants" n'existe pas
   

2. Avertissements. Parfois tu peux voir des warnings "WARNING". Même si c'est pas critique, lis-les quand même — ça peut signaler des soucis :

   WARNING:  aucun privilège n'a pu être accordé pour la table "notes"
   

3. Incohérences de données. Vérifie si tous les objets clés sont bien revenus : tables, index, foreign keys.

Vérification rapide avec grep

Si ton fichier log est trop long (et parfois ils sont aussi longs que "Guerre et Paix"), tu peux utiliser grep pour chercher des mots-clés :

grep -i "error" restore_log.txt
grep -i "warning" restore_log.txt

Décryptage d'erreurs dans les logs

Regardons un vrai exemple de log :

ERROR:  contrainte "fk_étudiant_cours" pour la relation "inscriptions" n'existe pas
DETAIL:  Clé (cours_id)=(2) n'est pas présente dans la table "cours".

Qu'est-ce que cette erreur veut dire ? Ça veut dire que PostgreSQL essaie de restaurer une ligne dans la table inscriptions, mais il n'y a pas de cours_id correspondant dans la table cours.

Comment régler ça ? Peut-être que les données dans la table cours ont été corrompues ou n'ont pas été restaurées. Tu devras soit ajouter les lignes manquantes à la main, soit relancer la restauration.

Utilisation des checksums pour vérifier l'intégrité

Si tu veux être sûr que ton fichier de backup n'a pas été corrompu avant ou après la restauration, tu peux utiliser les checksums.

Un checksum, c'est un petit nombre qui représente les données d'un fichier. Si le fichier change, même d'un seul bit, le checksum change aussi. Ça aide à voir si le fichier a été abîmé.

Pour générer un checksum, tu peux utiliser l'outil md5sum. Exemple de commande :

md5sum backup_file.dump

Le résultat ressemblera à ça :

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Comparer les checksums

Si tu as noté le checksum du fichier à l'avance, tu peux le comparer avec l'actuel :

md5sum -c checksum.md5

Le fichier checksum.md5 doit contenir une ligne avec le checksum et le nom du fichier :

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Si le checksum matche, tu verras OK. Sinon — le fichier est corrompu.

Vérification des données au niveau de la base

Les checksums et les logs c'est cool, mais comment vérifier que les données elles-mêmes sont clean ? Voilà la checklist classique :

1. Comparer le nombre de lignes

Compare le nombre de lignes dans les tables avant et après restauration. Par exemple :

-- Compter le nombre de lignes dans la table étudiants
SELECT COUNT(*) FROM étudiants;

Si le nombre de lignes diffère, la restauration n'est pas complète.

2. Vérifier l'intégrité des clés

Vérifie les liens entre les tables pour t'assurer que toutes les foreign keys fonctionnent :

-- Vérifier les étudiants inscrits aux cours
SELECT *
FROM inscriptions i
LEFT JOIN cours c
ON i.cours_id = c.cours_id
WHERE c.cours_id IS NULL;

Si la requête retourne des résultats, ça veut dire qu'il y a des lignes dans inscriptions sans cours associés.

3. Comparer les données avec l'original

Si tu as une copie des données (genre un dump d'une autre base), tu peux comparer les résultats :

-- Vérifier les données de la table cours
SELECT * FROM cours WHERE cours_id NOT IN (
  SELECT cours_id FROM cours_backup
);

Cas réels de restauration

Un cas vécu : un jour, l'admin SGBD Bob a voulu restaurer des données depuis un backup après un crash serveur. Il a lancé la commande :

pg_restore -U admin -d ma_base_de_données ma_sauvegarde.dump

Mais en analysant les logs, la restauration a planté avec cette erreur :

ERROR:  impossible de créer le fichier "base/16385/pg_internal.init" : Plus d'espace disponible sur le périphérique

Ça voulait dire que le disque était plein. Après avoir libéré de la place et relancé la restauration, il a aussi vu que toutes les tables n'avaient pas été restaurées. Heureusement, grâce aux checksums générés à l'avance et à la config de l'archivage WAL, Bob a pu tout récupérer nickel.

Bilan de la vérification d'intégrité

Pour finir la vérif d'intégrité après restauration, fais ça :

1. Checke les logs pour les erreurs et warnings.
2. Utilise les checksums pour t'assurer que les fichiers sont pas corrompus.
3. Compare les données de la base sur le nombre de lignes et l'intégrité des liens.
4. Si un truc cloche, analyse les erreurs et recommence la restauration.

Maintenant t'es prêt à faire une vérif complète et à être sûr que tes données sont revenues comme tu voulais. Parce qu'en admin de base de données, le plus important c'est d'avoir confiance dans son backup !