NEWS
Probleme bei ioBroker-Umzug mit backup/restore
-
@F-A-L
Wieder viel Text!Ich habe bei den hunderten Posts pro Tag nicht mehr alles im Kopf.
@F-A-L sagte in Probleme bei ioBroker-Umzug mit backup/restore:
Zur Erinnerung: es ist mit nicht gelungen, die auf dem alten System installierten node unf nojejs in der Version 8 zu installieren, ich bekam immer Version 10.
Hatte das mit Buster zu tun? Dazu habe ich bereits einiges geschrieben. u.a.: https://forum.iobroker.net/topic/23590/nodejs-v8-x-unter-buster
Im Großen und Ganzen kann es auch an was anderem gelegen haben, was wir jetzt wahrscheinlich nicht mehr herausbekommen werden.
@F-A-L sagte in Probleme bei ioBroker-Umzug mit backup/restore:
welche Version von welchem Programm installiert war
Es werden bei einem restore IMMER die neuesten Versionen für das eingestellte Repository installiert.
Das Ganze dauert je nach Hardware auch mal bis zu 2 Stunden (und länger). so lange erscheint
@F-A-L sagte in Probleme bei ioBroker-Umzug mit backup/restore:
File index_m.html not found
wenn man versucht die Konfiguration zu öffnen.
Bricht man jetzt irgendwie ab (oder passiert etwas (siehe log) bleibt es für immer dabei.
Dann hilft meist noch ein Upload der entsprechenden Adapterdateien in die Instanz.@F-A-L sagte in Probleme bei ioBroker-Umzug mit backup/restore:
wie leicht es ist, ein Linux-System zu zerschießen, wenn man es vor dem Ausschalten nicht korrekt herunterfährt.
Das gilt für alle Systeme.
Wenn der Rechner sich gerade in einem Schreibprozess befindet und der Strom wegbricht ist das Dateisystem defekt.@F-A-L sagte in Probleme bei ioBroker-Umzug mit backup/restore:
In dem Fall hat man möglicherweise auch eine andere Version von node und nodejs oder npm,
Das ist meine "übliche" Art upzudaten
- Backup
- komplette Neuinstallation mit den neuesten Versionen
- restore
- fertig
@Homoran said in Probleme bei ioBroker-Umzug mit backup/restore:
Hatte das mit Buster zu tun? Dazu habe ich bereits einiges geschrieben. u.a.: https://forum.iobroker.net/topic/23590/nodejs-v8-x-unter-buster
Ich vermute, dass Du recht hast. Zumindest ist das die für mich bislang einzig sinnvolle Erklärung. Ich selbst bin mit buster lite gestartet, also noch gänzlich ohne node, nodejs und npm. Da gibt es eigentlich keinen anderen Grund, die angeforderte Version (8.x) zu verweigern.
Es werden bei einem restore IMMER die neuesten Versionen für das eingestellte Repository installiert.
Tja, und wenn man auf dem neu aufgesetzten System (Annahme: altes System läuft nicht mehr) auf ein inkompatibles node/nodejs gezwungen wird, dann war's das möglicherweise (wie bei mir mit dem aktivierten https im Admin-Adapter).
Im Ergebnis hätte man ein völlig unbrauchbares Backup. Das darf wirklich nicht passieren!
Da ich aber auch keinen Weg sehe, wie man so etwas sicher ausschließen könnte, stelle ich den Vorschlag zur Diskussion, evtl. nur einzelne Adapter für das Restore auswählen zu können. Ich würde sogar so weit gehen, in einer Art Expertenmodus nur die Daten des Adapters für eine manuelle Neuinstallation zur Extraktion anzubieten. Dann hat man zwar mächtig Pech gehabt, aber man hat wenigstens nicht alles verloren.
Anmerkung: Wie gesagt, ich konnte mir noch ein brauchbares Backup erzeugen, da das alte System ja noch existierte. Bei meinem ersten Aufspielen des Backups ist schon einiges ganz dumm zusammen gelaufen. Aber offenbar kann auch so etwas mal passieren.@F-A-L sagte in Probleme bei ioBroker-Umzug mit backup/restore:
File index_m.html not found
wenn man versucht die Konfiguration zu öffnen.
Bricht man jetzt irgendwie ab (oder passiert etwas (siehe log) bleibt es für immer dabei.
Interessanterweise sah es so allerdings aus, als wäre das zweite Restore (ohne die https-Falle) dann erfolgreich gewesen. Was da tatsächlich mit backitUp u.s.w. passiert ist, weiß ich im Moment auch nicht.
Das ist meine "übliche" Art upzudaten
- Backup
- komplette Neuinstallation mit den neuesten Versionen
- restore
- fertig
Tja, genau das habe ich in beiden Fällen auch gemacht, funktionierte aber scheinbar wegen der neuen Version von node/nodejs nicht so wie es sollte.
Meine Quintessenz ist, dass man sich nicht darauf verlassen darf, dass etwas ältere Systeme (meins hatte ich Ende Dezember 2018 aufgesetzt) zuverlässing wiederherstellen kann. Das Backup/Restore dürfte zwar sehr häufig funktionieren, aber definitiv nicht immer, wie mein Beispiel zeigt. Sei mir nicht böse, aber das ist in diesem Backup/Restore-Procedere im Kern schon so angelegt, dabei ist das schon richtig aufwändig gemacht. Man braucht tatsächlich noch das Glück, dass das neu installierte System noch mit dem alten kompatibel ist, sonst nutzt einem das ganze Backup leider gar nichts. Und wenn ich mir diesen jahrelangen Blues mit node/nodejs so vor Augen führe, oje...Lieben Gruß
F-A-L -
Hallo,
das Zurückspielen eines Backups hat bei mir auch nicht soo funktioniert. Das immer die neuesten Versionen genutzt werden, widerspricht meinem Verständnis eines Backups. Den einen oder anderen Adapter habe ich an meine Bedürfnisse angepasst. Z.B. Rückmeldungen an Alexa local in node red. Diese geänderten Dateien müssen dann wieder aus dem Backup extrahiert und an den alten Platz kopiert werden.Linux wird oft hoch gelobt, eine einfache Backup / restore Möglichkeit im laufenden Betrieb habe ich noch nicht gefunden. Proxmox mag mein NUC, nicht so. Zumindest ist das Netzwerk darunter unzuverlässig, was den S7 Adapter arg aus dem Tritt bringt.
Zuverlässig läuft es, seit ich Debian nativ nutze. Zum Erstellen eines Backups starte ich den NUC von SD-Karte mit Clonezilla drauf neu, erstelle ein Image zur Ablage verschiedener Versionen und klone die SSD auf eine zweite um das letzte Backup bootfähig im Schrank zu haben. Das ganze dauert etwas über 20 Minuten.
Zwischendurch, nach kleineren Änderungen, speichere ich die Skripte sowie die iobroker eigenen Backups auf dem PC ab.
Gruß
Peterfido
Proxmox auf Intel NUC12WSHi5
ioBroker: Debian (VM)
CCU: Debmatic (VM)
Influx: Debian (VM)
Grafana: Debian (VM)
eBus: Debian (VM)
Zigbee: Debian (VM) mit zigbee2mqtt -
@Homoran said in Probleme bei ioBroker-Umzug mit backup/restore:
Hatte das mit Buster zu tun? Dazu habe ich bereits einiges geschrieben. u.a.: https://forum.iobroker.net/topic/23590/nodejs-v8-x-unter-buster
Ich vermute, dass Du recht hast. Zumindest ist das die für mich bislang einzig sinnvolle Erklärung. Ich selbst bin mit buster lite gestartet, also noch gänzlich ohne node, nodejs und npm. Da gibt es eigentlich keinen anderen Grund, die angeforderte Version (8.x) zu verweigern.
Es werden bei einem restore IMMER die neuesten Versionen für das eingestellte Repository installiert.
Tja, und wenn man auf dem neu aufgesetzten System (Annahme: altes System läuft nicht mehr) auf ein inkompatibles node/nodejs gezwungen wird, dann war's das möglicherweise (wie bei mir mit dem aktivierten https im Admin-Adapter).
Im Ergebnis hätte man ein völlig unbrauchbares Backup. Das darf wirklich nicht passieren!
Da ich aber auch keinen Weg sehe, wie man so etwas sicher ausschließen könnte, stelle ich den Vorschlag zur Diskussion, evtl. nur einzelne Adapter für das Restore auswählen zu können. Ich würde sogar so weit gehen, in einer Art Expertenmodus nur die Daten des Adapters für eine manuelle Neuinstallation zur Extraktion anzubieten. Dann hat man zwar mächtig Pech gehabt, aber man hat wenigstens nicht alles verloren.
Anmerkung: Wie gesagt, ich konnte mir noch ein brauchbares Backup erzeugen, da das alte System ja noch existierte. Bei meinem ersten Aufspielen des Backups ist schon einiges ganz dumm zusammen gelaufen. Aber offenbar kann auch so etwas mal passieren.@F-A-L sagte in Probleme bei ioBroker-Umzug mit backup/restore:
File index_m.html not found
wenn man versucht die Konfiguration zu öffnen.
Bricht man jetzt irgendwie ab (oder passiert etwas (siehe log) bleibt es für immer dabei.
Interessanterweise sah es so allerdings aus, als wäre das zweite Restore (ohne die https-Falle) dann erfolgreich gewesen. Was da tatsächlich mit backitUp u.s.w. passiert ist, weiß ich im Moment auch nicht.
Das ist meine "übliche" Art upzudaten
- Backup
- komplette Neuinstallation mit den neuesten Versionen
- restore
- fertig
Tja, genau das habe ich in beiden Fällen auch gemacht, funktionierte aber scheinbar wegen der neuen Version von node/nodejs nicht so wie es sollte.
Meine Quintessenz ist, dass man sich nicht darauf verlassen darf, dass etwas ältere Systeme (meins hatte ich Ende Dezember 2018 aufgesetzt) zuverlässing wiederherstellen kann. Das Backup/Restore dürfte zwar sehr häufig funktionieren, aber definitiv nicht immer, wie mein Beispiel zeigt. Sei mir nicht böse, aber das ist in diesem Backup/Restore-Procedere im Kern schon so angelegt, dabei ist das schon richtig aufwändig gemacht. Man braucht tatsächlich noch das Glück, dass das neu installierte System noch mit dem alten kompatibel ist, sonst nutzt einem das ganze Backup leider gar nichts. Und wenn ich mir diesen jahrelangen Blues mit node/nodejs so vor Augen führe, oje...Lieben Gruß
F-A-L@F-A-L sagte in Probleme bei ioBroker-Umzug mit backup/restore:
auf ein inkompatibles node/nodejs gezwungen wird,
von node hatten wir nicht geredet, sondern von Adapterversionen
@F-A-L sagte in Probleme bei ioBroker-Umzug mit backup/restore:
Im Ergebnis hätte man ein völlig unbrauchbares Backup. Das darf wirklich nicht passieren!
ist es ja auch nicht (s.o.)
@F-A-L sagte in Probleme bei ioBroker-Umzug mit backup/restore:
funktionierte aber scheinbar wegen der neuen Version von node/nodejs nicht so wie es sollte.
Wie geschrieben, habe ich exakt das gleiche (mit node 10) gemacht
Node 10 is die empfohlene Version -
Hallo,
das Zurückspielen eines Backups hat bei mir auch nicht soo funktioniert. Das immer die neuesten Versionen genutzt werden, widerspricht meinem Verständnis eines Backups. Den einen oder anderen Adapter habe ich an meine Bedürfnisse angepasst. Z.B. Rückmeldungen an Alexa local in node red. Diese geänderten Dateien müssen dann wieder aus dem Backup extrahiert und an den alten Platz kopiert werden.Linux wird oft hoch gelobt, eine einfache Backup / restore Möglichkeit im laufenden Betrieb habe ich noch nicht gefunden. Proxmox mag mein NUC, nicht so. Zumindest ist das Netzwerk darunter unzuverlässig, was den S7 Adapter arg aus dem Tritt bringt.
Zuverlässig läuft es, seit ich Debian nativ nutze. Zum Erstellen eines Backups starte ich den NUC von SD-Karte mit Clonezilla drauf neu, erstelle ein Image zur Ablage verschiedener Versionen und klone die SSD auf eine zweite um das letzte Backup bootfähig im Schrank zu haben. Das ganze dauert etwas über 20 Minuten.
Zwischendurch, nach kleineren Änderungen, speichere ich die Skripte sowie die iobroker eigenen Backups auf dem PC ab.
@peterfido sagte in Probleme bei ioBroker-Umzug mit backup/restore:
Diese geänderten Dateien müssen dann wieder aus dem Backup extrahiert
Diese Dateien sind im backup NICHT enthalten, lediglich die Konfigurationen der Instanzen
Wenn du mehr in einem Backup haben willst musst du tatsächlich einen Snapshot oder einen Spiegel der Platte machen.
-
Stimmt. Jetzt fällt es mir wieder ein: Ich hatte die aus einem manuellem Backup per ftp zurückgeholt.
Gruß
Peterfido
Proxmox auf Intel NUC12WSHi5
ioBroker: Debian (VM)
CCU: Debmatic (VM)
Influx: Debian (VM)
Grafana: Debian (VM)
eBus: Debian (VM)
Zigbee: Debian (VM) mit zigbee2mqtt -
Stimmt. Jetzt fällt es mir wieder ein: Ich hatte die aus einem manuellem Backup per ftp zurückgeholt.
@peterfido sagte in Probleme bei ioBroker-Umzug mit backup/restore:
Ich hatte die aus einem manuellem Backup per ftp zurückgeholt.
wenn du bei diesem Vorgehen jedoch anschließend eine andere node version oder andere Hardware hast müssen die Pakete jedoch neu kompiliert werden.
Sonst gibt es ProblemeMit einem einfachen restore wird das ja auf die vorhin genannte Art automatisch erledigt
-
Das ist das, was meinem Verständnis von Backup widerspricht.
Klar. Einerseits kann ich mit den Backups das System umziehen. Andererseits fehlen evtl. Details / Anpassungen.
Gruß
Peterfido
Proxmox auf Intel NUC12WSHi5
ioBroker: Debian (VM)
CCU: Debmatic (VM)
Influx: Debian (VM)
Grafana: Debian (VM)
eBus: Debian (VM)
Zigbee: Debian (VM) mit zigbee2mqtt -
Das ist das, was meinem Verständnis von Backup widerspricht.
Klar. Einerseits kann ich mit den Backups das System umziehen. Andererseits fehlen evtl. Details / Anpassungen.
@peterfido sagte in Probleme bei ioBroker-Umzug mit backup/restore:
Andererseits fehlen evtl. Details / Anpassungen.
Das ist korrekt.
Aber: Ich habe auch immer den rpi(2) Adapter an diverse SBCs angepasst.
Schon bei einem Update des Adapters waren die Änderungen wegUnd genauso ist es nach einem Backup
@peterfido sagte in Probleme bei ioBroker-Umzug mit backup/restore:
Das ist das, was meinem Verständnis von Backup widerspricht.
Dann sollten wir es vielleicht "Konfigurationsbackup" nennen
-
"Konfigurationsbackup inklusive Skripten und Views und sonst noch einigem" :joy:
Für die restlichen Dinge wäre dann das total backup aus dem Backitup Adapter
-
Hallo Leute,
ich habe folgendes Problem:
Ich möchte mit meinem ioBroker auf ein anderes System bzw. eine andere SD-Karte umziehen und bin jetzt in größeren Schwierigkeiten.
altes System:npm -v -> 6.9.2 node -v -> 8.irgendwas nodejs -v -> wie bei node -vin der Kommandozeile mit "iobroker backup" ein Backup gemacht und dieses auf das neue System kopiert.
neues System:
ganz frisch aufgesetzt mit Buster lite (ohne npm, node, nodejs)
wesentliche Installationsschritte:curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash - (ich möchte also Version 8...) sudo apt install -y nodejs curl https://www.npmjs.com/install.sh | shErgebnis:
npm -v -> 6.9.2 node -v -> 10.15.2 (...und bekomme Version 10) nodejs -v -> 10.15.2dann iobroker installiert mit curl -sL https://iobroker.net/install.sh | bash -
Ergebnis: ioBroker startet und funktioniert wohl. Admin medet sich auf Port 8081, sieht gut aus.Wenn ich aber das backup von dem anderen System einspielen will, gibt es Schwierigkeiten.
Auszug aus dem log-file:... 2019-07-01 17:11:48.962 - ^[[32minfo^[[39m: admin.0 received all states 2019-07-01 17:11:50.623 - ^[[32minfo^[[39m: admin.0 received all objects 2019-07-01 17:11:51.025 - ^[[31merror^[[39m: admin.0 uncaught exception: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small 2019-07-01 17:11:51.025 - ^[[31merror^[[39m: admin.0 Error: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small at Object.createSecureContext (_tls_common.js:136:17) at Server (_tls_wrap.js:870:27) at new Server (https.js:62:14) at Object.createServer (https.js:85:10) at Object.createServer (/opt/iobroker/node_modules/iobroker.js-controller/lib/letsencrypt.js:174:39) at __construct (/opt/iobroker/node_modules/iobroker.admin/lib/web.js:455:32) at new Web (/opt/iobroker/node_modules/iobroker.admin/lib/web.js:486:7) at getData (/opt/iobroker/node_modules/iobroker.admin/main.js:388:39) at Socket.adapter.objects.getObjectList (/opt/iobroker/node_modules/iobroker.admin/main.js:441:35) at Socket.onack (/opt/iobroker/node_modules/socket.io-client/lib/socket.js:312:9) 2019-07-01 17:11:51.028 - ^[[32minfo^[[39m: admin.0 terminating https server on port 8081 2019-07-01 17:11:51.398 - ^[[32minfo^[[39m: admin.0 Repository received successfully. 2019-07-01 17:11:51.437 - ^[[31merror^[[39m: Caught by controller[0]: Error: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small 2019-07-01 17:11:51.438 - ^[[31merror^[[39m: Caught by controller[0]: at Object.createSecureContext (_tls_common.js:136:17) 2019-07-01 17:11:51.438 - ^[[31merror^[[39m: Caught by controller[0]: at Server (_tls_wrap.js:870:27) 2019-07-01 17:11:51.438 - ^[[31merror^[[39m: Caught by controller[0]: at new Server (https.js:62:14) 2019-07-01 17:11:51.439 - ^[[31merror^[[39m: Caught by controller[0]: at Object.createServer (https.js:85:10) 2019-07-01 17:11:51.439 - ^[[31merror^[[39m: Caught by controller[0]: at Object.createServer (/opt/iobroker/node_modules/iobroker.js-controller/lib/letsencrypt.js:174:39) 2019-07-01 17:11:51.439 - ^[[31merror^[[39m: Caught by controller[0]: at __construct (/opt/iobroker/node_modules/iobroker.admin/lib/web.js:455:32) 2019-07-01 17:11:51.439 - ^[[31merror^[[39m: Caught by controller[0]: at new Web (/opt/iobroker/node_modules/iobroker.admin/lib/web.js:486:7) 2019-07-01 17:11:51.439 - ^[[31merror^[[39m: Caught by controller[0]: at getData (/opt/iobroker/node_modules/iobroker.admin/main.js:388:39) 2019-07-01 17:11:51.440 - ^[[31merror^[[39m: Caught by controller[0]: at Socket.adapter.objects.getObjectList (/opt/iobroker/node_modules/iobroker.admin/main.js:441:35) 2019-07-01 17:11:51.440 - ^[[31merror^[[39m: Caught by controller[0]: at Socket.onack (/opt/iobroker/node_modules/socket.io-client/lib/socket.js:312:9) 2019-07-01 17:11:51.440 - ^[[31merror^[[39m: host.raspberry-iobroker instance system.adapter.admin.0 terminated with code 0 (OK) 2019-07-01 17:11:51.440 - ^[[32minfo^[[39m: host.raspberry-iobroker Restart adapter system.adapter.admin.0 because enabled 2019-07-01 17:11:57.387 - ^[[32minfo^[[39m: iobroker npm ...Entscheidend ist wohl der Fehler
SSL routines:SSL_CTX_use_certificate:ee key too smallScheinbar wird mit dem Backup ein Schlüssel zurückgespielt, der von irgendeiner Systemkomponente als zu schwach angesehen wird - und die kommt dann mit einem Fehler statt mit einer Warnung daher. Im Ergebnis gerät ioBroker in eine Dauerschleife und auf Port 8081 passiert natürlich gar nichts mehr.
Meines Erachtens muss ich entweder versuchen, den Restore des Schlüssels (welcher? wo?) zu verhindern, oder ich muss aus meiner alten Installation meine Objekte und Skripte auf einem anderen Weg als duch backup/restore herausholen.
Ich persönlich würde vorziehen, aus der alten Installation die Objekte und Scripte zu exportieren oder herauszukopieren und in das neue System zu importieren/hineinzukopieren, da ich davon ausgehe, dass diese Sache mit dem zu schwachen Schlüssel ohnehin bei irgendeinem späteren Update zum Problem wird.Hat jemand Erfahrungen oder eine gute Idee?
Jede Hilfe ist sehr willkommen, ich selbst arbeite mich daran schon zwei Tage ab.edit:
ich werde erst einmal folgendes versuchen:
noch einmal ein neues System aufsetzen, dann
ioBroker Objektstruktur exportieren und importieren die Objekte vom alten System holen. Für die Skripte könnte ich mit vorstellen, dass der Adapter "Javascript to file" hilft.
Mal sehen ...Habe jetzt nicht alles gelesen. Das Problem
error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too smallhat nichts mit Backup/Restore zu tun. Ursache ist das bis dato in ioBroker integrierte default SSL-Zertifikat in Verbindung mit Node 10. Das Problem ist bei den Entwicklern adressiert und dürfte in Version 1.5.13 des js-controllers behoben werden.
770
Online32.6k
Benutzer82.1k
Themen1.3m
Beiträge