Pb migration V 0.68 vers 0.68.2

cedric · 2006-09-19 14:33:53

Bonjour,

Ce matin j'ai fait la maj de la V0.68 vers la V0.68.2
La maj s'est bien passée sauf que j'ai perdu la plupart de mes tickets....il m'en reste 4...sur 350 ..

Y a un moyen de les retrouver à part la sauvegarde journalière du serveur ?

Merci d'avance
Cédric

cedric · 2006-09-19 16:29:50

j'ai restauré la v0.68 mais maintenant j'ai ces messages :

Warning: include(C:/Program Files/OCS Inventory NG/xampp/htdocs/glpi/glpi/config/based_config.php) [function.include]: failed to open stream: No such file or directory in C:\Program Files\OCS Inventory NG\xampp\htdocs\glpi\index.php on line 39

Warning: include() [function.include]: Failed opening 'C:/Program Files/OCS Inventory NG/xampp/htdocs/glpi/glpi/config/based_config.php' for inclusion (include_path='.;C:\Program Files\OCS Inventory NG\xampp\php\pear\') in C:\Program Files\OCS Inventory NG\xampp\htdocs\glpi\index.php on line 39

Warning: include(C:/Program Files/OCS Inventory NG/xampp/htdocs/glpi/install.php) [function.include]: failed to open stream: No such file or directory in C:\Program Files\OCS Inventory NG\xampp\htdocs\glpi\index.php on line 41

Warning: include() [function.include]: Failed opening 'C:/Program Files/OCS Inventory NG/xampp/htdocs/glpi/install.php' for inclusion (include_path='.;C:\Program Files\OCS Inventory NG\xampp\php\pear\') in C:\Program Files\OCS Inventory NG\xampp\htdocs\glpi\index.php on line 41

je crois que j'ai déjà eu ça mais j'avais du le noter dans .....glpi ..
j'ai bien ce fichier...apparement y'a une erreur de syntaxe....non ?

help !

cedric · 2006-09-20 10:25:29

c'est hallucinant....j'y comprend rien....

hier matin, j'ai migré de la v0.68 à la v0.68.2....j'ai perdu toutes mes interventions.....

donc je restaure la sauvegarde de lundi soir, ça marche pas...cf message précédent...

donc je restaure la v0.65 avec ma sauvegarde du 31/08, ça marche, je migre en v0.68, ça marche sauf bien sur il me manque les données saisies depuis le 31/08...donc je restaure avec ma sauvegarde de lundi le repertoire ..\myssql\data\MaBase

et la j'ai un message me disant que ma base n'est pas dans la bonne version et en bas de l'écran je vois GLPI 0.65 ..!

qu'est ce que je fais mal ???

merci d'avance

cedric · 2006-09-20 11:54:45

j'ai essayé de tout remonter sur une autre machine, j'ai le même pb !

help !

cedric · 2006-09-20 16:09:21

Personnes ne peut m'aider ?
je suis vraiment bloqué et j'ai besoin de GLPI...

emgenet · 2006-09-20 17:22:15

Sur l'autre machine, t'as fait quoi exactement, si je comprend bien ta svg de Lundi est en 0.68.1.

Que se passe-t-il si sur ta nouvelle machine tu mets une 0.68.1, tu test le bon fonctionnement puis tu restaure ta svg de Lundi ?

pierrexp21 · 2006-09-20 17:29:54

Bonjour,

J'ai un souçis quasi identique!
Le fichier Sql de Glpi 0.65 est il compatible avec Glpi 0.68?

Merci d'avance

Pierre

JMD · 2006-09-20 17:57:10

oui les versions sont différentes les dump sql n'ont pas la meme structure. C'est bien pour ça qu'il faut passer à chaque fois par une mise à jour.

cedric · 2006-09-20 19:12:20

ma sauvegarde est une v0.68
donc sur l'autre machine j'installe une v0.68, je teste, ça marche bien....
je redescend uniquement la sauvegarde de la base....et la j'ai un message me disant que c'est pas la bonne version et que je dois faire un upgrade....mais sur cette page la version de glpi indiquée en bas de page est la v0.65...alors que j'ai installé la v0.68 et que la base que je redescend est une v0.68 !

mais le plus simple serait que je puisse relancer la v0.68.2 et que je fasse apparaitre mes anciens tickets !

donc la j'ai tout desinstallé sur le serveur ( OCS et GLPI ), j'ai supprimé le repertoire....
demain je reinstalle OCS RC3, GLPI 0.68 et je redescend la base de lundi....

on verra bien !

mais ca commence à me gonfler et mes collègues ont besoin de glpi !

je vous tiens au courant....

JMD · 2006-09-20 23:18:54

Je comprends que ça vous gonfle, nous aussi ça nous gonfle parfois...

Sachez toutefois que tout bon admin ne fait pas une upgrade sur base de production mais sur sa base de test afin de vérifier que tout fonctionne et que rien ne manque ensuite et seulement ensuite il upgrade sa base de production. Ceci permet d'éviter le caractère d'urgence et de stress dans lequel vous vous mettez et surtout d'assurer la continuité de service.

Cela vous aurez évité de perdre du temps à tout désinstaller pour rien. En matière de résolution de problème, il faut travailller méthodiquement et éliminer étape par étape les points pouvant poser problème.

En ce qui concerne votre premier post, s'il vous manque des informations suite à une mise à jour, c'est que la mise à jour s'est mal déroulée. Cela peut dépendre de la taille de votre db mais aussi de vos paramêtres dans votre php.ini.

cf wiki : http://glpi-project.org/wiki/doku.php?i … figuration

Ensuite je ne comprend pas ce que vous entendez par "redescendre" une base.

cedric · 2006-09-21 07:59:30

Bonjour

Je tiens à préciser que comme "tous bon admin" j'avais une sauvegarde complète de glpi et que je pensais qu'il suffisait de la restaurer en cas de pb !
cas que j'avais déjà rencontré....

en language de tous bon admin, "redescendre" une base signifie "restaurer"

j'ai regardé le lien wiki, ça ne correspond pas à mon pb....je vais jeter un oeil aux autres articles, je vous tiens au courant.

Merci encore
Cédric

cedric · 2006-09-21 10:09:38

juste une petite question

je repars d'une installation propre en v0.68
quels sont les fichiers data à restaurer ?
si je restaure tous le repertoire mysql\data\MaBase avec ma sauvegarde de lundi qui était en v0.68, quand je redémarre glpi, j'ai un message disant que la base n'est pas dans la bonne version et en bas de la page il me dit GLPI 0.65 !

merci d'avance

emgenet · 2006-09-21 12:39:49

Sauvegarder et restaurer ces fichiers ne me aparsi pas sain !

Je te propose la chose suivante, j'ai fait un cron (je suppose qu'on peux aussi le faire sous windows) avec un export complet de mes bases ocs et glpi dans un répertoire. Je sauvegarde ces fichiers. Quand j'ai besoin de restaurer je recré mes bases vides et j'importe ces exports, c'est plus propre. Je ne dit pas que le souci viens de la mais ce n'est pas impossible, à voir avec des spécialistes Mysql car je n'en suis pas un !.

@+

PS : Ca ne répond pas à ton pbm, mais c'est pour l'avenir.

Last edited by emgenet (2006-09-21 12:40:31)

JMD · 2006-09-21 13:02:47

Allé j'arrête ici, je laisse le soin aux autres Admins Windows de vous dépanner.

motsan · 2006-09-21 13:06:31

comme le dit JMD, procedont méthodiquement :

1 -re-installez une 0.65 (en terme de fichier glpi). recuperez des dump de vos sauvegardes
importez le fichier dump de la v0.65.
si vous ne pouvez pas faire une importation, vous n'etes peut etre pas un 'tout bon admin' .
plus serieux : la méthode de sauvegarde plus efficace est effectivement (cf emgenet) le dump de la base glpi. Donc essayez de restaurer une base avec les sauvegarde de vos fichiers.
testez si ca fonctionne (et dans ce cas faite un dump administration->données-> sauvegarde sql avec un nom style db0-65-[date sauvegarde].sql).
copiez ce dump ailleurs.

2 - supprimez le repertoire de glpi 0.65 et installez une 0.68 et faite une mise à jours.
testez si ca fonctionne, et faite un dump db0-68-[date sauvegarde].sql. copiez ce dump ailleurs.

3 - re installez un backup de votre rep mysql/glpi qui contient vos tickets. testez si ca marche. sinon supprimez le fichier de config et relancez l'install en faisant une mise à jours. testez si ca marche. si oui dump+ copy

4 - supprimez les fichiers glpi 0.68. installez les 0.68.2, faites une mise à jours. si ca fonctionne. faites un dump + copy.

voila, ca devrait etre bon ???

les dumps mysql sont tres efficaces en cas de restauration de DB. plus que les backup fichiers.
pour plus de securité, utilisez les deux méthodes : dump + backup.

@emgenet ou autre: le coup du cron m'interesse, comment on fait sous windows.

Last edited by motsan (2006-09-21 13:07:31)

aurel · 2006-09-21 18:50:54

Pour sauvegarder une base "proprement" utilise la commande mysqldump c'est très pratique car faire une sauvegarde du répertoire comme tu fais me paraît pas très propre" et surtout en faisant comme je t'ai dit je n'ai jamais eu de problème pour resataurer mes bases et n'oublie pas de sauvarger le répertoire _files qui contient tes fichiers si jamais t'en as uploadés via GLPI.

ex: mysqldump -u root -pton_mot_de_passe glpidb > glpi.sql

ps: quand JMD dit "tout bon admin" ce n'est pas à prendre méchament, il veut tout simplement dire qu'il est préférable pour plusieurs raisons de ne pas faire comme tu as fais c'est tout (même si moi aussi j'ai déjà fais ça sur une base de prod et que j'ai failli tout casser donc ça remarque est tout à fait judicieuse).

A+

cedric · 2006-09-25 08:32:36

aurel wrote:

Pour sauvegarder une base "proprement" utilise la commande mysqldump c'est très pratique car faire une sauvegarde du répertoire comme tu fais me paraît pas très propre" et surtout en faisant comme je t'ai dit je n'ai jamais eu de problème pour resataurer mes bases et n'oublie pas de sauvarger le répertoire _files qui contient tes fichiers si jamais t'en as uploadés via GLPI.
ex: mysqldump -u root -pton_mot_de_passe glpidb > glpi.sql

ps: quand JMD dit "tout bon admin" ce n'est pas à prendre méchament, il veut tout simplement dire qu'il est préférable pour plusieurs raisons de ne pas faire comme tu as fais c'est tout (même si moi aussi j'ai déjà fais ça sur une base de prod et que j'ai failli tout casser donc ça remarque est tout à fait judicieuse).
A+

c'est vrai que j'aurai du faire un dump de la base, je le fais pour toutes mes bases oracle....mais je n'y ai pas pensé pour la base glpi...je sais c'est ma faute....
Par contre je ne suis pas d'accord sur le fait qu'un dump soit plus "propre" qu'une sauvegarde complète des fichiers base arrêtée...sous oracle on fait des dumps pour les bases qui ne peuvent pas être arrêtées...bref...

je n'ai pas mal pris la remarque de JMD car elle était fondé, je trouvais juste que ça n'apportait rien au problème à ce moment la, la bêtise étant déjà faite.....c'est tout....
Cela dit, je vais mettre en place une version de test !

pour en revenir à mon pb, n'ayant pas de dump, j'ai reinstallé la V0.65 et restauré la base avec ma sauvegarde du 31/08 c'est à dire juste avant ma migration en v0.68.
Ensuite j'ai migré en v0.68 mais toujours impossible de récupérer mes données....je n'arrive même pas à visualiser les données avec phpmyadmin.....tant pis c'est pas grave, l'essentiel c'est que glpi marche....

maintenant je vais programmer un dump....

merci à tous

Last edited by cedric (2006-09-25 08:49:35)

Forum GLPI-Project

Announcement

#1 2006-09-19 14:33:53

Pb migration V 0.68 vers 0.68.2

#2 2006-09-19 16:29:50

Re: Pb migration V 0.68 vers 0.68.2

#3 2006-09-20 10:25:29

Re: Pb migration V 0.68 vers 0.68.2

#4 2006-09-20 11:54:45

Re: Pb migration V 0.68 vers 0.68.2

#5 2006-09-20 16:09:21

Re: Pb migration V 0.68 vers 0.68.2

#6 2006-09-20 17:22:15

Re: Pb migration V 0.68 vers 0.68.2

#7 2006-09-20 17:29:54

Re: Pb migration V 0.68 vers 0.68.2

#8 2006-09-20 17:57:10

Re: Pb migration V 0.68 vers 0.68.2

#9 2006-09-20 19:12:20

Re: Pb migration V 0.68 vers 0.68.2

#10 2006-09-20 23:18:54

Re: Pb migration V 0.68 vers 0.68.2

#11 2006-09-21 07:59:30

Re: Pb migration V 0.68 vers 0.68.2

#12 2006-09-21 10:09:38

Re: Pb migration V 0.68 vers 0.68.2

#13 2006-09-21 12:39:49

Re: Pb migration V 0.68 vers 0.68.2

#14 2006-09-21 13:02:47

Re: Pb migration V 0.68 vers 0.68.2

#15 2006-09-21 13:06:31

Re: Pb migration V 0.68 vers 0.68.2

#16 2006-09-21 18:50:54

Re: Pb migration V 0.68 vers 0.68.2

#17 2006-09-25 08:32:36

Re: Pb migration V 0.68 vers 0.68.2

Board footer