You are not logged in.

Announcement

 Téléchargez la dernière version stable de GLPI      -     Et vous, que pouvez vous faire pour le projet GLPI ? :  Contribuer
 Download last stable version of GLPI                      -     What can you do for GLPI ? :  Contribute

#1 2018-02-09 17:44:30

rreglpimc
Guest
Registered: 2018-02-09
Posts: 8

restauration de base GLPI via maintenance

Bonjour

débutant sur GLPI et ayant 2 serveurs (1 de prod qui doit rester dispo, 1 de test qui va servir justement pour des tests) j'ai voulu répliquer ma base de prod avec tout ce qu'elle contient (inventaire, ticket, pj) vers mon serveur de test.

- les 2 VM sont en windows 2012 + IIS 8.5 + PHP 7.0 + MySQL Server 5.1

- J'ai aligné les plugin pour n'en garder qu'un seul et donc la conf est identique des 2 côtés (même user, même mdp, même arbo)

- J'ai eut pas mal de soucis pour effectuer la sauvegarde de ma base de prod, voici ce que j'ai fait :
-> menu maintenance -> sauvegarde ko à 17% avec une erreur C:inetpubwwwroot/files/_dumps/glpi-9.2.1-2018-02-08-16-37.sql.gz): failed to open stream:
No such file or directory
-> edition de php.ini pour allonger le timeout sur l'exécution des requêtes + edition du backup.php pour appliquer une correction trouver dans un autre post sur le forum (forcer les / dans la variable $dumpFile)
-> résultat ma sauvegarde a pris environs 45min mais elle s'est terminée avec la barre de progression à 100%

- J'ai ensuite copier mon dump ainsi que l'ensemble des fichiers de PJ des tickets qui se trouvent dans /files sur le serveur de test

