@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

Lösung des Problems und meine gewonnenen (unschönen) Erfahrungen:
Das ursprünglich geschilderte Problem, dass ioBroker nach dem Einspielen des Backups mit dem SSL-Fehler in eine Dauerschleife geraten ist, konnte recht leicht gelöst werden. Ich hatte offenbar bei der Ersteinrichtung (ich bin da irgend einem Tutorial gefolgt) https im Admin-Adapter aktiviert. Das erstellte ioBroker-Backup (Kommandozeile mit "iobroker backup", nicht mit BackitUp) enthielt offensichtlich auch den zugehörigen Schlüssel, den ich auf dem neuen System aber nicht mehr zurückspielen konnte. 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. Ich nehme an, dass dadurch das Schlüsselproblem virulent wurde.

Daher folgender Wunsch:
Es würde Sinn machen, im Restore-Prozess einzelne Komponenten auswählen zu können.
Grund: Wenn man ein neues System aufsetzen muss, weiß man eventuell nicht einmal mehr, welche Version von welchem Programm installiert war. Und da man ein restore ja in der Regel macht, wenn das alte System aus welchen Gründen auch immer "gestorben" ist, muss man das Restore normalerweise in einem frisch aufgesetzen neuen System durchführen können. Ich hatte in dieser Hinsicht das Glück, dass ich das System nur klonen wollte und konnte glücklicherweise das alte System noch verändern und anschließend noch ein neues Backup starten. Aber im Ernstfall hat man diesen Luxus wohl kaum.

Weitere Beobachtungen:
Leider war diese SSL-Sache nicht das einzige Problem beim Restore. Vielleicht sollte ich vorweg sagen, dass ich auf dem alten System alle Adapter vor dem Backup auf den neuesten Stand gebracht hatte. Nach dem Restore auf dem neuen System brauchte ich einige wenige Adapter nur neu starten und sie liefen, dazu gehörte zu meiner Erleichterung auch Javascript (ich habe eine recht komplex miteinander verwobene Struktur von Objekten und Skripten, die ich für einen anderen Haushalt gerne übernehmen und anschließend anpassen wollte). Auch Philips Hue funktionierte so ziemlich auf Anhieb. Der Logitech-Adapter für meinen Hub hat hingegen schon recht ordentlich rumgezickt. Letztlich habe ich den komplett deinstallieren müssen und dann neu installiert. Aber dann funktionierte er wenigstens. Das kann ich über den BackitUp-Adapter leider nicht sagen. Die Instanz habe ich auch löschen müssen, aber er lässt sich nach der Erzeugung einer neuen Instanz (zumindest im Admin-Adapter, gemeint ist über port 8081) nicht mehr konfigurieren. Dort kommt jetzt anstelle der Konfigurationsseite nur "File index_m.html not found". Da die gleiche Version des Adapters auf dem alten System ohne Problem läuft, muss hier sogar durch das Restore etwas passiert sein, was sich durch das Löschen der Backup-Instanz und Erzeugung einer neuen Instanz nicht mehr reparieren lässt. Höchst merkwürdig! Auch der scenes-Adapter macht ähnliche Schwierigkeiten.

