Sauvegardes, restauration et reprise

Comprendre le mécanisme

Une sauvegarde logique exporte des objets et données avec un outil comme pg_dump ; une sauvegarde physique et l’archivage WAL répondent à d’autres scénarios de récupération. Choisissez la méthode selon le point de reprise et le délai de reprise nécessaires. La réplication améliore certaines disponibilités, mais peut aussi répliquer une suppression erronée : elle ne constitue pas à elle seule une sauvegarde indépendante.

Raisonner et vérifier

Un fichier de dump présent ne prouve pas qu’il se restaure ni qu’il contient le périmètre attendu. Restaurez dans une base distincte, vérifiez schéma, données, droits et fonctions indispensables. Définissez la rétention, le chiffrement et l’accès aux copies. Avant une migration risquée, identifiez la sauvegarde restaurable et la compatibilité du code précédent avec le schéma futur.

Transformer une copie en preuve de reprise

Un fichier de sauvegarde présent démontre une production de données selon un outil, pas encore une restauration utile. Restaurez dans un environnement contrôlé et vérifiez que l’application peut retrouver ses invariants. Conservez versions, préconditions et résultat. Ce contrôle doit être régulier selon les évolutions du système ; une réussite ancienne ne couvre pas automatiquement un format ou un volume devenu différent.

Comprendre la perte admissible avec RPO

Le RPO décrit un objectif de perte de données admissible exprimé dans le temps. Il relie la fréquence et la disponibilité des copies à ce que le métier accepte de perdre lors d’un incident. Il ne définit pas le temps de redémarrage. Demandez quels événements doivent être récupérables et vérifiez la chronologie des données effectivement présentes après restauration, plutôt que déduire la perte du seul horaire du job.

Mesurer le délai de reprise avec RTO

Le RTO concerne le délai visé pour rétablir un service selon un périmètre défini. Il inclut davantage que la lecture d’une archive : provisionnement, restauration, vérifications et remise à disposition peuvent compter. Un objectif écrit n’est pas une mesure. Exécutez un exercice représentatif et notez le temps de chaque étape afin de savoir quelle hypothèse empêche de respecter le délai annoncé.

Le rôle des WAL dans une reprise ponctuelle

Une reprise vers un point choisi peut dépendre de la sauvegarde de base et des journaux WAL nécessaires à la chronologie visée. Conserver seulement une base ancienne ne permet pas de reconstruire librement tout état ultérieur. Vérifiez continuité, accès et procédure de récupération des journaux selon le modèle utilisé. Un exercice doit provoquer une absence contrôlée pour valider aussi le diagnostic et les limites de reprise.

Formats logiques et physiques

Une sauvegarde logique et une sauvegarde physique n’ont pas les mêmes contraintes de version, de restauration et de dépendances. Choisissez le format selon le besoin et l’environnement cible, puis testez les outils correspondants. Ne renommez pas simplement un fichier en supposant tous les formats interchangeables. La procédure doit préciser ce qu’elle conserve, ce qu’elle reconstruit et les éléments externes nécessaires au redémarrage utile du service.

Ne pas restaurer un secret retiré

Une sauvegarde peut contenir des credentials ou références qui étaient légitimes à sa date mais ont été retirés ensuite. Une restauration aveugle peut réintroduire cette capacité. Ajoutez une revue de configuration sensible et de cycle de clés à la procédure de reprise. Le succès technique de la base ne prouve pas la conformité de ses accès actuels ni des connexions qu’elle va tenter de réutiliser.

Restreindre les copies et leur lecture

Une sauvegarde peut représenter une copie très large des données sensibles. Elle demande donc des droits, une conservation et un transport adaptés à sa capacité réelle de divulgation. Un répertoire de diagnostic public n’est pas un stockage approprié simplement parce que le fichier porte un nom de secours. Les preuves d’exercice doivent rester expurgées et permettre l’analyse sans donner accès aux données réelles.

Reproduire le volume utile

Restaurer quelques lignes n’établit pas le délai d’une base volumineuse avec index et contraintes. Les ressources du stockage et de l’environnement de reprise comptent. Préparez un volume représentatif et mesurez les étapes coûteuses. Si l’exercice utilise une réduction volontaire du périmètre, annoncez-la dans la conclusion : elle sert à tester le mécanisme, pas à promettre un délai réel qui n’a jamais été observé.

Vérifier le sens des données retrouvées

Un processus de restauration terminé sans erreur ne prouve pas chaque invariant métier. Définissez les contrôles utiles, par exemple cohérence des relations, comptages attendus et possibilité de lire un parcours clé. Les tests doivent distinguer disponibilité technique et résultat fonctionnel. Un fichier reconstruit peut encore manquer une dépendance, un rôle ou un élément de configuration indispensable à l’application.

Retour de code, réplication et sauvegarde

La réplication peut reproduire une suppression logique accidentelle ; elle n’est donc pas une garantie indépendante contre toutes les erreurs métier. De même, revenir à un ancien binaire ne rembobine pas automatiquement la base. Définissez les scénarios couverts par chaque mécanisme et leurs limites. Une procédure de restauration doit être validée dans un environnement séparé, sans détruire les données qui pourraient encore servir à l’investigation.

Atelier guidé : lire, expliquer et vérifier le code

pg_dump --format=custom --file=lab-backup.dump lab_database
# Le processus retourne 0 ; aucun test de restauration n’a été fait.

La commande de l’atelier réalise un export logique et retourne un succès selon l’outil. Cela ne mesure pas encore un RTO et ne prouve pas la présence de toutes les conditions d’une restauration future. Le commentaire précise justement qu’aucune reprise n’a été exécutée. La conclusion doit rester limitée à l’export observé.

Préparez une base distincte de laboratoire, restaurez le fichier avec l’outil compatible puis lancez des vérifications choisies avant l’exercice. Mesurez le délai complet et contrôlez un petit parcours applicatif. Documentez les rôles et éléments de configuration nécessaires. Cet essai transforme une hypothèse de récupérabilité en preuve limitée et reproductible, tout en laissant visibles les volumes ou scénarios qui n’ont pas été couverts.