Restauration des données après un crash

Les crashs, ça arrive : panne matérielle, coupure de courant, bug dans le code ou, assez souvent, suppression accidentelle de la base par un admin un peu trop pressé de nettoyer "un vieux truc". Dans ces moments-là, les backups et un process de restauration bien rodé deviennent ta baguette magique.

On va décortiquer le process de restauration étape par étape, comme si on montait un meuble IKEA : pas de panique, on suit la notice à la lettre.

Étape 1. Analyse de la cause du crash

Avant de foncer tête baissée pour restaurer les données, il faut piger ce qui s’est passé.

1. Erreur de l’application ou de la base ?
   Checke les logs de ton appli et de PostgreSQL (en général dans /var/log/postgresql/ ou un dossier équivalent selon ton OS). Cherche les indices d’erreur.

2. Panne matérielle ?
   Si le serveur est physiquement HS (genre disque dur mort), vérifie d’abord que le matos fonctionne. Si ton disque est mort, branche-en un autre et restaure tout dessus.

3. Problèmes réseau ou d’accès ?
   Si le crash vient du réseau — ton serveur n’a sans doute pas besoin d’opérations de restauration pour l’instant.

4. Erreur humaine :
   Avoue... quelqu’un a fait DROP DATABASE ? Si oui, on a encore une chance de restaurer les données depuis un backup.

Garde en tête que bien comprendre la cause du crash t’aidera à éviter que ça recommence.

Étape 2. Vérification de la dispo des backups

C’est le moment de s’assurer qu’on a un bon backup. Trouve les derniers backups de ta base, faits avec pg_dump ou pg_basebackup. Vérifie qu’ils sont intacts. Si tu sais pas comment faire, voilà un rappel rapide :

• Utilise la commande ls -l pour checker la taille de tes fichiers. Si un fichier est trop petit, c’est louche.
• Checke le fichier avec la commande file. Par exemple :

  file backup_file.sql
  

  Tu dois voir une info qui dit que c’est un dump SQL.

Pour une archive tar, vérifie que tu peux l’extraire :

tar -tf backup.tar

Pas d’erreur ? Nickel ! On peut continuer.

Étape 3. Arrêt de PostgreSQL

Avant de restaurer, il faut stopper le serveur PostgreSQL pour sécuriser le process. Fais-le avec cette commande (en tant qu’admin serveur) :

sudo systemctl stop postgresql

Arrêter la base garantit qu’aucun process ne va gêner la restauration.

Étape 4. Préparation d’une nouvelle base pour la restauration

Si ta base a été supprimée ou corrompue, commence par la recréer. Exemple de commande :

createdb -U postgres new_database

Remplace new_database par le nom de ta base.

Étape 5. Restauration du backup

On va voir deux scénarios principaux de restauration :

1. Si tu utilises un backup SQL (pg_dump) : Pour restaurer, utilise la commande

   psql -U username -d new_database -f backup_file.sql
   

• username — ton user PostgreSQL.
• new_database — la base où tu veux importer les données.
• backup_file.sql — ton fichier de backup.

2. Si tu utilises un backup binaire (pg_basebackup ou pg_dump avec custom) :
   Pour restaurer, fais :
   

   pg_restore -U username -d new_database backup_file.dump
   

   Note que ces backups ne sont pas en texte, mais contiennent des données "packagées".

En plus :

• Si le backup ne contient que les données, ajoute --data-only.
• Si tu veux restaurer juste la structure, ajoute --schema-only.

Étape 6. Démarrage de PostgreSQL et tests

Après la restauration, relance le serveur :

sudo systemctl start postgresql

Maintenant, il faut tester. Essaie de te connecter à la base restaurée via psql ou pgAdmin. Fais quelques requêtes pour vérifier que les données sont OK :

SELECT * FROM your_table_name LIMIT 10;

Si tout a l’air bon, félicitations : les données sont restaurées !

Étape 7. Vérification de l’intégrité des données

Après la restauration, il est important de vérifier que les données sont intactes. Par exemple :

1. Compare le nombre de lignes dans les tables avec les backups :

   SELECT COUNT(*) FROM your_table_name;
   

   Compare le résultat avec ce que tu avais dans le backup (si tu l’as noté).

2. Utilise les checksums : Si tu avais généré des checksums pour tes tables, c’est le moment de les comparer :

   md5sum backup_file.sql
   

3. Vérifie les relations entre les tables : Assure-toi que les relations FOREIGN KEY restaurées fonctionnent bien.

Étape 8. Test de l’application

Maintenant, teste ton appli qui utilise cette base. Parcours les scénarios principaux. Y a-t-il des bugs ? Tout s’affiche bien ?

Exemples d’erreurs de restauration réelles

Voyons quelques cas concrets pour éviter les galères :

1. Incompatibilité de versions PostgreSQL.
   Imagine que le backup a été fait en version 12, et que le serveur est passé en version 15. À la restauration, tu vas avoir des erreurs.
   Solution : utilise la même version de PostgreSQL que celle du backup, ou checke la doc sur la compatibilité : PostgreSQL Documentation.

2. Backup corrompu . Si ton backup est corrompu, tu risques de perdre des données.
   Solution : fais de la réplication de backups (genre, garde plusieurs versions).

3. Erreur lors de la restauration d’une table spécifique.
   Si tu restaures une table, mais que les dépendances (genre les foreign keys) manquent, ça peut planter.
   Solution : restaure toujours les tables dans le bon ordre, en commençant par les parents.