Tl;dr? / Fazit:
Ich bin ziemlich erschüttert, dass beim ioBroker das backup/restore-System solch riesengroße Probleme macht. Ich brauche wohl niemendem zu sagen, wie leicht es ist, ein Linux-System zu zerschießen, wenn man es vor dem Ausschalten nicht korrekt herunterfährt. Das Thema ist also ein Stromausfall, eine nicht zu unterschätzende Gefahr, gerade heutzutage wieder. Ich wünsche es niemandem, aber nehmen wir mal an, man hat durch irgendein Pech kein funktionierendes Linux mehr. Üblicherweise muss man dann ein komplett neues System aufzusetzen. In dem Fall hat man möglicherweise auch eine andere Version von node und nodejs oder npm, sei es, weil man seine alte Version nicht mehr kennt, oder weil sich das System sträubt, die gewünschte Version einzuspielen . Meines Erachtens sollte man dann auch die Möglichkeit haben, aus einem alten Backup die Daten zu extrahieren, die man nur mit großer Mühe oder gar nicht mehr auf andere Weise wiederbeschaffen kann.
Dieser Ansatz, dass ioBroker alles komplett in einem file sichert und dann wieder komplett einspielt, ist sicher gut gemeint, aber wenn man es dann braucht, muss es auch tatsächlich wieder einspielbar sein. Und da dieses Dauerproblem mit den node-, nodejs- und npm-Versionen nun einmal nicht wegzudiskutieren ist, wäre ich dafür, das Restore auch auf einzelne Adapter beschränken zu können.
(Ich werde bei Gelegenheit mal schauen, ob man dieses Problem mit BackitUp umgehen kann.)

Abschließend die Bitte, diesen Beitrag als konstruktive Kritik und Diskussionsanstoß aufzufassen. Nichts, was ich hier geschrieben habe, richtet sich gegen irgendwen. Aber vielleicht stellt sich ja auch heraus, das der Autor einfach nur die richtigen Befehle nicht kannte

Liebe Grüße
F-A-L

@Homoran

@F-A-L sagte in Probleme bei ioBroker-Umzug mit backup/restore:

dann npm installiert (version 8 angefordert)

Definitiv nicht!

Du hast natürlich Recht, die Anmerkung ist mir leider in die falschen Zeile gerutscht (ist inzwischen korrigiert). Gemeint war, dass ich node Version 8 angefordert hatte. npm hat die Version 6.9.2. Entschuldigung!

@F-A-L sagte in Probleme bei ioBroker-Umzug mit backup/restore:

Wieso meinet Du, dass

Was macht das install.sh denn?

Ich bin mir nicht sicher, ob ich die Frage richtig verstehe, daher noch einmal - und diesmal hoffentlich fehlerfrei - der Ablauf der Installation:
Ich bin mit Raspbian Buster lite gestartet (die Version enthält weder node, noch nodejs, noch npm - alle Versionsabfragen ohne Ergebnis)

Installation von node und nodejs:

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -      (ich möchte also Version 8...)
sudo apt install -y nodejs
node -v  -> 10.15.2
nodejs -v  -> 10.15.2

Das hatte ich vorher gemeint: ich wollte node version 8 (siehe setup_8.x) und bekomme version 10.
Im Anschluss noch npm installiert:

curl https://www.npmjs.com/install.sh | sh
npm -v   ->  6.9.2

Das install.sh hat vollkommen korrekt npm installiert und natürlich auch nichts an node und nodejs geändert.
Es tut mir wirklich leid, wenn ich durch den schlampig eingefügten Kommentar für Verwirrung gesorgt habe.

F-A-L

P.S.
Ich verfolge inzwischen den folgenden Weg beim klonen meines Systems:
indem ich https im admin-Adapter meines Systems abgeschaltet habe, war es mir möglich, ein frisch erstelltes backup auf dem neuen System mit "iobroker restore" einzuspielen. Den SSL-Fehler mit Dauerschleife beim restore, über den ich in meinem ursprünglichen post berichtet hatte, konnte ich dadurch vermeiden. Allerdings sehe ich einige andere Fehler im log-file, die ich mir jedoch erst einmal genauer ansehen muss. Ich werde später berichten...

@Homoran

Wo kommt dieser Befehl her?
Der setzt sich doch über das vorher eplizit geforderte v8 hinweg

@Hormoran
Danke, dass Du Dir mein Problem angeschaut hast und vielen lieben Dank für Dein Feedback!

Mit

curl https://www.npmjs.com/install.sh | sh

