Backup d'une base à partir d'un dossier récupéré

Bonjour,
Voilà, j'utilise PostgreSQL 9.3 avec ODOO 8.
Suite à une suppression par erreur de la base de données officielle, j'ai utilisé RecoverMyFiles pour récupérer le dossier data.
J'ai trouvé le dossier de la base concernée dans data/base/113876, mais je n'arrive pas à la remettre en place.
J'ai copié carrément le dossier data récupéré à la place de l’original, j'ai redonné les droits d'utilisateurs comme c'était avant, mais je n'arrive pas à voir mes bases.
Du coup, j'ai gardé l’ancien dossier data, j'ai juste copié le dossier 113876 correspondant à ma base perdue, mais je ne vois que les anciennes bases, pas ma base officielle.

Merci pour votre aide

Salut
Ta situation est telle que tu ne peux pas récupérer une base particulière.
Il faut REMPLACER CARRÉMENT le dossier data de la nouvelle installation par le dossier data de l'ancienne installation.
@+

Merci pour votre réponse j'ai remplacer le dossier data de la nouvelle installation par l'ancien dossier data, je n'arrive pas à demarrer le service PostgreSQL j'ai l'erreur suivante :

Citation:

---

Le service PostgreSQL_For_OpenERP - PostgreSQL Server 9.3 sur l'ordinateur local a démarré puis s'est arrêté. Certains services s'arrêtent automitiquement s'ils ne sont pas utilisés par d'autres services ou programmes.

---

Et au niveau de message d'erreur dans windows > Observateurs des événements j'ai le message suivant :

Citation:

---

Nom du journal*:Application
Source*: PostgreSQL
Date*: 03/07/2017 12:10:42
ID de l’événement*:0
Catégorie de la tâche*:Aucun
Niveau*: Erreur
Mots clés*: Classique
Utilisateur*: N/A
Ordinateur*: Win10
Description*:
Dépassement du délai pour le démarrage du serveur

---

XML de l’événement*:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="PostgreSQL" /> <EventID Qualifiers="0">0</EventID> <Level>2</Level> <Task>0</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2017-07-03T11:10:42.260369000Z" /> <EventRecordID>2866</EventRecordID> <Channel>Application</Channel> <Security /> </System> <EventData> <Data>Dépassement du délai pour le démarrage du serveur </Data> </EventData> </Event>

---

Merci pour votre Aide

Est ce que je peux remplacer juste le dossier data/base la ou il y a les bases de données ou si non le dossier data/base/113876
Merci

Salut
non et non!
Quel est l'OS utilisé?
Il faut s'assurer des points suivants...

• l'intégrité du dossier data récupéré
• l'existence des extensions de l'ancienne installation
• les tablespaces conformément à l'ancienne installation
• pour windows, les droits d'accès (au dossier data nouvellement copié) du compte exécutant le service postgres (généralement c'est le servie réseau)

@+

Merci pour votre réponse, alors L'OS utilisé dans l'ancienne installation c'est Windows Serveur 2008.

Pour le dossier récupéré voici une image du contenue récupéré :

Pièce jointe 291122

Pour ces deux points franchement j'ai pas bien compris ( désolé )

Citation:

---

l'existence des extensions de l'ancienne installation
les tablespaces conformément à l'ancienne installation

---

pour la dernière, j'ai bien mi les droits d'utilisation dans le dossier et c'est openpg pour odoo/PostgreSQL

Merci beaucoup

Salut
Voici mon dossier de PostgreSQL 9.3
Pièce jointe 291132
Pour les dossiers manquants (chez toi) tu peux essayer de les créer vide.
Par ailleurs le nom doit être data (non Recovered_data chez toi)!
@+

Merci pour votre réponse,
j'ai copié le dossier data puis j'ai crée les dossiers manquants, j'ai démarré le service PostgreSQL ça démarre sans soucis, par contre dans Pgadmin je vois que les anciennes base de donnés je vois pas les nouvelles bases, est ce que je dois rafraichir la liste des bases ou quoi ?

Merci pour votre aide

Salut
S'il s'agit des bases créées après récupération, oui il faut rafraichir (mais cela me semble très peu probable...).
Sinon, s'il s'agit des bases créées sur la nouvelle installation avant la récupération de l'ancien data alors tu ne les verra pas!
Pour cela...

