Bonjour,
suite à un problème entre le MQTT et Z2M, par facilité j’ai lancé une restauration, et cela dure encore (plus de 9h sur un Beelink). Est-ce normal (je suppose que non )
D’avance merci pour une solution
Bonjour,
suite à un problème entre le MQTT et Z2M, par facilité j’ai lancé une restauration, et cela dure encore (plus de 9h sur un Beelink). Est-ce normal (je suppose que non )
D’avance merci pour une solution
La restauration est en générale très rapide
À la fin de la restauration, Gladys doit normalement redémarrer, donc elle se coupe puis docker est censé la relancer (si tu es bien en restart=always dans ta config)
Possible que cette phase n’a pas bien eu lieu, tu peux faire un :
docker restart gladys
Sinon regarde les logs de gladys pour avoir plus d’informations !
Je regarde ça dès que je rentre.
Merci pour ta réponse rapide @pierre-gilles
J’ai fait un docker restart gladys
et j’ai bien récupéré ma configuration.
J’ai fais un docker inspect gladys
et tout semble conforme :
Par contre, les données de l’ensemble de mes graphiques n’ont pas été restaurées (absence de métriques d’avant le redémarrage de Gladys).
Faut-il réeffectuer une nouvelle restauration ou effectuer des controles avant ?
Et pour les logs, j’ai une récurrence de Error while connecting to MQTT - Error: Connection refused: Not authorized
D’avance merci pour toutes aides
Tu as restauré une sauvegarde qui date de quelle date ?
Si tu as restauré une sauvegarde qui date d’avant DuckDB ( Gladys Assistant 4.45 : DuckDB, une révolution dans Gladys ! ⚡ ), alors il faut que ton instance refasse la migration vers DuckDB en local et ensuite tu récupèreras les données historiques.
Sinon, tu peux regarder les logs de la restauration et voir si tout s’est bien passé (remonte dans tes logs Gladys, tu devrais l’avoir)
Autre possibilité: refaire une restauration et regarder en live les logs pour vérifier que tout se passe bien Peut-être qu’il y a un cas particulier dans ta donnée historique qui fait échouer la restauration de celles-ci.
Tu utilises l’intégration MQTT via le container Docker lancé par Gladys ou que tu as lancé manuellement ?
Il est possible que tu doives relancer l’intégration, normalement elle est censé retomber sur ces pattes en cas de restauration (relancer toute seule le container si tu utilises le container lancé par Gladys), mais peut-être que dans ton cas ça n’a pas fonctionné.
Après au vu de tout ce que tu rencontres, il est possible que la restauration ait été un échec dans ton cas, les logs nous diront d’avantage ce qui s’est passé
A la question
Tu as restauré une sauvegarde qui date de quelle date ?
C’était la sauvegarde du 21/10/2024 (données migrées)
J’ai fais quelques tests de restauration de la base du 21/10, du 19/10 et celle de juste avant ces test, voici les logs :
Suite à la restauration du 21/10
Suite à la restauration du 19/10
Suite restauration sauvegarde avant les tests de restaurationd précédents
A la question
Tu utilises l’intégration MQTT via le container Docker lancé par Gladys ou que tu as lancé manuellement ?
Oui j’utilise l’intégration MQTT via le container Docker lancé par Gladys.
Au vue des logs, il y a semble-t-il un problème lors de la restauration de la base migrée. Est-il envisageable de faire une restauration manuelle des données perdues ?
Merci beaucoup pour ton retour, j’ai investigué et c’est un bug de DuckDB, j’ai trouvé une issue Github qui parle de ce souci et apparemment ça a été corrigé dans la version 1.1 de DuckDB :
Le correctif :
Je travaille sur Gladys demain, je regarde pour mettre à jour DuckDB et ça partira dans la prochaine release !
Avec ce fix tu pourras normalement restaurer sans problèmes.
C’est tout à fait possible, mais ça demande un peu de gymnastique
Si tu vas dans le dossier /var/lib/gladysassistant/backups/restore
, tu devrais trouver un dossier « _parquet_folder », qui contient les données de capteurs au format parquet.
Si tu récupère ce dossier quelque part (sur ton ordi perso par exemple), et que tu installe DuckDB, tu peux importer ces fichiers Parquet dans un fichier .duckdb :
Ensuite il faut réimporter ce fichier dans le dossier /var/lib/gladysassistant
avec le nom gladys-production.duckdb
(ne pas oublier le wal file également).
Mais si t’es un peu patient, je vais mettre à jour DuckDB et normalement ça fixera ton souci dans la prochaine version de Gladys
Bonjour,
J’ai le même problème avec la restauration de gladysplus et souhaiterais ne pas supprimer tous les historiques du système. Normalement toutes les scènes devraient être disponibles après la prochaine release.
La question est : quand sortira-t-elle ?
Salut à tous les deux @Tolkyen et @Jluc !
J’ai travaillé sur ce sujet ce matin.
Malgré mes efforts, je n’ai pas réussi à reproduire ce bug, j’ai testé sur différents types de serveurs, et la restauration fonctionnait systématiquement chez moi.
Néanmoins, j’ai mise à jour DuckDB en 1.1.1 dans la dernière version de Gladys en espérant que cela corrige bien le souci chez vous :
Si vous refaites une restauration de Gladys, peut-être repartir d’une base « saine » serait avisée, je vous recommanderais de faire :
docker stop gladys && docker rm gladys
Supprimer tous les fichiers Gladys en faisant :
sudo rm -rf /var/lib/gladysassistant
(Attention, commande à faire que sur un environnement que vous voulez véritablement détruire, cette commande supprime tout)
Faire un pull de la dernière version de Gladys:
docker pull gladysassistant/gladys:v4
Puis relancer Gladys avec la commande du site:
Tenez moi au courant, j’espère que ça fonctionnera bien pour vous avec cette mise à jour
Bonjour,
Tout d’abord, un grand merci à toi, @pierre-gilles pour la prise en compte rapide du problème que nous rencontrons avec @Tolkyen mais aussi pour tout les conseils qui m’ont permis d’avancer dans l’installation de Gladys sur mon nouveau miniPC.
J’ai peut-être oublié quelque chose ou fait une mauvaise manipulation mais ces lignes s’affichent après avoir lancé la commande :
sudo docker run -d
Oui tu n’as pas bien lancé la première commande (docker stop / rm), on voit l’erreur, il faut que tu mette un “sudo” avant la commande
Décompose les deux commandes:
sudo docker stop gladys
sudo docker rm gladys
ça devrait marcher
Oui c’est parfait ça a fonctionné
Maintenant tu peux relancer Gladys avec le docker run du site
Normalement c’est assez rapide ! ça dépend de la vitesse de ta connexion internet
Tu peux suivre la restauration avec:
docker logs gladys
Les logs que tu montres sont tout à fait normales, je ne vois pas le souci
Regarde plutôt la fin des logs, pas le début