habe ich npm installiert. Da ich die Raspbian buster lite Version installiert hatte, war weder node, noch nodejs, noch npm installiert. Da die npm-Installation node voraussetzt, habe ich node eben auf diese Weise installiert. Durch die Installation von npm haben sich node -v und nodejs -v nicht verändert (habe ich kontrolliert)!
Ehrlich gesagt hatte ich diesmal npm auf diese Weise noch vor node installieren wollen, aber ich bin per Fehlermeldung darauf hingewiesen worden, dass zuerst doch node installiert werden muss. Also bin ich in der Reihenfolge node -> nodejs -> npm vorgegangen.
Tja, woher habe ich nun das Kommando, ich nehme an Du meinst:

curl https://www.npmjs.com/install.sh | sh

Bezüglich der Quelle komme ich jetzt leider richtig ins Schwimmen. Ich habe das aus einer Notiz, die ich vor etwa einem Jahr angelegt hatte, als ich das zuvor als "alt" bezeichete System aufgesetzt hatte. Damals hatte ich es offenbar genau so gemacht und es funktioniert bis heute.

Nachfrage:
Wieso meinet Du, dass

url https://www.npmjs.com/install.sh | sh

irgendwie

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -

überschreibt?

Es ist korrekt, dass node -v und nodejs -v die gleiche Versionsnummer haben müssen (war das der Auslöser Deines Posts?), aber die npm-Versionsnummer ist davon zunächst unabhängig - zumindest oberflächlich betrachtet. Die installierte npm-Version scheint dann allerdings doch versionsmäßig irgendwie von den installierten node/nodejs-Versionen abzuhängen, aber diese Abhängigkeit habe ich nie wirklich durchschaut.

Also, kleine Zusammenfassung:
ich habe zuerst node und nodejs installiert (siehe erster post):
node -v und nodejs -v -> 10.15.2 (edit: version 8 angefordert)
dann npm installiert (Fehlerkorrektur: hier stand "version 8 angefordert", aber das ist die falsche Zeile)
npm -v -> 6.9.2, node -v und nodejs -v unverändert

Liebe Grüße
F-A-L

@Dr-Bakterius
Ganz lieben Dank für Dein schnelles Feedback!
Tatsächlich bin ich immer via https auf dem System gewesen. Es ist jedoch nicht vom öffentlichen Internet zugänglich, d.h. hier wurde wohl irgendwann der Schlüssel selbst generiert (ich glaube fast, dass das irgendwie automatisch geschehen sein könnte). Diese Schlüssel haben also keinerlei Bedeutung und können jederzeit ausgetauscht werden.
Im Moment kann ich mich gar nicht mehr erinnern, ob ich damals SSL/TLS manuell im ioBroker aktiviert habe. In dem Fall könnte es vielleicht Sinn machen, SSL im alten System wieder zu deaktivieren und anschließend ein backup/restore vorzunehmen, sozusagen ohne https-Support und hoffentlich ohne Schlüssel-Backup?
Gruß,
F-A-L

@Fitti said in npm&Node Probs -wie alles NeuInstall?:

Unter https://www.iobroker.net/#de/documentation/trouble/RunsNoMore.md steht,
das node -v und npm -v die selbe Version sein sollen. Ist das so? Kann nirgends npm version 10 finden.

node und nodejs müssen die gleiche Version haben, npm -v zeigt eine andere Versionsnummer. Eine npm Version 10 gibt es in der Tat noch nicht.

edit:

Und wie sollte ich dann meine Updates/Setting zurücksichern, ohne gleich wieder die ganzen Module zu überschreiben.

Das Problem habe ich übrigens auch gerade, siehe Probleme bei ioBroker-Umzug mit backup/restore. Mal schauen, was die Experten raten...

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 -v

in 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 | sh

Ergebnis:

npm -v   ->  6.9.2
node -v  -> 10.15.2        (...und bekomme Version 10)
nodejs -v  -> 10.15.2

dann 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 small

Scheinbar 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 ...