You are not logged in.
Bonjour,
j'ai le même problème d'arrêt en cours de dump.
le problème a été contourné en vidant la table glpi_logs
le message est accès non autorisé sur c:inetpubwwwrootglpi/_files/...
effectivement, il manque les "/"
glpi 0.84 - IIS 7 - Php 5.3.10 - Mysql 5.5.23
Offline
J'ai exactement le même soucis.
Avez-vous pu trouver une solution?
Mon environnement:
IIS 6.0
PHP 5.4.25 (NTS, VC9) en mode Fast-CGI avec Wincache 1.3.4.0
MySQL Server 5.6.16
Offline
Bonjour,
Problème identique sur poste W7 avec wamps 2.4.2, php 5.4.3, sql 5.5.24, la sauvegarde sql s'arrête à 67% avec le message "Accès non autorisé au fichier d:wampwwwglpi/files/_dump/glpi-0.84.5-2014-03-21-09-27.sql
Je suis sous glpi 0.84.5 avec fusion agent 2.3.5
Ce problème de sauvegarde de la base est apparu après la mise à jour de glpi. J'ai vidé la table glpi_logs et le saoucis persiste sauf qu'avant de vider cette table, la sauvegarde s'arrêtait à 31% alors que maintenant elle s'arrête à 67%.
Avez vous une solution afin de régler ce problème.
Merci d'avance
Offline
Pour compléter mon post précédent, je précise que la mise à jour vers la 0.84.5 s'est déroulée sans problème. J'ai vérifier les logs et tout est OK. Le problème vient donc d'ailleurs. Il est bizarre que les / n'apparaissent pas dans d:wampwwwglpi.
Offline
Bonjour,
Je me permets de rajouter un commentaire pour savoir si une solution a été trouvé ou non.
J'ai moi aussi le même problème.
Merci d'avance
Offline
On n'est pas arrivé à reproduire le soucis
Offline
En vidant la table glpi_crontasklogs, la sauvegarde a fonctionné.
Offline
J'ai vidé la table glpi_crontasklogs et glpi_logs sans aucun résultat
Même problème depuis la remonté des agents fusioninventory.
Offline
Bonjour
En vidant les 2 tables glpi_crontasklogs et glpi_logs, la sauvegarde a fonctionnee
Offline
pas moi... je sais pas ou aller chercher
avec un parc de plus de 1000 postes et pour l'instant une remontée de 250 postes, j'ai les tables logiciel et versions qui sont très importante... est-ce le problème ???
Offline
Si t'as 1000 posts, utilises plutot la commande mysqldump pour la sauvegarde de ta base MySQL
Offline
bonjour,
je viens de faire la sauvegarde qui plantait très vite, à moins de 10%. J'ai suivi les conseils cités plus haut et ai vidé les tables glpi_crontasklogs et glpi_logs .
la sauvegarde a bien fonctionner par la suite. Et je suis passé d'un fichier de 65 Mo à 9 Mo. Comme quoi les logs, ça prend de la place.
serveur 2008 R2 , wamp 2.2., glpi 0.84.3 (maintenant en 0.84.6)
Bien à vous.
Offline
Bonjour,
Même problème (arrêt à 44%), même punition... heu solution !
Vidage partiel de glpi_logs avec phpMyAdmin :
DELETE FROM `glpi_logs` WHERE `date_mod` < "2013-09-01 08:00:00"
et ça passe.
Cordialement.
Windows Server 2008 R2 Entreprise, IIS 7.5, Php 5.5.14, MySQL 5.6.19, GLPI 0.84.6
Offline
Bonjour j'ai le même problême : arrêt de la sauvegarde à 29 %
Accès non autorisé au fichier C:wampwwwglpi/files/_dumps/glpi-0.84.7-2014-08-22-10-41.sql.gz
•Apache/2.4.9 (Win32) PHP/5.5.12
Glpi 0.84.7
wamp server 2.5
j'ai vidé partielllement la table des log et completement celle des crontasklog mais le problème est toujours là.
quelqu'un a t'il une solution ?
Merci d'avance.
Offline
Idem
Même message
Xamp Glpi 0.84.5
Avez vous une idée.
Merci d'avance
GLPI 10.0.11 Copyright (C) 2015-2023 Teclib' and contributors
Debian Linux 10
Apache version 2.4.38
PHP 8.3
Offline
Re-Bonjour
Purge logs <01/01/2014 OK taille backup 17M0 avant plantage à 19 M0
Si ces infos peuvent vous aider.
GLPI 10.0.11 Copyright (C) 2015-2023 Teclib' and contributors
Debian Linux 10
Apache version 2.4.38
PHP 8.3
Offline
Si votre base est trop grosse, il faut passer par un script avec mysqldump à lancer sur le système
Offline
Bonjour,
J'ai le même problème de blocage de sauvegarde de la base SQL (elle s’arrête à 35%), mais avant de vider les tables de glpi_logs et glpi_crontasklogs j'aimerais avoir une idée sur les conséquences de cette action.
Merci d'avance
Glpi 0.84.70 Sous Linux Ubuntu et Xampp 1.8.3-2
Offline
Ta version de GLPI est également 0.84 ?
(Tu déterres du vieux post là...)
Last edited by Bikarfioul (2015-01-13 17:07:00)
GLPI 0.85.1 / Plugins Fusion : 085+1 / Agent : 2.3.14 < Serveur Centos 64 Bits>
Offline
glpi_logs corresponds à l'historique de toute les actions menées dans GLPI. (Modification de Ticket, de droits, ...) C'est ce que tu retrouve dans l'onglet Historique de l'élément GLPI que tu consultes.
glpi_crontasklogs corresponds à l'historique de toute les actions menées par les actions automatisées.
Les 2 tables ne servent pas vraiment, mais si tu es comme moi un chercheur de qui à fait quoi elles te sont utiles.
GLPI 0.85.1 / Plugins Fusion : 085+1 / Agent : 2.3.14 < Serveur Centos 64 Bits>
Offline
Ta version de GLPI est également 0.84 ?
(Tu déterres du vieux post là...)
J'ai la version 0.84.70. Si je suis aller chercher dans les abysses du forum c'est pour ne pas créer de doublons ...
Glpi 0.84.70 Sous Linux Ubuntu et Xampp 1.8.3-2
Offline
glpi_logs corresponds à l'historique de toute les actions menées dans GLPI. (Modification de Ticket, de droits, ...) C'est ce que tu retrouve dans l'onglet Historique de l'élément GLPI que tu consultes.
glpi_crontasklogs corresponds à l'historique de toute les actions menées par les actions automatisées.
Les 2 tables ne servent pas vraiment, mais si tu es comme moi un chercheur de qui à fait quoi elles te sont utiles.
Je ne cherche pas vraiment, mais parfois on me demande de voir qui a fait quoi. Du coup, je me tâte un peu a vider ces tables. Mais s'il n'y a pas d'autres moyens, je vais devoir le faire pour a voir une sauvegarde en cas de pépin.
Merci pour ta réponse.
Glpi 0.84.70 Sous Linux Ubuntu et Xampp 1.8.3-2
Offline
Tu peux également supprimer directement en base avec une commande du style
SELECT count(*) FROM glpi.glpi_logs where date_mod <= CURRENT_DATE - INTERVAL 450 DAY
Pour compter le nombre de lignes impactées, le 450 étant le nombre de jour que tu souhaites garder.
DELETE FROM glpi.glpi_logs where date_mod <= CURRENT_DATE - INTERVAL 450 DAY
Pour effectuer la suppression des lignes.
Mais je ne sais pas si la tâche automatisé optimize n'effectue pas un ménage équivalent.
Last edited by Bikarfioul (2015-01-13 18:02:13)
GLPI 0.85.1 / Plugins Fusion : 085+1 / Agent : 2.3.14 < Serveur Centos 64 Bits>
Offline
Merci Bikarfioul. En supprimant les logs et ne laissant que 40 jours, la sauvegarde s'est enfin faite.
Glpi 0.84.70 Sous Linux Ubuntu et Xampp 1.8.3-2
Offline
Bonjour,
J'ai le même problème pendant la sauvegarde sql:
"Accès non autorisé au fichier C:Program Files (x86)Apache Software FoundationApache2.2htdocsglpi/files/_dumps/glpi-0.84.7-2015-02-05-15-22.sql.gz"
J'aimerais pouvoir purger les tables glpi_crontasklogs et glpi_logs comme le préconisent certain. Seulement je suis sur windows ( je ne peut donc pas utiliser les commandes données ci et la). Si quelqu'un peut me dire où je peut trouver ces tables et comment les purger, merci d'avance (dans mon dossier glpi/files/_logs il n'y a que cron.log mail.log et php-erros.log).
Je souligne que ce problème de sauvegarde existe depuis le passage à la version 0.84, étant donné que la 0.85 existe je serais tenté de faire une mis à jour malheureusement j'aimerais pouvoir sauvegarder la base de donnée avant la maj. Si quelqu'un à une solution, merci d'avance.
Cordialement,
Last edited by abmignot (2015-02-12 11:48:33)
Offline