1. remettre le data de la nouvelle installation
2. sauvegarder les bases UNE A UNE
3. récupérer l'ancien data
4. restaurer UNE A UNE les nouvelles bases sauvegardées

@+

Merci beaucoup
en fait je pense que si je vous mets dans la situation réel je pense que vous comprendrez mieux, alors j'avais une installation d'odoo 8 avec PostgreSQL 9.3, par erreur j'ai supprimé ma base officielle la ou il y a toutes mes données et j'avais pas mi de système de sauvegarde du coup j'ai perdu ma base tous ça sur windows serveur 2008, du coup j'ai utilisé RecoverMyfiles pour essayer de récupérer la base supprimé, j'ai pu récupérer le dossier data contenant les anciennes bases de données donc comme je vous ai expliqué j'ai réussi a mettre le dossier data a la place de l'ancien dossier qui ne contenait pas ma base et bien sur tous dans la même installation et le même pc .

Que dois-je faire pour qu'il reconnait les bases dans le nouveau dossier data .

Merci beaucoup

Questions et réponse une à une...
Comment avez-vous constaté la suppression de la base?

j'avais plusieurs bases de données sur odoo, en fait j'ai décidé de supprimer les non utiles du coup et par erreur j'ai supprimer la base depuis Odoo base de donné manager

Si tu as supprimé la base à partir l'interface d'administration (de Odoo, PgAdmin, psql ou tout autre chose) tu perds irrémédiablement la base à moins d'avoir une sauvegarde.
La solution que je te donne, suppose que tu à supprimé (puis récupéré) un répertoire de ton installation.
@+

Vous pensez qu'il n y a pas moyen de remettre en place le dossier data récupéré

Citation:

---

Envoyé par Le13009

Vous pensez qu'il n y a pas moyen de remettre en place le dossier data récupéré

---

récupéré DES EFFET DE QUELLE ACTION? Suppression de répertoire ou suppression de base à partir de l'interface d'administration?

c'est pas pareil ??? moi je parle plutôt d'une suppression de base à partir de l'interface d'administration, mais le problème c'est que j'ai pu récupéré le dossier data.......

Citation:

---

Envoyé par Le13009

c'est pas pareil ???

---

non, c'est ce que je t'ai expliqué!!!

Citation:

---

Envoyé par Le13009

moi je parle plutôt d'une suppression de base à partir de l'interface d'administration,

---

dans ce cas SEULE UNE SAUVEGARDE permet de récupérer la base!!!

Citation:

---

Envoyé par Le13009

mais le problème c'est que j'ai pu récupéré le dossier data.......

---

