NEWS
Javascript Adapter ständige Restarts
-
@BananaJoe @OliverIO @Thomas-Braun @TT-Tom
Vielen Dank für eurer Input, nach einigem hin und her-überlegen muss ich euch einfach recht geben. Für den reinen IoBroker Betrieb ist eine Desktop-Umgebung nicht nötig. Ich fand es damals beim Start mit Linux und IoBroker weniger befremdlich mit dem Raspberry OS mit Desktop, und habe das deswegen installiert. In der Zwischenzeit habe ich mich aber auch an die Konsole gewöhnt und mache eigentich alles für die IOB Wartung über den Admin oder die Konsole -> deshalb werde ich auf Proxmox eine Debian-Server aufsetzen und dort den Master aufsetzen. Danke nochmal für eurer Hilfe!!
-
@etzeste13 sagte in Javascript Adapter ständige Restarts:
Welch ein Betriebssystem für die IOB VM würdet Ihr mir empfehlen?
wie @Thomas-Braun schon schrieb wirst du mit Debian gut fahren - Raspberry OS basiert auch auf Debian, die Befehle und Kommandos die du kennst funktionieren dann also genauso.
Bis auf die paar Raspberry Pi spezifischen Befehle, die du dann aber auch nicht mehr brauchst.Wenn du einen Proxmox-Cluster testen willst: Die VMs sollten auf ZFS Speicher liegen, haben deine Hosts nur eine Festplatte eingebaut, musst du beim Installieren darauf achten die Festplatten gleich mit ZFS zu installieren.
Siehe hier was du beim Setup auswählen musst:
https://znil.net/index.php?title=Proxmox:_Installation_2_Node_Cluster_mit_Replikation_und_Live-Migration#Installation_der_Nodes_von_USB-Stick@BananaJoe sagte in Javascript Adapter ständige Restarts:
Wenn du einen Proxmox-Cluster testen willst: Die VMs sollten auf ZFS Speicher liegen, haben deine Hosts nur eine Festplatte eingebaut, musst du beim Installieren darauf achten die Festplatten gleich mit ZFS zu installieren.
Siehe hier was du beim Setup auswählen musst:
https://znil.net/index.php?title=Proxmox:_Installation_2_Node_Cluster_mit_Replikation_und_Live-Migration#Installation_der_Nodes_von_USB-StickDie Cluster-Lösung spricht mich sehr an muss ich sagen, auch die Doku die du verlinkt hast scheint super zu sein und trauhe ich mir auch zu umzusetzen. Was ich dich aber noch fragen wollte, ist es wirklich nötig hier 2 NICs zu haben. Ich habe auf meinen beiden Servern nur eine 1GB schnittstelle zur Verfügung. Reicht das für IOB für eine Replikation/Migration? Oder wäre es hier vielleicht besser auf beiden Host eine USB-NIC einzurichten, über die die Synchronisation separat läuft? vG Etze
-
@BananaJoe sagte in Javascript Adapter ständige Restarts:
Wenn du einen Proxmox-Cluster testen willst: Die VMs sollten auf ZFS Speicher liegen, haben deine Hosts nur eine Festplatte eingebaut, musst du beim Installieren darauf achten die Festplatten gleich mit ZFS zu installieren.
Siehe hier was du beim Setup auswählen musst:
https://znil.net/index.php?title=Proxmox:_Installation_2_Node_Cluster_mit_Replikation_und_Live-Migration#Installation_der_Nodes_von_USB-StickDie Cluster-Lösung spricht mich sehr an muss ich sagen, auch die Doku die du verlinkt hast scheint super zu sein und trauhe ich mir auch zu umzusetzen. Was ich dich aber noch fragen wollte, ist es wirklich nötig hier 2 NICs zu haben. Ich habe auf meinen beiden Servern nur eine 1GB schnittstelle zur Verfügung. Reicht das für IOB für eine Replikation/Migration? Oder wäre es hier vielleicht besser auf beiden Host eine USB-NIC einzurichten, über die die Synchronisation separat läuft? vG Etze
@etzeste13 sagte in Javascript Adapter ständige Restarts:
Die Cluster-Lösung spricht mich sehr an muss ich sagen, auch die Doku die du verlinkt hast scheint super zu sein und trauhe ich mir auch zu umzusetzen. Was ich dich aber noch fragen wollte, ist es wirklich nötig hier 2 NICs zu haben. Ich habe auf meinen beiden Servern nur eine 1GB schnittstelle zur Verfügung. Reicht das für IOB für eine Replikation/Migration? Oder wäre es hier vielleicht besser auf beiden Host eine USB-NIC einzurichten, über die die Synchronisation separat läuft? vG Etze
Das geht auch mit nur einer NIC. Meine MiniPCs hatten halt 2, da habe ich diese dafür genommen.
Du solltest die Replikation dann nach und nach einschalten und bei einer Migration immer nur eine VM zur Zeit verschieben (kann man auch bei Bulk-Migration so festlegen).
Da die meisten USB-Netzwerkadapter mit Debian (dem Linux unter Proxmox, mit Ubuntu-Kernel) funktionieren, könntest du bei Bedarf so einfach eine Netzwerkschnittstelle nachrüsten. Aber es geht auch ohne.Den ganzen Teil mit dem Quorum kannst du auch weglassen. Und HA lässt du aus.
HA mit Replikation kann halt einen Datenverlust über die Zeit des Replikationzeitabstandes bedeuten.
Du kannst mit den 2 Knoten aber jederzeit die VMs hin und her schieben und so immer einen Knoten updaten. Und im Notfall, falls der Knoten wo die VMs gerade lagen abraucht, kommts du noch immer an die VM Daten und kannst die VM von Hand wieder anwerfen. Dazu muss man dann eine Datei von Hand in einer SSH-Sitzung verschieben. Dafür macht er das dann nicht automatisch und du hast Zeit das Problem mit dem ausgefallenden Host zu beheben.
Die Anleitung ist von mir, wenn ich "etwas neues" mache, schreibe ich mir das gerne zusammen damit ich es 1:1 wiederholen kann. Inzwischen war ich auch auf einer einwöchigen Proxmox-Schulung. Meine Anleitung ist nicht falsch, aber ob man HA mit Replikation macht, sollte man vorher zumindest einmal durchdenken. -
@etzeste13 sagte in Javascript Adapter ständige Restarts:
Die Cluster-Lösung spricht mich sehr an muss ich sagen, auch die Doku die du verlinkt hast scheint super zu sein und trauhe ich mir auch zu umzusetzen. Was ich dich aber noch fragen wollte, ist es wirklich nötig hier 2 NICs zu haben. Ich habe auf meinen beiden Servern nur eine 1GB schnittstelle zur Verfügung. Reicht das für IOB für eine Replikation/Migration? Oder wäre es hier vielleicht besser auf beiden Host eine USB-NIC einzurichten, über die die Synchronisation separat läuft? vG Etze
Das geht auch mit nur einer NIC. Meine MiniPCs hatten halt 2, da habe ich diese dafür genommen.
Du solltest die Replikation dann nach und nach einschalten und bei einer Migration immer nur eine VM zur Zeit verschieben (kann man auch bei Bulk-Migration so festlegen).
Da die meisten USB-Netzwerkadapter mit Debian (dem Linux unter Proxmox, mit Ubuntu-Kernel) funktionieren, könntest du bei Bedarf so einfach eine Netzwerkschnittstelle nachrüsten. Aber es geht auch ohne.Den ganzen Teil mit dem Quorum kannst du auch weglassen. Und HA lässt du aus.
HA mit Replikation kann halt einen Datenverlust über die Zeit des Replikationzeitabstandes bedeuten.
Du kannst mit den 2 Knoten aber jederzeit die VMs hin und her schieben und so immer einen Knoten updaten. Und im Notfall, falls der Knoten wo die VMs gerade lagen abraucht, kommts du noch immer an die VM Daten und kannst die VM von Hand wieder anwerfen. Dazu muss man dann eine Datei von Hand in einer SSH-Sitzung verschieben. Dafür macht er das dann nicht automatisch und du hast Zeit das Problem mit dem ausgefallenden Host zu beheben.
Die Anleitung ist von mir, wenn ich "etwas neues" mache, schreibe ich mir das gerne zusammen damit ich es 1:1 wiederholen kann. Inzwischen war ich auch auf einer einwöchigen Proxmox-Schulung. Meine Anleitung ist nicht falsch, aber ob man HA mit Replikation macht, sollte man vorher zumindest einmal durchdenken.@BananaJoe
OK, dann werde ich mal den Cluster einrichten und auf das HA und Quorum mit einem zusätzlichen Raspi verzichten. Soweit ich alles verstanden habe, sollte ich das ja zu einem späteren Zeitpunkt ja auch erweitern können.... oder?Was hat dich den abgehalten HA ohne der Replikation zu machen? vG
-
@etzeste13 sagte in Javascript Adapter ständige Restarts:
Die Cluster-Lösung spricht mich sehr an muss ich sagen, auch die Doku die du verlinkt hast scheint super zu sein und trauhe ich mir auch zu umzusetzen. Was ich dich aber noch fragen wollte, ist es wirklich nötig hier 2 NICs zu haben. Ich habe auf meinen beiden Servern nur eine 1GB schnittstelle zur Verfügung. Reicht das für IOB für eine Replikation/Migration? Oder wäre es hier vielleicht besser auf beiden Host eine USB-NIC einzurichten, über die die Synchronisation separat läuft? vG Etze
Das geht auch mit nur einer NIC. Meine MiniPCs hatten halt 2, da habe ich diese dafür genommen.
Du solltest die Replikation dann nach und nach einschalten und bei einer Migration immer nur eine VM zur Zeit verschieben (kann man auch bei Bulk-Migration so festlegen).
Da die meisten USB-Netzwerkadapter mit Debian (dem Linux unter Proxmox, mit Ubuntu-Kernel) funktionieren, könntest du bei Bedarf so einfach eine Netzwerkschnittstelle nachrüsten. Aber es geht auch ohne.Den ganzen Teil mit dem Quorum kannst du auch weglassen. Und HA lässt du aus.
HA mit Replikation kann halt einen Datenverlust über die Zeit des Replikationzeitabstandes bedeuten.
Du kannst mit den 2 Knoten aber jederzeit die VMs hin und her schieben und so immer einen Knoten updaten. Und im Notfall, falls der Knoten wo die VMs gerade lagen abraucht, kommts du noch immer an die VM Daten und kannst die VM von Hand wieder anwerfen. Dazu muss man dann eine Datei von Hand in einer SSH-Sitzung verschieben. Dafür macht er das dann nicht automatisch und du hast Zeit das Problem mit dem ausgefallenden Host zu beheben.
Die Anleitung ist von mir, wenn ich "etwas neues" mache, schreibe ich mir das gerne zusammen damit ich es 1:1 wiederholen kann. Inzwischen war ich auch auf einer einwöchigen Proxmox-Schulung. Meine Anleitung ist nicht falsch, aber ob man HA mit Replikation macht, sollte man vorher zumindest einmal durchdenken.@BananaJoe sagte in Javascript Adapter ständige Restarts:
Meine Anleitung ist nicht falsch, aber ob man HA mit Replikation macht, sollte man vorher zumindest einmal durchdenken.
Welche SSDs hast genommen, "Normale" oder Server SSDs?
Proxmox 9 HA-Cluster mit 3x HP prodesk 400 G6 i5
Bei einem downvote bitte melden, es könnte sein, dass dieser ungewollt ist! -
@BananaJoe sagte in Javascript Adapter ständige Restarts:
Meine Anleitung ist nicht falsch, aber ob man HA mit Replikation macht, sollte man vorher zumindest einmal durchdenken.
Welche SSDs hast genommen, "Normale" oder Server SSDs?
Knoten1 ist ein Unraid-Server bei dem der Proxmox als VM läuft und am Cache von Unraid liegt. Der Cache sind hier 2 Samsung 970Evo Plus 2TB als btrfs Spiegel.
Am Knoten 2 habe ich eine normale 512GB SSD in einem vorhanden Laptop (HP PB650 mit i5-4200M). -
@BananaJoe
OK, dann werde ich mal den Cluster einrichten und auf das HA und Quorum mit einem zusätzlichen Raspi verzichten. Soweit ich alles verstanden habe, sollte ich das ja zu einem späteren Zeitpunkt ja auch erweitern können.... oder?Was hat dich den abgehalten HA ohne der Replikation zu machen? vG
@etzeste13 ich mache gar kein HA mehr sondern schalte bei Bedarf von Hand um.
Replikation läuft z.B. alle 15 Minuten. Und wenn man HA anhat und der schaltet um, schaltet er auch gnadenlos die Relikationrichtung um.
Ist mir z.B. mal passiert als ich einen Kurzschluss/Kreis im Netzwerk hatte oder ich einen Switch neu gestartet habe. -
@BananaJoe sagte in Javascript Adapter ständige Restarts:
Meine Anleitung ist nicht falsch, aber ob man HA mit Replikation macht, sollte man vorher zumindest einmal durchdenken.
Welche SSDs hast genommen, "Normale" oder Server SSDs?
@Shadowhunter23 sagte in Javascript Adapter ständige Restarts:
@BananaJoe sagte in Javascript Adapter ständige Restarts:
Meine Anleitung ist nicht falsch, aber ob man HA mit Replikation macht, sollte man vorher zumindest einmal durchdenken.
Welche SSDs hast genommen, "Normale" oder Server SSDs?
Die SSDs die ab Werk in meinen Mini-PCs eingebaut waren. Sind "Acemagic S1", die mit dem Display, da ist eine 512GB SSD drin
Also normale. Auch meine anderen Server haben normale NVMe / SSD drin.
Sicherheit habe ich durch redundanz, dafür ist die Hardware billigerioBroker@Ubuntu 24.04 LTS (VMware) für: >260 Geräte, 5 Switche, 7 AP, 9 IP-Cam, 1 NAS 42TB, 1 ESXi 15TB, 4 Proxmox 1TB, 1 Hyper-V 48TB, 14 x Echo, 5x FireTV, 5 x Tablett/Handy VIS || >=160 Tasmota/Shelly || >=95 ZigBee || PV 8.1kW / Akku 14kWh || 2x USV 750W kaskadiert || Creality CR-10 SE 3D-Drucker
-
@etzeste13 ich mache gar kein HA mehr sondern schalte bei Bedarf von Hand um.
Replikation läuft z.B. alle 15 Minuten. Und wenn man HA anhat und der schaltet um, schaltet er auch gnadenlos die Relikationrichtung um.
Ist mir z.B. mal passiert als ich einen Kurzschluss/Kreis im Netzwerk hatte oder ich einen Switch neu gestartet habe.@BananaJoe Das klingt eigentlich sehr vernünftig und ausreichend. Mir ist wenn ich so überlege schon lange keiner der Knoten abgeraucht, oder offline gegangen... ich habe auch alles hinter einer USV laufen, deshalb lauft auch alles sehr stabil... Danke für deine Inputs.... sehr hilfreich!!
-
@Shadowhunter23 sagte in Javascript Adapter ständige Restarts:
@BananaJoe sagte in Javascript Adapter ständige Restarts:
Meine Anleitung ist nicht falsch, aber ob man HA mit Replikation macht, sollte man vorher zumindest einmal durchdenken.
Welche SSDs hast genommen, "Normale" oder Server SSDs?
Die SSDs die ab Werk in meinen Mini-PCs eingebaut waren. Sind "Acemagic S1", die mit dem Display, da ist eine 512GB SSD drin
Also normale. Auch meine anderen Server haben normale NVMe / SSD drin.
Sicherheit habe ich durch redundanz, dafür ist die Hardware billiger@BananaJoe überwachst du die smart werte? oder
wann würdest du die ssd tauschen? -
@BananaJoe überwachst du die smart werte? oder
wann würdest du die ssd tauschen?@OliverIO sagte in Javascript Adapter ständige Restarts:
@BananaJoe überwachst du die smart werte? oder
wann würdest du die ssd tauschen?Proxmox selbst hat die Smartwerte auch im Blick und man könnte diese darüber abfragen, ansonsten per smartctrl im Betriebssystem.
Ob es da einen Alarm gibt, weis ich aber gerade nichtZufällig habe ich mich neulich damit ein paar Stunden beschäftigt - an einem Windows PC habe eine Festplatte mit jeder Menge "Bad Blocks", da sind auch schon Dateien beschädigt.
CrystalDiskInfo markiert die Festplatte als gelb, das basiert aber wohl auf irgendwelchen Listen.
S.M.A.R.T. Werte per Powershell oder anderere Tools sagen alle das die Festplatte "Good" ist.Also Smart ist nett, aber die Bad Blocks sehe ich z.B. nur in der Ereignisanzeige.
Hier meine "Baustelle" zu Überlegungen dazu: https://znil.net/index.php?title=Zabbix:Template_Windows_SMART-Werte_Festplatten -
@ticaki sagte in Javascript Adapter ständige Restarts:
-) Wenn ich das Backup mache und auf den neuen Host aufsetze, ist es dann besser vor dem Backup von redis auf File oder Json zu wechseln? Auf dem Server denke ich würde die Performance so sicher ausreichen, und ich erspare mir den Aufwand mit Redis.Vorher umwandeln.
Ich gehe davon aus, dass ich es auf json Umwandeln soll. Muss ich das dann vorher auch bei allen Slaves so machen? Und wenn ja in welcher Reihenfolge? Aktuell läuft ja alles über Redis am Master, und wenn ich das umstelle laufen die Slaves ja ins nirgends, wenn der Master kein Redis mehr macht. Oder verstehe ich hier was falsch?
sagte in Javascript Adapter ständige Restarts:
Online
etzeste13
schrieb am 27. Nov. 2025, 16:33 zuletzt editiert von
#11@ticaki sagte in Javascript Adapter ständige Restarts:
-) Wenn ich das Backup mache und auf den neuen Host aufsetze, ist es dann besser vor dem Backup von redis auf File oder Json zu wechseln? Auf dem Server denke ich würde die Performance so sicher ausreichen, und ich erspare mir den Aufwand mit Redis.
Vorher umwandeln.Ich gehe davon aus, dass ich es auf json Umwandeln soll. Muss ich das dann vorher auch bei allen Slaves so machen? Und wenn ja in welcher Reihenfolge? Aktuell läuft ja alles über Redis am Master, und wenn ich das umstelle laufen die Slaves ja ins nirgends, wenn der Master kein Redis mehr macht. Oder verstehe ich hier was falsch?
@ticaki
@bananajoe
@tt-tom
@oliverioich habe jetzt mal eine debian 13 VM aufgesetzt und einen jungfräulichen IOBroker drauf laufen. Ich wollte euch nochmals fragen wie ich die Migration des Masters nun richtig mache, bzw wie die richtige Reihenfolge sein muss:
Mein Verständnis/Idee bisher:
- IOB auf Slaves und zuletzt am Master stoppen
- am Master
iob setup customausführen und von redis auf JSON umstellen - danach einen Slave nach dem anderen auch auf JSON umstellen und jeweils die IP des Masters angeben
- ab dann sollte alles wieder normal laufen.
- Backup per backitup machen
--- Ab hier bin ich mir unsicher ---- - Dieses Backup mittels Backit-UP im neuen IOB Master einspielen ( muss ich hier auf Dinge we Hostname oder IP-Adresse aufpassen?)
Ich meine ich habe mal gelesen, dass es möglich wäre die Daten aus dem "alten" Master von /opt/iobroker, in das Verzeichnis des neuen Master zu kopieren - dann sollte alles am neuen Master weiterlaufen????? - Wie binde ich nun die Slaves wieder richtig ein sodass die weiter laufen? Da laufen ja einige Instanzen, unter anderem Zigbee drauf und das würde ich ungern neu pairen...
Gibt es hier irgendwo eine Anleitung, was die richtige Vorgehensweise/Reihenfolge ist damit man so wenig Down-Time wie möglich hat?
Ich habe das gefühl, dass ich hier relativ viel falsch bzw. kaputt machen kann, wenn ich nicht genau das Richtige mache...
vG
Etze -
sagte in Javascript Adapter ständige Restarts:
Online
etzeste13
schrieb am 27. Nov. 2025, 16:33 zuletzt editiert von
#11@ticaki sagte in Javascript Adapter ständige Restarts:
-) Wenn ich das Backup mache und auf den neuen Host aufsetze, ist es dann besser vor dem Backup von redis auf File oder Json zu wechseln? Auf dem Server denke ich würde die Performance so sicher ausreichen, und ich erspare mir den Aufwand mit Redis.
Vorher umwandeln.Ich gehe davon aus, dass ich es auf json Umwandeln soll. Muss ich das dann vorher auch bei allen Slaves so machen? Und wenn ja in welcher Reihenfolge? Aktuell läuft ja alles über Redis am Master, und wenn ich das umstelle laufen die Slaves ja ins nirgends, wenn der Master kein Redis mehr macht. Oder verstehe ich hier was falsch?
@ticaki
@bananajoe
@tt-tom
@oliverioich habe jetzt mal eine debian 13 VM aufgesetzt und einen jungfräulichen IOBroker drauf laufen. Ich wollte euch nochmals fragen wie ich die Migration des Masters nun richtig mache, bzw wie die richtige Reihenfolge sein muss:
Mein Verständnis/Idee bisher:
- IOB auf Slaves und zuletzt am Master stoppen
- am Master
iob setup customausführen und von redis auf JSON umstellen - danach einen Slave nach dem anderen auch auf JSON umstellen und jeweils die IP des Masters angeben
- ab dann sollte alles wieder normal laufen.
- Backup per backitup machen
--- Ab hier bin ich mir unsicher ---- - Dieses Backup mittels Backit-UP im neuen IOB Master einspielen ( muss ich hier auf Dinge we Hostname oder IP-Adresse aufpassen?)
Ich meine ich habe mal gelesen, dass es möglich wäre die Daten aus dem "alten" Master von /opt/iobroker, in das Verzeichnis des neuen Master zu kopieren - dann sollte alles am neuen Master weiterlaufen????? - Wie binde ich nun die Slaves wieder richtig ein sodass die weiter laufen? Da laufen ja einige Instanzen, unter anderem Zigbee drauf und das würde ich ungern neu pairen...
Gibt es hier irgendwo eine Anleitung, was die richtige Vorgehensweise/Reihenfolge ist damit man so wenig Down-Time wie möglich hat?
Ich habe das gefühl, dass ich hier relativ viel falsch bzw. kaputt machen kann, wenn ich nicht genau das Richtige mache...
vG
EtzeMultihost habe ich leider keine Ahnung.
-
sagte in Javascript Adapter ständige Restarts:
Online
etzeste13
schrieb am 27. Nov. 2025, 16:33 zuletzt editiert von
#11@ticaki sagte in Javascript Adapter ständige Restarts:
-) Wenn ich das Backup mache und auf den neuen Host aufsetze, ist es dann besser vor dem Backup von redis auf File oder Json zu wechseln? Auf dem Server denke ich würde die Performance so sicher ausreichen, und ich erspare mir den Aufwand mit Redis.
Vorher umwandeln.Ich gehe davon aus, dass ich es auf json Umwandeln soll. Muss ich das dann vorher auch bei allen Slaves so machen? Und wenn ja in welcher Reihenfolge? Aktuell läuft ja alles über Redis am Master, und wenn ich das umstelle laufen die Slaves ja ins nirgends, wenn der Master kein Redis mehr macht. Oder verstehe ich hier was falsch?
@ticaki
@bananajoe
@tt-tom
@oliverioich habe jetzt mal eine debian 13 VM aufgesetzt und einen jungfräulichen IOBroker drauf laufen. Ich wollte euch nochmals fragen wie ich die Migration des Masters nun richtig mache, bzw wie die richtige Reihenfolge sein muss:
Mein Verständnis/Idee bisher:
- IOB auf Slaves und zuletzt am Master stoppen
- am Master
iob setup customausführen und von redis auf JSON umstellen - danach einen Slave nach dem anderen auch auf JSON umstellen und jeweils die IP des Masters angeben
- ab dann sollte alles wieder normal laufen.
- Backup per backitup machen
--- Ab hier bin ich mir unsicher ---- - Dieses Backup mittels Backit-UP im neuen IOB Master einspielen ( muss ich hier auf Dinge we Hostname oder IP-Adresse aufpassen?)
Ich meine ich habe mal gelesen, dass es möglich wäre die Daten aus dem "alten" Master von /opt/iobroker, in das Verzeichnis des neuen Master zu kopieren - dann sollte alles am neuen Master weiterlaufen????? - Wie binde ich nun die Slaves wieder richtig ein sodass die weiter laufen? Da laufen ja einige Instanzen, unter anderem Zigbee drauf und das würde ich ungern neu pairen...
Gibt es hier irgendwo eine Anleitung, was die richtige Vorgehensweise/Reihenfolge ist damit man so wenig Down-Time wie möglich hat?
Ich habe das gefühl, dass ich hier relativ viel falsch bzw. kaputt machen kann, wenn ich nicht genau das Richtige mache...
vG
Etze@etzeste13 wenn der Multihost korrekt installiert wurde
- vor der Kopplung an den Master keine Instanz darauf installiert
- alle Instanzen erst nach der Kopplung über den Master auf die Slaves installiert.
Dann liegen alle Informationen von ioBroker auf dem Master
Dann sind auch alle Informationen im Backup des Masters.Wenn nun die (bisher korrekt Installierten und arbeitenden Slaves nur an einen neuen Master angebunden werden sollen, auf dem ein funktionierendes Backup der bisherigen Installation zurückgespielt wurde,
- muss auf den slaves nur ein
iob stetup customausgeführt und dort die neue IP des neuen Masters eingegeben werden.
noch einfacher wird es nur, wenn der neue Master den selben Hostnamen und die selbe IP wie bisher der alte Master hatte, bekommt.
Dann müssen nur alle Hosts neu gestartet werden.
===
Wenn auf den Slaves externe Datenbanken laufen (z.b. influx/zigbee...) müssten diese getrennt gesichert werden wenn die Slaves neu aufgesetzt werden sollen.
-
@etzeste13 wenn der Multihost korrekt installiert wurde
- vor der Kopplung an den Master keine Instanz darauf installiert
- alle Instanzen erst nach der Kopplung über den Master auf die Slaves installiert.
Dann liegen alle Informationen von ioBroker auf dem Master
Dann sind auch alle Informationen im Backup des Masters.Wenn nun die (bisher korrekt Installierten und arbeitenden Slaves nur an einen neuen Master angebunden werden sollen, auf dem ein funktionierendes Backup der bisherigen Installation zurückgespielt wurde,
- muss auf den slaves nur ein
iob stetup customausgeführt und dort die neue IP des neuen Masters eingegeben werden.
noch einfacher wird es nur, wenn der neue Master den selben Hostnamen und die selbe IP wie bisher der alte Master hatte, bekommt.
Dann müssen nur alle Hosts neu gestartet werden.
===
Wenn auf den Slaves externe Datenbanken laufen (z.b. influx/zigbee...) müssten diese getrennt gesichert werden wenn die Slaves neu aufgesetzt werden sollen.
@Homoran
Hallo, und danke für die Antwort. Hm ist schon lange her das ich den ersten Slave mit dazu genommen habe. Ich denke aber ich habe damals alles nach der Anleitung gemacht. Die Hosts ( RasPis) aufgesetzt, IOBroker installiert und dann als Slave definiert. Da waren damals aber sicher Admin, Backitup und Discovery-Adapter drauf, als ich auf Slave umstellte. --> Macht das dann die einfache Umstellung zunichte?Ich habe nur auf einem Slave ZigBee laufen, sonst nur andere Adapter, die ich vor der Migration auch auf den Master schieben könnte...
Bzgl des Host mit der ZigBee Datenbank drauf. Wie geht das getrennt sichern?
vG
-
@Homoran
Hallo, und danke für die Antwort. Hm ist schon lange her das ich den ersten Slave mit dazu genommen habe. Ich denke aber ich habe damals alles nach der Anleitung gemacht. Die Hosts ( RasPis) aufgesetzt, IOBroker installiert und dann als Slave definiert. Da waren damals aber sicher Admin, Backitup und Discovery-Adapter drauf, als ich auf Slave umstellte. --> Macht das dann die einfache Umstellung zunichte?Ich habe nur auf einem Slave ZigBee laufen, sonst nur andere Adapter, die ich vor der Migration auch auf den Master schieben könnte...
Bzgl des Host mit der ZigBee Datenbank drauf. Wie geht das getrennt sichern?
vG
@etzeste13 sagte in Javascript Adapter ständige Restarts:
Bzgl des Host mit der ZigBee Datenbank drauf. Wie geht das getrennt sichern?
müsstest du nochmal im wirklich guten backitup Wiki nachsehen.
Soweit ich es im Kopf hab, braucht es dafür eine Backitup Instanz auf diesem Slave.@etzeste13 sagte in Javascript Adapter ständige Restarts:
Da waren damals aber sicher Admin, Backitup und Discovery-Adapter drauf, als ich auf Slave umstellte. --> Macht das dann die einfache Umstellung zunichte?
nicht mehr als bisher 😉
-
@etzeste13 sagte in Javascript Adapter ständige Restarts:
Bzgl des Host mit der ZigBee Datenbank drauf. Wie geht das getrennt sichern?
müsstest du nochmal im wirklich guten backitup Wiki nachsehen.
Soweit ich es im Kopf hab, braucht es dafür eine Backitup Instanz auf diesem Slave.@etzeste13 sagte in Javascript Adapter ständige Restarts:
Da waren damals aber sicher Admin, Backitup und Discovery-Adapter drauf, als ich auf Slave umstellte. --> Macht das dann die einfache Umstellung zunichte?
nicht mehr als bisher 😉
@Homoran
Hallo, also ich habe nun übers WE eine VM mit dem gleichen Hostnamen mit debian 13 aufgesetzt, IOB, Redis, Influx und Grafana laufen wie am bisherigen Master. Soweit ist die Basis für die Migration vom alten Master hergestellt.Meine Idee und Versuch war dann folgender:
- Backup vom akt Master machen
- das ins IOB-Backup-Verzeichnis der VM spielen
- dann alten Master runterfahren und bei den Slaves IOB stop
- die VM mit der IP des alten Masters starten lassen - dann sollten IP und Hostname gleich sein
- die IOB Installation der VM starten, und über den BackitUp-Adapter das Backup vom alten Master einspielen, und die Slaves nach der Wiederherstellung wieder starten
Dann sollte laut obriger Info, alles weiter laufen.
Leider bricht das Restore des alten Masters auf der neuen VM immer ab, sobald der Admin neu geladen wird. Es ist dann auch kein Fortschritt mehr sichtbar und auch auf der VM oder im htop sind keine Aktivitäten des Restores sichtbar. Hier ein screenshot beim Abbruch...
Der IOB auf der VM ist dann nicht mehr erreichbar...Ich hab das mehrere male probiert, aber immer mit dem gleichen Ergebniss.... Die Versionen von Admin und Backitup sind am alten Master und der neuen IOB Installation auf der VM gleich.
Mach ich hier generell was falsch, bzw. habt Ihr einen Tipp woran es hacken kann?
vG Etze
-
@Homoran
Hallo, also ich habe nun übers WE eine VM mit dem gleichen Hostnamen mit debian 13 aufgesetzt, IOB, Redis, Influx und Grafana laufen wie am bisherigen Master. Soweit ist die Basis für die Migration vom alten Master hergestellt.Meine Idee und Versuch war dann folgender:
- Backup vom akt Master machen
- das ins IOB-Backup-Verzeichnis der VM spielen
- dann alten Master runterfahren und bei den Slaves IOB stop
- die VM mit der IP des alten Masters starten lassen - dann sollten IP und Hostname gleich sein
- die IOB Installation der VM starten, und über den BackitUp-Adapter das Backup vom alten Master einspielen, und die Slaves nach der Wiederherstellung wieder starten
Dann sollte laut obriger Info, alles weiter laufen.
Leider bricht das Restore des alten Masters auf der neuen VM immer ab, sobald der Admin neu geladen wird. Es ist dann auch kein Fortschritt mehr sichtbar und auch auf der VM oder im htop sind keine Aktivitäten des Restores sichtbar. Hier ein screenshot beim Abbruch...
Der IOB auf der VM ist dann nicht mehr erreichbar...Ich hab das mehrere male probiert, aber immer mit dem gleichen Ergebniss.... Die Versionen von Admin und Backitup sind am alten Master und der neuen IOB Installation auf der VM gleich.
Mach ich hier generell was falsch, bzw. habt Ihr einen Tipp woran es hacken kann?
vG Etze
@etzeste13 sagte in Javascript Adapter ständige Restarts:
Es ist dann auch kein Fortschritt mehr sichtbar und auch auf der VM oder im htop sind keine Aktivitäten des Restores sichtbar.
Schau dir das log per
iob logs --watchan. Ein Restore kann geraume Zeit in Anspruch nehmen.
-
@etzeste13 sagte in Javascript Adapter ständige Restarts:
Es ist dann auch kein Fortschritt mehr sichtbar und auch auf der VM oder im htop sind keine Aktivitäten des Restores sichtbar.
Schau dir das log per
iob logs --watchan. Ein Restore kann geraume Zeit in Anspruch nehmen.
@Thomas-Braun
Hallo, danke für die Info....
das kommt folgendes
Man sieht ab einem gewissen Zeitpunkt keinen Fortschritt mehr.... auch im Log nicht mehr...vG
-
@Homoran
Hallo, also ich habe nun übers WE eine VM mit dem gleichen Hostnamen mit debian 13 aufgesetzt, IOB, Redis, Influx und Grafana laufen wie am bisherigen Master. Soweit ist die Basis für die Migration vom alten Master hergestellt.Meine Idee und Versuch war dann folgender:
- Backup vom akt Master machen
- das ins IOB-Backup-Verzeichnis der VM spielen
- dann alten Master runterfahren und bei den Slaves IOB stop
- die VM mit der IP des alten Masters starten lassen - dann sollten IP und Hostname gleich sein
- die IOB Installation der VM starten, und über den BackitUp-Adapter das Backup vom alten Master einspielen, und die Slaves nach der Wiederherstellung wieder starten
Dann sollte laut obriger Info, alles weiter laufen.
Leider bricht das Restore des alten Masters auf der neuen VM immer ab, sobald der Admin neu geladen wird. Es ist dann auch kein Fortschritt mehr sichtbar und auch auf der VM oder im htop sind keine Aktivitäten des Restores sichtbar. Hier ein screenshot beim Abbruch...
Der IOB auf der VM ist dann nicht mehr erreichbar...Ich hab das mehrere male probiert, aber immer mit dem gleichen Ergebniss.... Die Versionen von Admin und Backitup sind am alten Master und der neuen IOB Installation auf der VM gleich.
Mach ich hier generell was falsch, bzw. habt Ihr einen Tipp woran es hacken kann?
vG Etze
Hallo an alle.... ich habe den Fehler gefunden: Es lag an der /etc/resolv.conf. Da waren keine DNS-Server eingetragen, deshalb konnte die VM die namen nicht auflösen und die adapter konnten nicht geladen werden.
Nachdem ich das gelöst hatte, hat die Migration wie erhofft und oben beschrieben funktioniert. Soweit ich es bisher feststellen könnte passt auch alles bei den Slaves... und alle Instanzen funktionieren.
Jetzt bleiben noch die Slaves einer nach dem anderen neu aufzusetzen. Aber schon jetzt an alle die mich unterstützt haben vielen Dank!!
vG Etze
352
Online32.6k
Benutzer82.2k
Themen1.3m
Beiträge