J’essayais de migrer dans docker et de restaurer ma sauvegarde sans succès.
Je me suis obstiné, déployé avec les différentes solutions proposé, j’ai refais des sauvegardes au cas ou (j’ai fais les vérifications système avant ma dernière sauvegarde au cas ou)…
Finalement je me suis dis c’est peut-être docker et j’ai créé une vm dans proxmox mais j’ai toujours le même problème.
[START RESTORE]
***************Begin Jeedom restore 2024-09-20 09:49:44***************
Send begin restore event...OK
Checking rights...
OK
Restore from file : /var/www/html/core/class/../../backup/backup-MyHome-4.4.17-2024-09-20-09h06.tar.gz
Backup database access configuration...OK
Disable all task OK
Disable all scenario OK
Unpacking backup...
OK
Update composer file...
La restauration se lance puis reste planté sur Update composer file..., y aurait-il moyen de faire du debug ?
Quand je raffraichi la page j’ai le message suivant : [MySQL] Error code : 42S02 (1146). Table 'jeedom.config' doesn't exist : SELECT key,valueFROM config WHEREkey IN ('language') AND plugin=:plugin
Je suis en version Jeedom 4.4.17
En écrivant la ligne du dessus, je me dis que je suis en Debian 12.5.
Du coup je refais l’installation en Debian 11.11… et je reviens vers vous au cas ou.
J’ai recemment passé ma dev sur debian 12 avec une clean install et une restauration. J’ai souvenir avoir eu le même souci de présentation : impression que la restauration ne progressait plus. C’est en allant voir la log « restore » que je me suis aperçu que la restauration était alléé au bout.
J’ai aussi eu ce comportement avec la Debian 11, j’ai eu un message furtif d’une erreur 401.
Lorsque je me suis réidentifié avec mon compte utilisateur présent dans la sauvegarde c’était bon.
La ce qui m’étonne c’est que rien ne se passe alors que j’ai laissé tourné plus d’une heure… C’est pour ça que je me dis qu’il y a peut-être une log ou autre indiquant ce qui bloque.
Je constate qu’il n’y a pas de table dans la base :
Bonjour, même soucis de restauration d’un jeedom 4.4.17 sur un Debian 12 (sauvegarde faite sur Debian 11)
Bloqué sur « Update composer file… » depuis 3h…
Je n’ai pas encore trouvé la solution mais pour moi c’est un problème de sauvegarde.
J’ai restauré une sauvegarde du mois d’août et ça fonctionne.
Pour le moment ça passe jusqu’au 18/09 et ça échoue dès le 19/09.
Il faut que je compare ce qui change dans la sauvegarde ce qui peut être long…
Sinon je vais restaurer au 18/09 et perdre juste 2 jours de données…
En revanche dans certains cas l’écran ne rafraîchi pas mais la restauration a bien fonctionné et c’est visible dans la log restore
Forcement je n’ai pas eu le temps de tout comparer mais j’ai une piste sur la version de MariaDB (j’ai fais une mise à jour du système !)
Dans le backup d’aujourd’hui, j’ai le fichier DB_backup.sql je constate que j’ai pas la même version de MariaDb mais j’ai cette ligne en début de fichier que je n’ai pas dans la version qui fonctionne /*M!999999\- enable the sandbox mode */
Version KO
/*M!999999\- enable the sandbox mode */
-- MariaDB dump 10.19 Distrib 10.5.26-MariaDB, for debian-linux-gnu (x86_64)
--
-- Host: localhost Database: jeedom
-- ------------------------------------------------------
-- Server version 10.5.26-MariaDB-0+deb11u2
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
Version OK
-- MariaDB dump 10.19 Distrib 10.5.23-MariaDB, for debian-linux-gnu (x86_64)
--
-- Host: localhost Database: jeedom
-- ------------------------------------------------------
-- Server version 10.5.23-MariaDB-0+deb11u1
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
J’essaye de continuer mes recherches et faire un retour dès que j’ai du concret (pour le moment j’ai pas été plus loin).
Sur ma prod (Debian 11) qui a généré les backup j’ai la version : mariadb Ver 15.1 Distrib 10.5.26-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper
Dans le container j’ai la version : mariadb Ver 15.1 Distrib 10.11.6-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper
Merci pour le partage, pour le moment je suis un peu perdu, j’avais déjà supprimé la première ligne du fichier mais j’ai toujours le même comportement…
J’espère qu’un correctif arrivera prochainement pour que mes sauvegardes puissent être réutilisée.
Je n’ose pas recharger une sauvegarde en prod de peur que ça me plante le serveur pour le week-end.
Du coup il faut que j’attende que la version de mariaDB passe en 10.11.8 car je suis en 10.11.6
J’imagine que pour Docker, il faut que l’image intègre la bonne version.
Pour le moment je n’ai pas de mise à jour de proposé sous Debian 12 :
$sudo apt-get -y update && sudo apt-get -y upgrade && sudo apt-get -y dist-upgrade && sudo apt-get -y auto-clean && sudo apt-get -y autoremove
Hit:1 http://security.debian.org/debian-security bookworm-security InRelease
Hit:2 http://deb.debian.org/debian bookworm InRelease
Hit:3 http://deb.debian.org/debian bookworm-updates InRelease
Hit:4 https://deb.nodesource.com/node_20.x nodistro InRelease
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
$mariadb --version
mariadb Ver 15.1 Distrib 10.11.6-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper
Encore merci pour ton aide, ça devrait rentrer dans l’ordre bientôt. C’est mal tombé au moment ou je voulais tester dans docker a 2 jours prêt j’aurais rien vu.
Un truc m’échappe, j’ai installé un Jeedom tout neuf sur un Debian 12 toute neuve aussi.
J’ai fait une sauvegarde avant d’injecter la mienne pour la restaurer et la sauvegarde du Jeedom vierge fait 83 Mo, la sauvegarde de mon Jeedom de production fait 73 Mo.
Si vous avez des idées (je flippe) en attendant un correctif.
Pour info la dernière alpha supprime cette ligne qu’ils rajoutent et fait tout planter. A tester car j’ai pas cette version de mariadb dans mes jeedoms de tests
Est-il possible de tester cette correction sans passer par la version alpha ?
Mon problème c’est que j’ai uniquement en prod ce comportement et je ne souhaite pas trop passer sur une alpha en prod.
Les versions ou je souhaitais restaurer ma sauvegarde de prod n’ont pas ces versions.
Bonjour,
Oui il suffit de reprendre la modification que j’ai faite (c’est une ligne) et de le mettre directement sur ton jeedom. Les modifications sont sur le repo core du GitHub
Hello, merci Loic
J’ai récupéré le restore.php sur GitHub core alpha que j’ai remplacé sur mon jeedom « vierge » debian12 d’une VM
La restauration est bien allé jusqu’au bout après plusieurs essais infructueux avant la modification:
0088|Restore duration : 64s
0089|Jeedom Restore End
0090|[END RESTORE SUCCESS]
super !
J’ai testé sur mes 2 environnements de test (docker et vm). Ma sauvegarde de production se restaure bien.
PS : j’ai compris en voyant le code que j’avais pas besoin de modifié ma prod.
La version corrigé en alpha exclue la ligne /*M!999999\- enable the sandbox mode */ si elle est présente lors de la restauration.
Encore Merci Loic. Tu nous fais ça le dimanche c’est vraiment trop trop sympa de ta part.
a 2 jours prêt j’aurais rien vu.