Tester une restauration PostgreSQL avant la migration

Ceci est un exercice de restauration, pas une procédure d’écrasement de la production. Confirmez moteur/version, responsable, rétention, chiffrement et espace disponible.

Créez et identifiez la sauvegarde

• Utilisez la méthode documentée et un instantané cohérent. Notez source, version, date/fuseau, taille, responsable de clé et somme de contrôle.
• Stockez la copie chiffrée hors du serveur de production. Évitez les secrets dans l’historique shell, tickets et captures ; vérifiez l’accès autorisé à la clé.

Restaurez dans une cible isolée

• Créez une base vide avec la version majeure, rôles et extensions compatibles. Restaurez avec l’outil PostgreSQL adapté ; ne ciblez jamais la production.
• Vérifiez tables, volumes critiques, contraintes, démarrage et parcours en lecture seule. Consignez durée et écarts avant d’approuver la migration.

Exemple et résultat attendu

• Choisissez l’outil selon le format : SQL brut avec psql, archive custom/tar avec pg_restore (inspectez avec pg_restore --list backup.dump). Restaurez dans une base jetable isolée, workers et intégrations externes désactivés, secrets de test uniquement. Jamais en production.
• Notez code de sortie, durée, nombre de tables attendu et contrôles agrégés. En cas d’échec ou d’écart, arrêtez-vous et vérifiez erreur, extensions et rôles sur l’hôte de test avant migration. pg_dump couvre une base ; sauvegardez les rôles globaux séparément.

Sources primaires

• PostgreSQL documentation · pg_dump and restore formats