Que faire si ta sauvegarde est corrompue

Sheet happens. Dans le cours précédent, on a aussi vu étape par étape comment restaurer complètement une base de données après un crash. Mais la réalité adore nous surprendre. Que faire si ta sauvegarde est corrompue ? Il est temps de voir ça de plus près.

Où vaut-il mieux mettre le CV ?

Blague. Là, on va parler technique. Mais n'oublie pas, dans chaque blague il n'y a qu'une part de blague :)

Analyse d'une sauvegarde corrompue

Une sauvegarde corrompue — c'est comme ton fichier de mémoire de fin d'études qui refuse de s'ouvrir juste avant de le rendre. Les symptômes sont similaires :

• Des erreurs à la tentative de restauration : quand tu lances pg_restore tu peux voir des erreurs du genre :

  pg_restore: [archiver] input file does not appear to be a valid archive

• Une partie des données manque ou le fichier a une taille bizarre (genre soudainement minuscule ou carrément zéro).
• Le fichier SQL décompressé contient des données coupées, des caractères chelous ou des sections vides.

Les corruptions de backup peuvent arriver pour plein de raisons :

• Interruption du processus de sauvegarde (genre coupure de courant ou arrêt du système).
• Mauvais transfert de fichier (erreurs lors de la copie sur une clé USB ou via le réseau).
• Pannes matérielles (disques, RAM, crash d'un RAID).
• Erreurs dans la config du système ou de l'outil de backup.
• Virus, malwares et bien sûr, le fameux "clic au mauvais endroit".

Récupérer des données depuis une sauvegarde corrompue

Si le fichier est corrompu, c'est pas forcément la fin du monde. Parfois, tu peux quand même sauver des trucs. Voyons quelques approches.

Tenter une restauration avec pg_restore

Si le fichier a été créé avec pg_dump au format custom ou directory, tente une restauration avec la commande pg_restore en ajoutant le flag --ignore-errors. Exemple :

pg_restore --dbname=your_database --ignore-errors backup_file.dump

Ce flag dit à l'outil d'ignorer les erreurs et de continuer. Bien sûr, les données aux endroits corrompus seront perdues, mais tu peux peut-être récupérer une partie de l'info.

Si ça marche, vérifie bien les données restaurées à la fin et note ce qui manque.

Utiliser les données partielles

Imaginons que tu as une sauvegarde au format texte SQL. Essaie de l'ouvrir avec un éditeur de texte (prends un truc costaud, genre Visual Studio Code ou Notepad++) pour voir où ça coupe. Si le fichier est lisible et que la plupart des requêtes SQL sont intactes :

1. Supprime la partie corrompue du fichier.
2. Exécute le reste des requêtes SQL à la main ou avec la commande psql :

psql -U username -d database_name -f partial_backup.sql

Lire un fichier au format custom

Si ta sauvegarde est au format custom, tu peux essayer d'en extraire le contenu morceau par morceau :

pg_restore --list backup_file.dump > file_list.txt

Cette commande va te sortir la liste de tous les objets dans le backup. Ensuite, tu peux tenter de restaurer des éléments séparés (genre des tables ou des schémas) avec :

pg_restore --dbname=your_database --use-list=file_list.txt backup_file.dump

En éditant file_list.txt, tu peux zapper les éléments corrompus lors de la restauration.

Tenter une restauration via les logs d'archive (WAL)

Si tu utilises des backups incrémentaux ou différentiels (genre avec pg_basebackup), t'as sûrement des logs d'archive (fichiers WAL). Ils gardent toutes les modifs depuis le dernier backup. Pour récupérer tes données, tu peux :

1. Trouver la dernière sauvegarde complète (genre un full backup).
2. Dire à PostgreSQL où sont les fichiers WAL :

   restore_command = 'cp /path/to/wal_directory/%f %p'

3. Lancer la restauration.

Utiliser des outils tiers

Parfois, tu peux limiter la casse avec des utilitaires de récupération de fichiers. Un outil populaire c'est ddrescue. Exemple :

ddrescue --force backup_file.dump recovered_dump.file

Cet outil va essayer de récupérer un max de données et créer une nouvelle copie du fichier.

Prévenir la corruption des sauvegardes

Ouais, bosser avec des fichiers corrompus c'est stressant. Voyons comment éviter ça.

Stocker les copies à plusieurs endroits

Comme dans tout projet, la règle du backup c'est "ne mets pas tous tes œufs dans le même panier". Duplique tes backups :

• Sur le serveur local.
• Dans le cloud (Amazon S3, Google Cloud Storage ou même un service simple genre Dropbox).
• Sur des supports externes (si tu veux être ultra-parano).

Vérifier régulièrement l'intégrité des sauvegardes

Y'a un dicton dans l'IT : "Un backup jamais testé, c'est pas un backup". Teste régulièrement tes sauvegardes en faisant une restauration sur un serveur de test. Pour ça :

1. Charge le backup sur un serveur de test.
2. Restaure les données depuis ce backup.
3. Vérifie que tout est correct.

Utiliser des checksums

Quand tu fais un backup, génère un checksum du fichier (genre avec MD5 ou SHA256) :

md5sum backup_file.dump > backup_file.md5

Quand tu veux restaurer, compare le checksum actuel avec l'original :

md5sum -c backup_file.md5

Comme ça, tu sauras tout de suite si le fichier est corrompu.

Exemples de restauration depuis des sauvegardes corrompues

Voyons deux cas réels.

Cas 1. Erreur de transfert de fichier

Tu transfères une sauvegarde via FTP, mais tu remarques que le fichier est plus petit que prévu. Tu as utilisé pg_dump en format texte, donc :

1. Tu ouvres le fichier dans un éditeur.
2. Tu vires la partie corrompue.
3. Tu restaures la partie saine avec psql.

Cas 2. Perte partielle de données dans les WAL

Ton serveur utilisait des backups incrémentaux et des fichiers WAL archivés. Soudain, certains fichiers disparaissent. Mais tu as pu restaurer les données avec pg_basebackup et les fichiers WAL restants, en indiquant leur chemin dans la config de restauration.

Souviens-toi, le backup c'est pas juste faire des copies, c'est aussi les tester. Attends pas la fin du monde pour découvrir que tes backups servent à rien. Et si jamais la sauvegarde est corrompue, panique pas : PostgreSQL propose plein de moyens pour récupérer tes données. Le plus important, c'est d'agir vite et proprement !

Et si rien n'a marché — relis le premier point de ce cours.