Discussion :

[Pierre31C]

Bonjour,
Je sollicite vos connaissances en PostgreSQL. Les miennes sont inexistantes et j'ai un besoin de beaucoup d'aide afin de résoudre un (gros) problème pour moi.
Contexte :
Je dois reprendre la gestion d'une base de données PostgreSQL. Malheureusement pour moi, le server contenant la base de données a crashé il y plusieurs mois de ça. Nous avons pu récupérer la partition des Data de ce server. J'ai découvert plusieurs dossiers de sauvegarde de la base: un .backup datant de 08/2015 et des fichiers dans un répertoire WAL_Archive.

J'ai l'impression qu'il est possible de reconstitué la base de données grâce a ses éléments. C'est possible mais je ne trouve pas d'explications claires (=correspondants à mon niveau) pour pouvoir remonter la base.

J'ai testé depuis pgAdminIII de faire un clic droit -> restaurer-> sélectionner le .backup : j'ai un message que le dossier doit être en format text et d'utiliser psql.

En théorie, je pense qu'il faut remonter le fichier .backup et rejouer les fichiers WAL depuis la date du backup sur la nouvelle installation pour que ça marche. Mais 1/ je n'en suis pas certain et 2/ j'en suis en pratique incapable.


Si quelqu'un a déjà rencontré ce problème et a réussi à récupérer sa base ou si quelqu'un est super chaud là dedans, je veux bien votre aide, please.

N’hésitez pas à m'expliquer comme à un enfant de 6 ans (c'est à peu près mon niveau)
Merci !!!

Environnement :
Windows
PostGresql 9.3.2

[SQLpro]

Restaurer une base consiste à reprendre l'intégralité des données de la base à un moment du temps ou la base est intègre. La notion d'intégrité étant fondamentale, sinon la base est considérée comme corrompue et sera inexploitable. C'est pour cela qu'il existe des mécanismes spécifiques de sauvegarde des bases, intégrées au SGBDR (ici en l'occurrence PostGreSQL), qui génère des fichiers destinés à la restauration.
En l'absence de tels fichiers, la restauration d'une base n'est pas garantie. En effet, la simple copie des fichiers ne garantie aucunement la possibilité de retrouver une base intègre.
Un exemple simple va vous démontrer pourquoi...
Imaginions que vous voulez sauvegarder votre base par simple copie des fichiers. Comme les fichiers vont être copiés successivement, il se peut que le fichier contenant la table des clients soit traité le premier, et le processus va continuer... Pendant ce temps, un utilisateur ajoute un nouveau client et une facture à ce client. Votre copie continuant, celle-ci porte finalement sur la table des factures.
Maintenant à la restauration vous vous retrouvez avec une facture ayant un numéro de client qui n'existe pas dans la table des client, ce qui est logiquement impossible...
Afin de se prémunir de ce cas de figure (et d'autres similaires) on a inventé un mécanisme appelé journalisation des transactions, constitué d'un fichier qui enregistre les commandes de mises à jour et les données avant modification afin d'en permettre la ré exécution (redo log) ou l'annulation (undo log).
Mais comme les fichiers de données et les fichiers de transactions doivent "coopérer" afin de savoir quelle a été la dernière transaction effectives, on enregistre dans les différents fichier un numéro séquentiel de transaction appelé LSN (Log Segment Number).

Bien entendu, vous ne pourrez restaurer une base et la rendre fonctionnelle que si les différents LSN se recoupent. Autrement dit, entre vos fichiers et les sauvegardes, vous devez pouvoir assurer une continuité des transactions, sans en oublier aucune, chaque transaction étant rejouée sur la base. Ce sont les fameux fichiers de type WAL, permettant une restauration PITR....

A +

[Pierre31C]

Merci pour votre retour.
Cependant, je cherche a remonter la base de données grâce aux différents fichiers que j'ai pu récupérer.
Pouvez vous m'aider là-dessus.

Merci

[alassanediakite]

Salut
Le processus...

1. Partir du dossier DATA...
   
   • copier le répertoire DATA sur la nouvelle machine
   • tenter l'installation de la dernière UPDATE de pg 9.3 en indiquant à l'intalleur le dossier DATA copié
2. Si le premier ne passe pas!!!, partir du backup (donc restauration)...
   
   • installer la dernière UPDATE de pg 9.3
   • arrêter le service pg, décompresser le contenu du .backup dans le dossier DATA de la nouvelle installation
   • configurer le fichier recovery.conf pour que le serveur tente une restauration lors du démarrage. Pour plus de détails.

[Pierre31C]

Salut
Le processus...

1. Partir du dossier DATA...
   
   • copier le répertoire DATA sur la nouvelle machine
   • tenter l'installation de la dernière UPDATE de pg 9.3 en indiquant à l'intalleur le dossier DATA copié
2. Si le premier ne passe pas!!!, partir du backup (donc restauration)...
   
   • installer la dernière UPDATE de pg 9.3
   • arrêter le service pg, décompresser le contenu du .backup dans le dossier DATA de la nouvelle installation
   • configurer le fichier recovery.conf pour que le serveur tente une restauration lors du démarrage. Pour plus de détails.

Merci alassanediakite ! Ca a marché