OpenConcerto

Bonjour,
J'utilise OpenConcerto v13 beta 3 ou 4, mon disque vient de me lâcher...
J'étais en version monoposte mais à partir d'un serveur PostgreSQl (pas de H2).
Je n'ai pas la possibilité de faire un dump de la base comme indiqué dans le forum.
J'ai juste les données de la sauvegarde hebdomadaire effectuée à la sortie du logiciel: documents txt
Le manuel (papier) ne fait pas mention des procédures de sauvegarde et de restauration que ce soit en H2 ou bien SQL.
Merci de me donner la procédure, pour réintégrer la base.
Cdlt
Francis

Vous êtes sur qu'il n'y a rien dans le manuel?
Si c'est vrais je trouve ça dommage, c'est un point essentiel pourtant...
Bon courage et des que vous avez une solution dite le nous.
Alex

Bonjour,

Dans ce fil http://www.openconcerto.org/forum/viewt ... arde#p2273 Guillaume a dit :

La sauvegarde intégrée est destinée a vous sauver la vie si tout va mal, à utiliser en cas de dernier recours!

.

Mais pour la récupération, il ne nous dit pas comment faire et, question sous-jacente, si on peut le faire tout seul?

Pour ma part, j'effectue et récupère ma sauvegarde quotidiennement par la méthode pg_dump/pg_restore.

Mais j'apprécierais avoir cette fonctionnalité au sein du logiciel.

Et c'est vrai : l'explication sur ce fameux bouton "sauvegarde" manque dans le manuel (mais c'est un oubli mineur face à la somme d'information utile qu'il contient!).

Stephan.

Bonsoir,

pour faire une sauvegarde de PostgreSQL, la seule bonne méthode : pg_dump
pour restaurer les données : psql ou pg_restore

Il est vrai que le manuel ne traite pas de tout cela, car c'est vraiment à la marge d'OpenConcerto, les développeurs de PostgreSQL ont réalisé un très bonne documentation sur ces points.
J'ai souvenir que l'on conseille dans le manuel la lecture de la doc de PostgreSQL .
Pour la restauration, c'est la même procédure que l'installation multiposte (injection des données) que nous avons (je l’espère) bien détaillé.
Je note quand même dans un coin d'étoffer le manuel sur ces points, cela pourra sauver la mise à d'autres.

Pour votre problème en particulier, une bonne et une mauvaise nouvelle :
- vous pouvez dire merci aux gentils développeurs qui ont prévu le cas des Jedi qui utilisent la version multiposte, n'ont jamais pris le temps de mettre en place un système de sauvegarde du serveur (base de données et autres) : vos données ne sont pas perdues
- la mauvaise c'est que le format de cette sauvegarde d’extrême secours est fait justement pour récupérer des informations quand tout va VRAIMENT mal, d'où le format de fichier en clair (texte) et non binaires ou liés à un système. Avec un peu de patience, vous pouvez lire et traiter ces données vous même OU faire appel à la hotline qui sait vous recréer un fichier SQL à partir des données (en 4 jetons, me dit on) .

Cordialement,

Merci pour vos réponses.
Je vais me débrouiller, je me suis malheureusement reposé sur le fameux bouton sauvegarde sans me pencher sur son action réelle.
Je vais me pencher sur une procédure réelle de sauvegarde: intégrité des données mais au format natif + sauvegarde des documents générés contenus dans "Documents", l'intérêt c'est de pouvoir remettre en fonction rapidement le CRM.
Je vous tiens au courant dès que j'ai une solution.
Bon WE

Bonjour,

@Qualitec : la procédure mentionnée - pg_dump/pg_restore - est détaillée dans le fil référencé et une fois mise en place ne prend même pas une minute [je le fais TOUS les jours pour un transfert bureau->maison!]

Astuce pour les répeŕtoires de documents et le dump de sauvegarde : les mettre dans un(des) répertoire(s) sur un "cloud" synchronisé(s). De cette manière, il y a autant de copies qu'il y a de PC synchronisés. -- J'utilise Ubuntu One (5 Go gratuits) qui fonctionne sur Windows, Linux, et Mac.

@Guillaume : C'est le bouton de sauvegarde dans la fenêtre "Quitter le logiciel" qui est traître! Pourquoi ne pourrait-il pas servir pour lancer le dump justement?

Stephan

Bonsoir,

ce n'est pas possible de lancer un pg_dump depuis le poste car dans la plupart des cas, les utilisateurs ne travaillent pas sur le serveur...

La fonction sauvegarde fait débat, si c'est un "piège", il nous faudrait tout simplement la supprimer... mais dans ce cas, bonjour la catastrophe à long terme... Négliger les sauvegardes, ce n'est pas le seul cas de Francis, nous le voyons tous les jours avec nos clients. Certains sont mêmes surpris que nous prenions d'énormes précautions pour les sauvegardes (plusieurs supports, alternés et vérifiés régulièrement).
En moyenne, un disque dur c'est 5 ans de vie dans le monde de l'entreprise. Ceci est une moyenne, un disque qui lâche au bout de 2 semaines, nous avons déjà vu et nous avons beaucoup mieux à faire que de jouer les pompiers!

Bon weekend.

Bonjour,

La fonction (le bouton) sauvegarde ne fait débat QUE parce que le TYPE de sauvegarde qui en résulte n'est pas compris.

Du fait que les sauvegardes sont tellement essentielles, il ne faut surtout pas supprimer le bouton mais plutôt le renommer ou y joindre une infobulle [ou faire apparaître une fenêtre d'astuce] indiquant qu'il ne donne qu'une sauvegarde "texte" de dernier recours (dont la récupération nécessite des compétences particulières) et inciter à faire AUSSI un pg_dump (qui lui peut être facilement récupéré)!

Il s'agit simplement d'effectuer un peu de désambiguïsation.

Et puis en lisant ce fil, je me rend compte que parce que je ne fait que des dumps j'ai tout à fait négligé ce type de sauvegarde primaire et qu'il serait bon que j'en fasse une de temps en temps

À TOUS CEUX QUI PASSERAIENT PAR LÀ : UNE SAUVEGARDE NON TESTÉE N'EST PAS UNE SAUVEGARDE.

Stephan.

Bonjour,
Je rejoins un peu le fil de la discussion, je parlerais plutôt en terme d'efficacité ou bien qualité de service.
En cas de crash chez un client je pensais qu'il était simple de restaurer rapidement afin que la base soit à nouveau opérationnelle, mais pour moi ce n'est pas le cas, les documents générés ne sont pas sauvegardés et la base est sauvegardée sous forme de tables au format txt.
Difficile dans ce cas de remettre la base en fonction en une heure.
Mais que ça me serve de leçon une sauvegarde, qui n'est pas pleinement testée avec un essai de restauration, ne peut être considérée comme viable, ne serait ce que de s'approprier le processus.
Je m'oriente vers Cobian: sauvegarde des dossiers avec la possibilité (non essayée) d'effectuer un .batch pour le dump de la base SQL.
Merci pour ces échanges

Bonjour,

est-ce que les choses ont évolué depuis 2013 ou c'est toujours comme indiqué dans ce fil : la "sauvegarde" ne permet pas de restaurer rapidement et facilement les données pour un non initié aux lignes de commande ?

Une partie de mes données (écritures) a crshé en raison d'un problème de hardware et j'espérais pouvoir récupérer les données en copiant les fichiers de "sauvegarde" journalirs sur un autre PC... Ca marche, ou je dois faire appel à la hotline ?