Forum GestSup

Bonjour,

Je me suis retrouvé plus ou moins en charge (plus que moins à l'heure actuelle) du suivi du parc informatique de mon lycée.
Il m'incombe de remonter les problèmes aux personnes compétentes afin de régler tous les soucis rencontrés par mes collègues (130 !) sur pas loin de 600 postes ...

La seule façon de structurer un peu la chose m'a semblé être la mise en place de la solution Gestsup.
Et cela fonctionne merveilleusement bien depuis un an !

Mais, de ma petite bidouille sur un vieux pc qui traîné dans les placards, j'aimerai désormais passé à quelque chose d'un peu plus sérieux (serveur virtualisé dans mon cas sous proxmox).

Et je commence à bloquer, mes essais n'étant pas concluant (et pour cause ... je n'arrive à rien) et mes compétences / connaissances un chouïa limitées.

Mon actuel serveur (linux) est sous php 7.3, est vieux et n'est pas sauvegardé.

J'ai donc préparé un serveur linux avec gestsup 3.2.15 et php 7.4 de façon à y effectuer une restauration.

Et c'est à partir de cet instant que tout s'embrouille :

- j'ai bien une sauvegarde obtenue via l'interface
2022_02_23_15_11_37_backup_gestsup_3.2.17_e39e46e77e9907eb74e97db912d5293fe5129491c5b1f971ffe21c1ff0d8b235.zip

- j'ai bien accès à phpmyadmin

- j'ai bien essayé de suivre la documentation ...

mais je ne vois pas quel fichier utilisé dans ce .zip.

Après décompression, j'y trouve un dossier _SQL mais il y a pléthore de fichier .sql.

Si quelqu'un pouvait m'orienter, ce ne serait pas de refus.

Merci

Bonjour,

il vous faut recopier l'ensemble des fichiers de l'ancien serveur sur le nouveau.
Puis au niveau base de données, faite un export depuis le vieux serveur avec PhpMyAdmin, et réalisé un import sur le nouveau serveur.

Cdt

Bonjour,

Les fichier .sql dans le dossier _SQL correspondent aux fichiers SQL permettant d'effectuer les mises à jour. Cela n'a donc rien à voir.

Lors de la sauvegarde, un fichier terminant par .sql.gz est généré - celui-ci permet de restaurer la base de données.

Ainsi: Cette commande sauvegarde la base de données. Ces commandes sauvegardent le site web. Cette commande compresse les fichiers du site web et le backup de la base de données en un seul.

On se retrouve donc avec plusieurs fichiers dans l'archive .zip situé dans /backup permettant la restauration : celui nommé selon la date se terminant par .sql.gz correspondant à la base de données, et les fichiers correspondant au site web.
Ainsi, pour restaurer, il faut dézipper le fichier .zip (qui est une archive) dans l'emplacement du serveur web (/war/www/html/ par défaut), extraire le fichier .sql.gz et exécuter le fichier .sql qui en sort dans la base de données :
deux moyens sont possibles, soit par phpmyadmin soit par ligne de commande.

Bonsoir et merci pour le coup de main.

Vous me dites si je fais une erreur de compréhension quelque part :

J'ai essayé de décrypter car j'avais qq soucis avec l'ordre des commandes proposées et j'en ai conclus qu'il me fallait créer en premier lieu un dossier /backup et ensuite un autre dossier /temp/backup.

Puis, la commande : va me créer le fameux .sql.gz dans le dossier /temp/backup (il y est bien, avec sa date du jour en guise de nom).

Ensuite : va me faire la copie de l'intégralité du dossier /var/www/html et la coller dans le dossier /temp/backup

Et là, je me retrouve avec le .sql.gz et la copie de /var/www/html dans le même dossier à savoir /temp/backup.

Enfin, le contenu de /temp/backup sera compressé au format zip dans le dossier /backup sous l'appellation backup_gs_datedelacopie.zip

A ce stade, c'est bon, j'ai bien mon backup_gs_2022-02-23.zip dans /backup
Ouf ! Ça commence à être un poil plus limpide.

Reste maintenant à utiliser tout cela convenablement. Il me reste à récupérer le zip et à le placer sur le nouveau serveur pour poursuivre. Ce sera pour demain.

Mais en tout cas, à mon niveau, je ne trouve pas la documentation super explicite à ce sujet. Autant, pour l'installation, c'était fluide, autant pour la sauvegarde et la restauration, je m'arrache les quelques cheveux qu'il me reste.
Et je n'arrive toujours pas à comprendre le rôle de la sauvegarde effectuée via l'interface web en administrateur.

Merci bien,
Franck

Bonjour,

Le rôle de la fonction sauvegarde disponible dans l'application est de télécharger une sauvegarde compressée de l'application, contenant a la fois les fichiers et la base de données.

Cdt

Flox a écrit : ↑jeu. 24 févr. 2022 09:22 Bonjour,

Le rôle de la fonction sauvegarde disponible dans l'application est de télécharger une sauvegarde compressée de l'application, contenant a la fois les fichiers et la base de données.

Cdt

Bonjour,

Ok mais la question est alors de savoir comment l'utiliser ! Ce n'est pas de la mauvaise volonté de ma part.
La documentation à ce sujet n'est pas très explicite.
Quand j'aurai vu une fois la méthode, ce sera bon. Mais pour le moment, les quelques infos présentes sur cette partie de la documentation restent plus qu'obscures.

Je poursuis ce soir.
Franck

La procédure est a adapter en fonction de votre environnement serveur.

Sur le principe :
1- télécharger la sauvegarde depuis l'application
2- extraire les fichiers
3- transférer les fichiers sur le nouveau serveur
4- importer la base de données sur le nouveau serveur via le fichier présent dans le dossier /_SQL

La documentation à été mis à jour, je vous laisserai voir si cela est plus claire pour vous :
https://doc.gestsup.fr/backup/#restaura ... lete-linux

Bonjour,

j'ai suivi la nouvelle documentation mais ça coince encore.

Dans un premier temps, j'ai transféré les fichiers vers le nouveau serveur avec filezilla.

Ensuite, connexion à ip_nouveau_serveur/phpmyadmin

Puis bsup et importer.
J'ai sélectionné dans le dossier _SQL le fichier nommé

2022_02_23_15_11_37-backup-gestsup-3.2.17-e39e46e77e9907eb74e97db912d5293fe5129491c5b1f971ffe21c1ff0d8b235.sql

et finalisé l'importation.

Le nouveau serveur me dit :

Erreur

Requête SQL : Copier

CREATE TABLE `tauth_attempts` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`date` datetime NOT NULL,
`ip` varchar(40) NOT NULL,
`attempts` int(10) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

MySQL a répondu :
#1050 - La table 'tauth_attempts' existe déjà

A partir de là, je ne peux plus me connecter à l'interface web.
J'obtiens quelque soit le pc client le message :

Error : SQLSTATE[HY000] [1045] Access denied for user 'gestsup'@'localhost' (using password: YES)

Je pense avoir progressé mais ce n'est pas encore fonctionnel. Dommage, j'y croyais !

Franck

Par acquis de conscience, je viens de supprimer bsup et ré-importer.

Je retrouve bien mes 'users'.

Cette fois-ci, plus d'erreur lors de l'importation mais l'interface reste injoignable.

Il ne doit plus manquer grand chose ! Peut-être un service à relancer ?

Franck