j’ai essayé le processus de restauration via le gladys plus. Cependant je n’arrive pas à restaurer les données
lorsque que j’ai créé ma nouvelle instance Gladys, j’ai choisis la restauration via le gladys plus.
1 - J’ai été étonné de trouver que des vieilles sauvegarde (7mois et plus), que j’avais certainement réalisés à la main. Il me semblait pourtant qu’il y avait une sauvegarde automatique toutes les semaines ou tous les mois. Je me suis trompé ?
2 - Je prend la sauvegarde qui était la plus récente, je laisse tourner et après plusieurs minutes je m’aperçois que le container est arrêté. Il n’a pas redémarré tout seul. Peut-être un problème car j’utilise docker sur synology ?
3 - Je redémarre le docker manuellement, je me connecte sur l’url, et là je suis déjà connecté avec un 'temp-user". Je me déconnecte, mais impossible de reconnecter avec mon login/pasword. J’ai tenté un ancien en me disant que depuis 7 mois j’avais surement changé le mot de passe. En vain aussi.
La sauvegarde est quotidienne! Etais-tu sur que tes sauvegardes fonctionnaient sur ton instance? Tu peux regarder dans l’onglet « Backups » des settings sur l’ancienne instance?
Ah mince, effectivement ton container doit être en restart=always, car la seule façon de redémarrer Gladys est de stopper Gladys volontairement pour que docker relance Gladys. Tu es le premier à tester sur Synology !
Cela veut dire que la restauration n’a pas marchée. Quand tu restaure, Gladys créé un « temp-user » en DB qui restaure ton backup Gladys, qui est écrasée juste après vu que la DB entière est écrasée par la restauration.
Je suis allé voir côté Gladys Plus, effectivement tu n’as que 5 backups à ces dates là:
Je ne sais pas d’ou venait ces backups (Syno? Raspberry Pi?) peut-être sur les backups sur Synology ne fonctionnent pas, tu es le premier à tester je t’avoue, je n’ai pas de synology pour ma part! Si tu as des logs, ça m’intéresse pour améliorer le produit sur Synology.
Malheureusement je n’ai plus l’ancienne version. Trop confiant sur le backup du gladys Plus, j’ai shooté ma base local lors du changement de NAS.
Tant pis pour la sauvegarde, je n’avais pas grand chose. Je vais remonter un Gladys sur le Synology et on vérifiera si les sauvegardes fonctionnent ou non.
Ensuite je pourrai tester une restauration et voir te fournir des log pour comprendre pourquoi je suis bloqué sur le temp-db.
Mince Il y a un développement prévu pour envoyer des alertes quand les backups sont en échec, mais il y a pas mal d’autres tâches plus prioritaires en ce moment.
Je suis intéressé par ton retour pour pouvoir améliorer le service
Concernant docker sur Synology si on passe par l’assistant graphique de Docker, on ne peut pas régler la fonction restart autrement que sur always. Il faut passer par une commande ssh pour avoir du unless-stopped.
Les sauvegardes ont l’air de se faire régulièrement. Je ne sais pas pourquoi elle ne se faisait pas sur mon ancienne ancienne.
Je viens de modifier le dashboard et j’ai tenté de restauré à deux jours en arrière afin de revenir en arrière et valider le bon fonctionnement de la restauration.
Le container c’est arrêté mais n’a pas redémarré tout seul (on a déjà identifié ce problème et des propositions ont été mis en avant, je n’ai pas testé). J’ai donc redémarré le container à la main, mais en retournant sur Gladys je n’ai pas retrouvé l’affichage que j’attendais.
Voici les logs :
2020-06-13T18:55:22+0000 <info> gateway.checkIfBackupNeeded.js:27 (Gateway.checkIfBackupNeeded) Not backing up instance to Gladys Gateway, last backup is recent. stdout
20:55:23 2020-06-13T20:55:23+0000 <info> gateway.checkIfBackupNeeded.js:27 (Gateway.checkIfBackupNeeded) Not backing up instance to Gladys Gateway, last backup is recent. stdout
21:03:53 2020-06-13T21:03:53+0000 <info> gateway.restoreBackupEvent.js:15 (Gateway.restoreBackupEvent) Receiving restore backup event. File url = https://gladys-gateway-backup.fra1.digitaloceanspaces.com/4c852ac6-084a-469a-b9a3-f19a42ed5f06.enc stdout
21:03:53 2020-06-13T21:03:53+0000 <info> gateway.downloadBackup.js:45 (Gateway.downloadBackup) Gladys backup downloaded with success. stdout
21:03:53 2020-06-13T21:03:53+0000 <info> gateway.restoreBackup.js:13 (Gateway.restoreBackup) Restoring back up /var/lib/gladysassistant/backups/restore/4c852ac6-084a-469a-b9a3-f19a42ed5f06.db stdout
21:03:53 2020-06-13T21:03:53+0000 <info> gateway.restoreBackup.js:24 (Gateway.restoreBackup) Backup restored. Need reboot now. stdout
21:05:46 stdout
21:05:46 > gladys-server@ start:prod /src/server stdout
21:05:46 > cross-env NODE_ENV=production node index.js stdout
21:05:46 stdout
21:05:58 2020-06-13T21:05:58+0000 <info> system.init.js:31 (System.init) System.init: This system doesn't have a docker dameon available. stdout
21:06:01 Initialising OpenZWave 1.6.1051 binary addon for Node.JS. stdout
21:06:01 OpenZWave Security API is ENABLED stdout
21:06:01 ZWave device db : /usr/local/etc/openzwave stdout
21:06:01 User settings path : /src/server/services/zwave/node_modules/openzwave-shared/build/Release/../../ stdout
21:06:01 Option Overrides : --Logging false --ConsoleOutput false --SaveConfiguration true stdout
21:06:02 2020-06-13T21:06:02+0000 <info> index.js:20 (Object.start) Starting Dark Sky service stdout
21:06:02 2020-06-13T21:06:02+0000 <info> index.js:19 (Object.start) Starting telegram service stdout
21:06:02 2020-06-13T21:06:02+0000 <info> index.js:13 (Object.start) Starting usb service stdout
21:06:02 2020-06-13T21:06:02+0000 <info> index.js:16 (Object.start) Starting zwave service stdout
21:06:02 2020-06-13T21:06:02+0000 <info> service.start.js:16 (Service.start) Service telegram is not configured, so it was not started. stdout
21:06:02 2020-06-13T21:06:02+0000 <info> service.start.js:16 (Service.start) Service zwave is not configured, so it was not started. stdout
21:06:02 2020-06-13T21:06:02+0000 <info> service.start.js:16 (Service.start) Service mqtt is not configured, so it was not started. stdout
21:06:02 2020-06-13T21:06:02+0000 <info> index.js:63 (Server.<anonymous>) Server listening on port 8080 stdout
21:06:03 2020-06-13T21:06:03+0000 <info> index.js:743 (Socket.<anonymous>) Gladys Gateway: connected in websockets stdout
21:06:03 2020-06-13T21:06:03+0000 <info> gateway.checkIfBackupNeeded.js:27 (Gateway.checkIfBackupNeeded) Not backing up instance to Gladys Gateway, last backup is recent.
je n’ai pas encore vérifié mon fichier avant/après restauration sur le synology.
Comme ca ne semble pas fonctionner avec le synology j’ai tenté de restaurer sur une pi. J’ai donc installé une instance de gladys et ensuite j’ai connecté le gladys Plus. J’ai une nouvelle clef de chiffrement qui a été générée. J’ai lancé la restauration d’une sauvegarde. Aie ! ca ne fonctionne pas. Les logs il m’indique que la clef utilisée n’est pas la bonne.
2020-06-26T18:33:54+0200 gateway.restoreBackupEvent.js:20 (Gateway.restoreBackupEvent) Error: Command failed: openssl enc -aes-256-cbc -pass pass:ea4244f9f37ff6fa7a46dbadf73c3c31ead77f02be89e792298c636d7561b927 -d -in /var/lib/gladysassistant/backups/restore/b1c3d1de-e277-4ba3-b6f7-a7ffa4f64fd3.enc -out /var/lib/gladysassistant/backups/restore/b1c3d1de-e277-4ba3-b6f7-a7ffa4f64fd3.db.gz
*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.
bad decrypt
1995588952:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:588:
at ChildProcess.exithandler (child_process.js:303:12)
at ChildProcess.emit (events.js:315:20)
at maybeClose (internal/child_process.js:1021:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:286:5) {
Alors il y a 2 façons de faire une restauration dans Gladys 4:
A l’installation, en sélectionnant « Restaurer un backup »
J’avais décris la procédure dans ce post =>
Ou directement depuis une instance existante, dans les paramètres de Gladys
Je suppose que tu as fais la restauration avec la procédure 2), et effectivement si tu essaie de restaurer un backup d’une ancienne instance sans avoir au préalable mis la clé de restauration de l’ancienne instance, ça échoue car la clé n’est pas la même !
Il faut que soit tu passe par la procédure 1), soit que tu mette la clé de restauration dans la nouvelle instance avant de faire la restauration (le champ est éditable)
Je suis d’accord que l’UX de la procédure 2) est pas super, je l’avais fais au début et je ne l’ai pas encore adapté suite au développement de la procédure 1) qui n’est normalement bien plus claire
Oui effectivement j’avais pas pensé à changer le clef par celle d’origine. Quelques explications dans l’UX afin d’accompagner l’utilisateur serait les bienvenues.
Après coup ca me semble logique de mettre la clef d’origine, mais un petit mémo dans l’interface éviterait des erreurs bêtes comme la mienne.
Il y a un développement prévu pour envoyer des alertes quand les backups sont en échec, mais il y a pas mal d’autres tâches plus prioritaires en ce moment.