- Sur mon GLPI de test, je vois bien le fichier .sql.gz mais en cliquant sur le bouton "Restaurer" il ne se passe rien, tout en plus l'écran clignote mais il n'y a pas de message d'erreur ou de loading indiquant qu'une requête s'exécute et rien n'est restaurer.
Le comportement est identique si je fait un backup de la base de test et que je tente une restauration, aucune confirmation, aucune progression. (j'ai effectué un ajout de ticket entre les 2 actions pour pouvoir vérifier si je voyais une différence).

Bref je me retrouve bloqué sans savoir pourquoi l'import ne fonctionne pas. (il n'y pas d'erreur dans le php-errors.log)

En parcourant le forum j'ai vu plein d'informations variées mais je n'ai pas de phpmyadmin, je n'ai donc pas su purger les tables de log qui pourrait être à l'origine du soucis d'import/export (sans être sur que ça soit lié à ça).

Idem le backup et la restauration via les binaires mysql en ligne de commande me semblent tout au plus obscurs et pour avoir tenter une dump sur mon serveur de prod ce dernier s'est retrouvé inaccessible (je suppose que le binaire lock la base mysql le temps du dump). Je n'ai aucune idée de comment faire un import sur mon autre vm en ligne de commande.

Dans tous les cas il semble que bien que ma base ne soit pas énorme (le fichier .gz fait 15Mo et le fichier .sql décompressé fait 112Mo) et bien qu'ayant réussi à faire la sauvegarde je me vois dans l'impossibilité de faire un import.
A noter Le bouton "Supprimer définitivement" ne fonctionne pas non plus bien que les droits sur l'arbo de glpi soit ouverts. (pour permettre de tester je "re-sécuriserai" par la suite)

Quelqu'un aurait des informations ou des idées sur le sujet ?


Question subsidiaire, y a t il un moyen de reset/purger la base sur mon serveur de test pour permettre un import propre ?

Offline

#2 2018-02-09 17:54:21

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 4,084

Re: restauration de base GLPI via maintenance

bonjour,
les commmandes de mysql en ligne de code  permettent de faire des dumps, restaurer et détruire les bases de données.
pour info un un dump de ma base de prod ne prend que quelques minutes. pareil pour la restauration .


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+formcreator2.5.2 PHP7.0 Mariadb10
*GLPI 9.2.4(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.
*GLPI 9.3  en test (ubuntu 16.04 mariadb 10.2.4) (attente 9.3.1 et plugin compatible avant mise en prod)

Offline

#3 2018-02-09 18:00:17

rreglpimc
Guest
Registered: 2018-02-09
Posts: 8

Re: restauration de base GLPI via maintenance

merci mais ça ne débloque pas vraiment ma situation. Est ce que je peux dump sans bloqué ma base de prod (visiblement non) ?
idem la restauration va lock ma base de destination je suppose ?

Ensuite j'aimerai d'abord comprendre pourquoi en passant par l'interface ça ne fonctionne pas du tout et qu'il n'y a aucune erreur. Une fonction qui ne fonctionne pas ce n'est pas normal y compris avec ma base de test qui fait 1.5Mo (donc ce n'est pas un soucis de taille).

Je reste partisan des interfaces graphiques et si on peut éviter les lignes de commande à outrance c'est d'autant plus pratique à gérer. Mais si je n'ai pas le choix je appliquerai cette solution.

Offline

#4 2018-02-12 17:50:51

rreglpimc
Guest
Registered: 2018-02-09
Posts: 8

Re: restauration de base GLPI via maintenance

Petit update après avoir fait plusieurs tests, je suis toujours preneur de conseils détaillés sur la meilleure manière de faire :

- Backup et restauration via ligne de commande mysql ok --> ci dessous les commandes utilisées au cas où ça pourrait servir à qqqlun :

mysqldump -h localhost -u root -p --single-transaction --databases MYDB > fichier.sql

mysql -u root -p MYDB < fichier.sql

Question subsidiaire : Est ce qu'on peut faire une sorte de backup incrémental avec la ligne de commande ?


- Backup via interface GLPI ok après avoir modifier mon php.ini mais le fichier obtenu n'est pas utilisable pour restaurer sur mon autre instance GLPI (ou sur la même instance ou le backup a été réalisé)
=> lorsque je dépose le fichier dans _dump et que je clique sur "Restaurer" dans le menu "Maintenance", j'ai juste la page qui clignote une fois et rien, pas d'erreur, rien dans les logs donc aucun moyens de savoir pourquoi c'est ko. Quelqu'un sait pourquoi ?


- Test avec PHPMyadmin, comme je préfère une interface graphique à la ligne de commande pure j'ai tenté de monter un phpmyadmin. La configuration a été réalisée, je rentre bien mon compte et mdp pour la connexion aux bases (base de mon appli + base par défaut de mysql + compte root) mais ça génère des erreurs comme ci dessous :

SET lc_messages = 'fr_FR';
#1193 - Unknown system variable 'lc_messages'

et

Warning in .\libraries\dbi\DBIMysqli.php#576
mysqli_real_escape_string() expects parameter 1 to be mysqli, boolean given

=> le menu de gauche est vide en dehors de "___Nouvelle base de données", un clic sur n'importe quel onglet me ramène à l'authentification et j'ai essayé plusieurs solutions trouvées sur stackoverflow mais rien à faire le phpmyadmin ne veut pas de ma base mysql (j'ai déplacé temporairement la base de mon appli pour ne conserver que la base par défaut de mysql afin d'avoir le minimum syndical).

Si quelqu'un a des informations, je suis preneur. Merci d'avance

Offline

#5 2018-04-12 10:14:04

groot
Guest
Registered: 2018-04-12
Posts: 11

Re: restauration de base GLPI via maintenance

Bonjour,

Je ne sais pas si tu as avancé avec tes problèmes mais je suis à peu près dans le même cas que toi, j'ai un serveur de prod sous 2012 que j'aimerais le dupliquer pour en faire un serveur de test

J'ai installé un nouveau serveur avec exactement la même conf que la prod, (même OS, même wamp, même GLPI)

J'ai rencontré le même souci que toi pour l'export SQL, je l'ai solutionné rapidement en modifiant l'URL
Tu peux voir qu'il manque des "/", donc en gros ton URL est " C:inetpubwwwroot/files/_dumps/glpi-9.2.1-2018-02-08-16-37.sql.gz", il faut la modifier en " C:/inetpub/wwwroot/files/_dumps/glpi-9.2.1-2018-02-08-16-37.sql.gz"
chez moi pour une base de 25 Mo il a fallu 11h, alors qu'en mode ligne de commande sans compression il a fallu environ 5min (pour 2Go)

J'ai copié le dossier "files" de la prod sur la test

Ensuite j'ai copié le fichier gz sur le serveur de test, j'ai lancé l'import qui a tourné environ 15min, il n'y a pas eu d'erreurs, en revanche il n'y a que les PC qui ont été importé dans la base de test

J'ai essayé d'importer le fichier sql non compressé (celui de 2Go) en ligne de commande sur mon serveur de test, ça a tourné environ 2h, il n'y a pas eu d'erreurs, la base semble bien remplie (vu avec phpmyadmin) mais dans GLPI il n'y a rien du tout...


Voila, si quelqu'un a des idées je suis preneur

Merci

Offline

#6 2018-04-12 10:24:59

rreglpimc
Guest
Registered: 2018-02-09
Posts: 8

Re: restauration de base GLPI via maintenance

Bonjour,

alors effectivement j'ai abandonné l'idée d'utiliser le backup/restauration depuis l'interface graphique GLPI. En effet même après avoir corriger les soucis de chemin avec l'ajout des "/" mon dump était incomplet.

L'usage de la ligne de commande mysql pour le backup et la restauration fonctionne très bien et est même automatisé via Control-M pour une sauvegarde quotidienne sur un NAS.
Sinon je n'ai toujours pas réussi à faire fonctionner phpmyadmin avec ma base GLPI donc j'ai également abandonné cette voies.

Pour ton cas de figure, par contre je ne sais pas si c'est le double import (via le fichier gz puis via le fichier sql) mais c'est effectivement bizarre que tu ne vois rien dans l'interface de GLPI si ta base est remplie.

A la limite je dirais de refaire l'installe propre de ton serveur de test (au moins détruire la base GLPI existant et en initialiser une nouvelle puis faire l'import sql) ou encore plus simple si c'est une VM type vmware directement la dupliquer (en passant par un changement du nom de machine et d'ip histoire d'adapter à ton écosystème de test).

Dernier point, pour être sur que tes 2 GLPI sont iso, vérifie que tu as bien les mêmes plugins des 2 côtés.

cdlt

Last edited by rreglpimc (2018-04-12 10:30:02)

Offline

#7 2018-04-12 10:33:53

groot
Guest
Registered: 2018-04-12
Posts: 11

Re: restauration de base GLPI via maintenance

Merci pour ta réponse rapide

Quand je disais que j'avais fait 2 imports c'était avec une resintall complète entre les 2 wink
Je n'ai pas cumulé les imports

Quelle commande as-tu utilisé pour tom export/import

moi j'ai fait :

Sur le serveur de prod :
mysqldump -u monuser -p mabasedeprod > c:\temp\baseprod.sql

ensuite j'ai recopié le fichier baseprod.sql sur le serveur de test puis j'ai lancé l'import :
mysql -u monuser -p mabasetest < c:\temp\baseprod.sql

Si je me connecte en phpmyadmin, je vois bien ma base de test complète avec les données provenant de la base de prod
Mais dans GLPI c'est tout vide.....

J'ai bien une infra virtuelle mais j'ai peur d'oublier de modifier un fichier dans la conf GLPI et de me retrouver avec la prod et la test en conflit !

Offline

#8 2018-04-12 10:39:36

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 4,084

Re: restauration de base GLPI via maintenance

le glpi/config/config_db.php est bien à jour ?


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+formcreator2.5.2 PHP7.0 Mariadb10
*GLPI 9.2.4(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.
*GLPI 9.3  en test (ubuntu 16.04 mariadb 10.2.4) (attente 9.3.1 et plugin compatible avant mise en prod)

Offline

#9 2018-04-12 11:19:27

groot
Guest
Registered: 2018-04-12
Posts: 11

Re: restauration de base GLPI via maintenance

Je viens de me rendre compte que l'import ne fonctionnait pas si bien que ça (via maintenance)
Il arrivait bien à 100% et il n'y avait pas d'erreurs mais je viens de voir que ma partition était pleine
Je l'ai étendu (+20 Go) et j'ai relancé l'import....de nouveau pleine...j'ai rajouté 20Go...idem, pleine
En fait y'a un fichier /wamp/www/glpi/files/logs/sql-errors.logs qui fait 70 Go et qui ne cesse d'augmenter... j'ai encore ajouté 20Go pour voir si l'import s'arrête à un moment...

Offline

#10 2018-04-12 11:20:07

groot
Guest
Registered: 2018-04-12
Posts: 11

Re: restauration de base GLPI via maintenance

LaDenrée wrote:

le glpi/config/config_db.php est bien à jour ?

c'est à dire ? à jour par rapport à quoi ?
c'est une nouvelle install, donc y'a les infos de la nouvelle base (qui a le même nom que la base de prod)

Last edited by groot (2018-04-12 11:22:00)

Offline

#11 2018-04-12 11:22:00

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 4,084

Re: restauration de base GLPI via maintenance

comme vous avez changé de serveur, peut être que le nom de bdd ou de serveur est différent.
ceci dit, vu votre dernier message, il est plus probable que la cause soit une mauvaise restauration de bdd.


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+formcreator2.5.2 PHP7.0 Mariadb10
*GLPI 9.2.4(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.
*GLPI 9.3  en test (ubuntu 16.04 mariadb 10.2.4) (attente 9.3.1 et plugin compatible avant mise en prod)

Offline

#12 2018-04-12 11:23:48

groot
Guest
Registered: 2018-04-12
Posts: 11

Re: restauration de base GLPI via maintenance

normalement ça devrait marcher comme j'ai fait ?

Offline

#13 2018-04-12 11:31:36

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 4,084

Re: restauration de base GLPI via maintenance

je n'ai jamais utilisé les sauvegardes internes GLPI.
je l'ai toujours fait en ligne de commande mysql ( avec php my admin, on ne peut pas faire les grosses bases)

-je fais un dump de ma base
-copie de www/glpi sur mon serveur de test ( avec propriétaire www-data)
-restauration de ma base de prod sur le serveur de test ( avec creation d'un user mysql avec les droits sur la base, je n'aime pas utiliser root même en test)
-mise à jour de glpi/config_db.php ( le serveur c'est localhost donc OK mais mise à jour user, PW et nom de BDD car j'ai plusieurs versions en test et donc je ne peux pas utiliser "glpi" comme nom de bdd en test.

et ça marche à chaque fois


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+formcreator2.5.2 PHP7.0 Mariadb10
*GLPI 9.2.4(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.
*GLPI 9.3  en test (ubuntu 16.04 mariadb 10.2.4) (attente 9.3.1 et plugin compatible avant mise en prod)

Offline

#14 2018-04-12 11:38:24

groot
Guest
Registered: 2018-04-12
Posts: 11

Re: restauration de base GLPI via maintenance

Et ensuite quand tu ouvres GLPI ça marche ? y'a rien à faire ?

C'est dingue, ça ressemble fortement à ce que j'ai fait la 1ere fois avant d'utiliser le mode sauvegarde de GLPI, la différence c'est que je suis sous Windows...

tu me donner tes commandes d'export et d'import ?

Comme c'est un serveur de test j'utilise le compte root....le temps de voir que tout marche, ensuite je recommencerai en créant un user spécifique
Sachant que ma base de test s'appelle "glpi" comme ma base de prod et que le serveur c'est "localhost" je n'ai pas modifié le config_db...

Offline

#15 2018-04-12 11:41:27

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 4,084

Re: restauration de base GLPI via maintenance

le mot de passe de root c'est le même en prod et en test ?
root a les droits ALL PRIVILEGES et GRANT=OUI  sur cette base ?


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+formcreator2.5.2 PHP7.0 Mariadb10
*GLPI 9.2.4(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.
*GLPI 9.3  en test (ubuntu 16.04 mariadb 10.2.4) (attente 9.3.1 et plugin compatible avant mise en prod)

Offline

#16 2018-04-12 11:44:15

groot
Guest
Registered: 2018-04-12
Posts: 11

Re: restauration de base GLPI via maintenance

non c'est pas le même mais quand je lance l'import je tape le mdp du serveur de test

oui il a bien les droits, d'ailleurs l'import marche en partie puisque je vois tous les ordinateurs

sinon mes commandes d'export et d'import sont OK ?

Last edited by groot (2018-04-12 11:45:53)

Offline

#17 2018-04-12 11:47:10

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 4,084

Re: restauration de base GLPI via maintenance

vérifiez la table glpi_logs
avez vous d'autres table après ?
sur le serveur de test est elle crashée ?
a elle la même taille que sur la prod ?
avez vous le même nombre de tables en prod et en test ?


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+formcreator2.5.2 PHP7.0 Mariadb10
*GLPI 9.2.4(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.
*GLPI 9.3  en test (ubuntu 16.04 mariadb 10.2.4) (attente 9.3.1 et plugin compatible avant mise en prod)

Offline

#18 2018-04-12 11:52:57

groot
Guest
Registered: 2018-04-12
Posts: 11

Re: restauration de base GLPI via maintenance

LaDenrée wrote:

vérifiez la table glpi_logs
avez vous d'autres table après ?

Oui j'en ai d'autres après

LaDenrée wrote:

sur le serveur de test est elle crashée ?

Comment voir ça ?

LaDenrée wrote:

a elle la même taille que sur la prod ?

Oui d'ailleurs elle est énorme, 2Go

LaDenrée wrote:

avez vous le même nombre de tables en prod et en test ?

Oui 317 des 2 cotés

Offline

#19 2018-04-12 11:53:19

rreglpimc
Guest
Registered: 2018-02-09
Posts: 8

Re: restauration de base GLPI via maintenance

à toute fin utile, les commande que j'utilise :

Dump (automatisé) :
mysqldump --defaults-extra-file=x:\chemin\ctrm-log.cnf --single-transaction -v --databases glpi > \\serveur\partage\GLPI\BK_PRD_GLPI_YYYYMMDD.sql

- le fichier ctrm-log.cnf contient en fait le login/mdp permettant la connexion sur la base et est sécurisé pour n'être accessible que par le user qui exécute l'action.
- le YYYYMMDD à la fin du nom de fichier est dynamique dans mon cas

Restauration (non automatisée) :
mysql -u root -p glpi < \\serveur\partage\GLPI\BK_PRD_GLPI_YYYYMMDD.sql

Reparation DB :
mysqlcheck -u root -p -r -A

NB : j'ai la même conf en prod et en test, les 2 serveurs étant sur des réseaux séparés, il n'y a pas de conflits.

Offline

#20 2018-04-12 12:00:28

groot
Guest
Registered: 2018-04-12
Posts: 11

Re: restauration de base GLPI via maintenance

Bon je vais refaire un serveur et recommencer en utilisant tes commandes (sauf le fichier des mots de passe car je n'automatise pas le truc, je saisi le mot de passe de façon interactive)...ça fera que 3 fois que je recommence smile

J'aimerais éviter de faire un clone de mon serveur, non seulement pour comprendre pourquoi l'import ne marche pas mais, mais également pour pouvoir installer un serveur 2016 au lieu d'un 2012


Tu as modifié les valeurs upload_max_files, memory_limit et post_max_size dans le php.ini ?

Last edited by groot (2018-04-12 12:07:59)

Offline

#21 2018-04-12 13:44:32

rreglpimc
Guest
Registered: 2018-02-09
Posts: 8

Re: restauration de base GLPI via maintenance

j'avais touché au param memory limit du php.ini durant mes premier essais mais actuellement mon glpi fonctionne avec les valeurs par défaut.
j'avais également purger à la main la table  glpi.glpi_logs  (en conservant les 3 derniers mois) et cela avait allégé ma base.

Offline

#22 2018-04-12 13:53:33

groot
Guest
Registered: 2018-04-12
Posts: 11

Re: restauration de base GLPI via maintenance

rreglpimc wrote:

j'avais touché au param memory limit du php.ini durant mes premier essais mais actuellement mon glpi fonctionne avec les valeurs par défaut.
j'avais également purger à la main la table  glpi.glpi_logs  (en conservant les 3 derniers mois) et cela avait allégé ma base.


ok merci

Offline

#23 2018-04-12 14:35:07

groot
Guest
Registered: 2018-04-12
Posts: 11

Re: restauration de base GLPI via maintenance

Avant de tout casser, j'ai refait un export/import en ligne de commande, l'export a mis 10min, l'import 2h et cette fois ça a marché ....!
Je comprends pas...je vais essayer de recommencer avec un serveur 2016, en tout cas merci beaucoup pour votre aide

Offline

Board footer

Powered by FluxBB