une récupération (à partir d'un logiciel de récupération comme RecoverMyFiles dans ton cas) est faite suite à la suppression de répertoire ou formatage depuis l'OS.
Pour comparaison, penses-tu qu'après modification d'un fichier word, RecoverMyFiles te permettra de retrouvé le même fichier avec sont contenu ancien?
@+

OK, je comprends.....Merci pour votre aide

Bonjour,

Le problème que vous avez, c'est que la copie du répertoire data qui est faite est une sauvegarde qui ne s'est pas faite instance arrêtée (sauvegarde physique à froid). Du coup, certains fichiers, comme les journaux de transaction, ne sont pas dans un état cohérent et le redémarrage risque d'être compromis...

Bon, la première chose à faire, c'est d'essayer de restaurer sur une machine différente de votre machine de production (un serveur de test). Il faut que son environnement technique soit identique à votre serveur de production (même architecture : 32 / 64 bits, même version du système d'exploitation).
Installez la même version de PostgreSQL (9.3 si j'ai bien suivi) dessus, arrêtez le service postgresql, puis restaurez votre copie du répertoire data sur ce serveur de test en lieu et place du nouveau répertoire data.
Essayez de redémarrer le service postgresql. Normalement, ça ne va pas fonctionner, parce que les journaux de transaction sont corrompus, mais ça se tente. Si ça ne fonctionne pas, il faut aller dans les journaux système pour nous donner plus d'infos sur l'erreur.

Merci beaucoup, je vais essayer de faire tous ça et je vous tiens au courant

Salut

Citation:

---

Envoyé par ced

Bonjour,

Le problème que vous avez, c'est que la copie du répertoire data qui est faite est une sauvegarde qui ne s'est pas faite instance arrêtée (sauvegarde physique à froid). Du coup, certains fichiers, comme les journaux de transaction, ne sont pas dans un état cohérent et le redémarrage risque d'être compromis...

Bon, la première chose à faire, c'est d'essayer de restaurer sur une machine différente de votre machine de production (un serveur de test). Il faut que son environnement technique soit identique à votre serveur de production (même architecture : 32 / 64 bits, même version du système d'exploitation).
Installez la même version de PostgreSQL (9.3 si j'ai bien suivi) dessus, arrêtez le service postgresql, puis restaurez votre copie du répertoire data sur ce serveur de test en lieu et place du nouveau répertoire data.
Essayez de redémarrer le service postgresql. Normalement, ça ne va pas fonctionner, parce que les journaux de transaction sont corrompus, mais ça se tente. Si ça ne fonctionne pas, il faut aller dans les journaux système pour nous donner plus d'infos sur l'erreur.

---

Il a fait une suppression de base à partir d'une interface de management donc un DROP DATABASE implicite. Penses-tu pouvoir faire une restauration de cette base avec une copie du dossier data?
@+

Si la copie du dossier DATA qu'il a, a été effectuée au moment de la suppression par le DROP DATABASE, la synchro des transaction est en principe garantie...
Dans tous les autres cas c'est mort...

A +

Re bonjour
Voila je viens d'installer windows serveur 2008 sur une autre machine ( même système d’exploitation même archi 64B même domaine......enfin la même structure ) après j'ai installé dessus la même version d'odoo bien sur avec la même version de PostgreSQL 9.3 après installation j'ai stoppé le service PostgreSQL j'ai remplacé le dossier data par le dossier récupéré, j'ai donné les droits au dossier ( les mêmes que l'ancien dossier ) j'ai lancer le service PostgreSQL, ça marche, il n y a pas d'erreur, j'ouvre Pgadmin mais malheureusement je vois que les anciennes base de donné, voila merci

Alors, c'est que votre copie du répertoire data ne contient déjà plus la base supprimée. Et là, malheureusement, sans sauvegarde, c'est cuit...

Citation:

---

Envoyé par Le13009

Re bonjour
Voila je viens d'installer windows serveur 2008 sur une autre machine ( même système d’exploitation même archi 64B même domaine......enfin la même structure ) après j'ai installé dessus la même version d'odoo bien sur avec la même version de PostgreSQL 9.3 après installation j'ai stoppé le service PostgreSQL j'ai remplacé le dossier data par le dossier récupéré, j'ai donné les droits au dossier ( les mêmes que l'ancien dossier ) j'ai lancer le service PostgreSQL, ça marche, il n y a pas d'erreur, j'ouvre Pgadmin mais malheureusement je vois que les anciennes base de donné, voila merci

---

Un SGBDR digne de ce nom (je ne parle pas de MySQmerde) utilise des tables système pour renseigner la liste des bases, des tables, etc...
Lorsque vous créez une base, PG commencer par créer une ligne dans la table système des bases de données, puis créer un répertoire, puis y créer les tables systèmes propres à la base.
L'oid attaché à la base sert d'identifiant du répertoire dans lequel la base sera stockée.
Regardez par exemple ceci :
Pièce jointe 293428
J'ai créé une base DB_TESTS) dans un tablespace particulier (C:\PGDB_TEST) afin de bien l'isoler.
PG a créé une première entrée d'instance avec PG_6.6_...
puis un répertoire reprenant l'OID de la base nouvellement créée (DB_TESTS)

Le simple fait de générer un nouveau répertoire ne sert à rien, il ne sera pas vu du SGBDR.

Ce que vous pouvez faire c'est :
1) créer un tablespace particulier
2) créer une base portant exactement le même nom que le base perdue dans ce tablespace
3) arrêter le service PG
4) supprimer le contenu du répertoire de la base
5) mettre les fichier de l'ancienne base dans ce rapertroire
6) redémarrer le service PG
7) mettre un cierge à Saint Isidore de Séville

mais le plus important est à mon sens VOUS FORMER À POSTGRESQL !

A +