You are not logged in.
Pages: 1
Topic closed
Bonjour,
Je rencontre un soucis de disque dur saturé lors de la restauration d'une ancienne base sur un nouveau serveur.
J'ai installé complètement une nouvelle VM avec la dernière version d'Ubuntu, GLPI et OCS Inventory NG.
La restauration d'une ancienne base 0.83.2 vers 9.1.6 s'est bien déroulée après avoir modifié le fichier update_91_911.php.
Il posait soucis lors de la mise à jour pas à pas.
Suite à la modification de ce fichier, tout s'est bien passé, la maj pas à pas de la base a fonctionné.
Et j'ai pu utiliser mon ancienne base (non à jour car c'était pour tester) sur mon nouveau serveur sans avoir perdu de données.
J'ai configuré OCS Inventory NG et installé deux plugins (Tableau de bord & GLPI Modifications).
J'ai ensuite refait une sauvegarde sur l'ancien serveur (de production afin d'avoir la base à jour) pour la restaurer.
Et c'est là que le problème survient.
J'ai désactivé tout les plugins et ai lancé la restauration.
La barre de progression avance puis se bloque à 90% et là le disque se rempli petit à petit jusqu'à être plein
il rempli quand même les 40Go disponibles restant.
ancien serveur : VM Fedora 8 / GLPI 0.83.2 / OCS Inventory NG 2.0.5
nouveau serveur : VM Ubuntu 16.04.3 / GLPI 9.1.6 / OCS Inventory NG 2.3.1
Quelqu'un a-t-il déjà eu ce soucis? Ou une solution?
La première restauration s'est bien passée et rien n'a été modifié entre temps. Je comprends pas!
Par avance, merci de vos réponses.
Je suis novice en Linux/php/mysql mais je me débrouille...
Last edited by bdam34 (2017-09-11 15:53:01)
Offline
quel outil avez vous utilisé pour la sauvegarde/restauration?
l'outil interne GLPI ou Mysqldump/mysql ?
en ligne de commande ou via phpmyadmin ?
sur le php.ini qu'avez vous comme max memory ?
avez vous vérifié la taille de la table glpi_logs ? est elle en bon etat ?
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
Bonjour et merci de votre réponse,
Je suis passé par l'outil interne à GLPI.
Ce matin, j'ai fait un test avec mysqldump, déjà ce fut bien plus rapide.
30sec avec mysqldump contre 2h30 avec l'outil interne à GLPI.
et j'ai eu un gain de 50Mo sur la base.
J'ai déposé la base dans le dossier _dump et ai restauré depuis l'outil interne à GLPI.
C'est passé en 30sec au lieu de plusieurs minutes, j'ai mis à jour la base pas à pas, idem en quelques secondes.
Tout à été vérifié et je n'ai apparemment perdu aucunes données.
Je pense que l'outil interne à GLPI ne fonctionne pas super et qu'il vaut mieux passer par mysqldump.
Peut-on laisser le topic ouvert le temps que je passe mon serveur de test en prod? Juste au cas où?
Merci
Offline
Je pense que l'outil interne à GLPI ne fonctionne pas super et qu'il vaut mieux passer par mysqldump.
quand la base de donnée devient trop grosse, l'outil interne de sauvegarde n'est plus adapté.
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
Bonjour,
J'ai passé mon nouveau serveur en production sans soucis.
Seul hic, les éléments associés à tous mes tickets ont disparus suite à la restauration de la base.
Est-il possible de les restaurer/retrouver?
Merci.
Offline
pouvez vous comparer les table glpi_items_ticket avant et après restauration ?
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
Sur l'ancienne je n'ai pas la table glpi_items_tickets (base en 0.83).
Le soucis se pose lors de la mise a jour de la base vers la version 9.1.1.
Cela ne semble pas remplir la table glpi_items_tickets avec les informations d'éléments associés de l'ancienne base.
Last edited by bdam34 (2017-09-14 15:20:04)
Offline
Suite à l'installation de phpmyadmin j'ai constaté que les informations des éléments liés étaient bien présentes dans la table glpi_tickets.
Simplement que la nouvelle version de GLPI allait chercher les informations seulement dans la table glpi_items_tickets.
Une requête mysql INSERT INTO GLPI_ITEMS_TICKETS avec un SELECT FROM GLPI_TICKETS (seulement sur les 3 colonnes qui m'intéressait) a résolu mon problème.
ticket à clore de ce fait!
Offline
Pages: 1
Topic closed