Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[Josh]

Hallo liebe ioBroker-Gemeinde!

Ich möchte mein aktuelles ioBroker-System welches aus einem Master (RPi4-4GB) und einem Slave (RPI3) besteht besser und ausfallsicherer konfigurieren. Dazu soll eine VM bzw. ein Container zum Einsatz kommen. Dazu muss der Master auf eine VM bzw. einen Container umziehen und der alte Master soll zum Slave werden. Der zweite/alte Slave muss sich dann mit dem neuen Master verbinden.

Da ich ungerne mit meinem Halbwissen an meinem Produktivsystem herumexperimentieren möchte, frage ich hier lieber vorher um Rat.

In Sachen VM/Container habe zwei Möglichkeiten der Hardware:

1. Synology Diskstation DS720+ mit 6 GB RAM und ordentlich HDD-Speicher

• im Docker-Container
• als echte VM Virtual Machine Manager
  Nachteil der Hardware: relativ wenig Arbeitsspeicher

2. Intel NUC10i5 mit 32GB RAM und 1 TB SSD mit Proxmox

• im LXC Container
• echte VM mit Ubuntu oder Debian

Ziel soll es sein, dass ich vor Update die VM/Container komplett sichern kann bzw. einen Snapshot erstellen kann, der ein Fallback einfach ermöglicht. Backups lassen sich auch ganz einfach zurückspielen.

Erster Fragenblock:
Auf welche Hardware würdet ihr setzen? Und welche Art würdet ihr bevorzugen? Container oder echte VM?

Zweiter Fragenblock:
Wie gehe ich beim Umzug geschickt vor, sodass möglichst wenig Probleme zu erwarten sind? Bei der Multihost-Einrichtung bin ich nach dieser Anleitung vorgegangen.
Ich würde einfach den neuen Master konfigurieren und den alten Slave und den alten Master zum Slave gegen den neuen Master verbinden. Wäre das Vorgehen so richtig? Oder muss der alte Master noch irgendwie deaktiviert werden?
Mit den Adaptern würde ich sukzessive und manuell vom alten auf den neuen Master umziehen.

Ach ja... Redis läuft auch auf dem aktuellen Master.

Gebt mir gerne euren Senf dazu :-)

Gruß Josh

[Homoran]

@Josh sagte in Multihost: neuen Master setzen und alten als Slave einsetzen:

und den alten Master zum Slave gegen den neuen Master verbinden

Das geht nicht!
ALLES muss im Master verwaltet werden.
Ein Slave sollte vorher keine Adapter installiert haben, außer ggf. admin

[Josh]

@Homoran Wie würde man denn dann bei diesem Projekt vorgehen? Neuen Master aufsetzen und alle Adapter neu installieren und konfigurieren und im Anschluss zwei neue leere Slaves aufsetzen? Das wäre natürlich exterm viel Arbeit... Hilft ein Backup des alten Masters irgendwie weiter?

[Homoran]

@Josh sagte in Multihost: neuen Master setzen und alten als Slave einsetzen:

Hilft ein Backup des alten Masters irgendwie weiter?

Im Backup des Masters sind auch die Konfigurationen der Instanzen, die auf den Slaves sind (wenn alles korrekt konfiguriert war)

Dann würde ich

• den neuen Master aufsetzen,
• beide Slaves "nackt" neu aufsetzen und an den Master binden.
• Das Backup auf dem Master wiederherstellen
• Die Instanzen, die jetzt vom Master auf den zweiten Slave sollen, dorthin verschieben.

ACHTUNG
Der Neue Master muss den gleichen Hostnamen und die gleiche IP haben, wie der alte.
Das gilt (zumindest was den Hostnamen angeht) auch für den "alten" Slave
Und natürlich müssen alle drei Hostnamen unterschiedlich sein.

(Am besten die momentanen SD-Karten als Hardwarebackup aufheben und neue SD-Karten verwenden, dann kann man jederzeit zurück)

[Josh]

@Homoran Danke für Deine Handlungsempfehlung. Wie sieht es denn mit SQL und Redis aus? Muss ich die im Master vorher neu installieren? Wenn ich das richtig sehe, sind ja nur die Configs im Backup enthalten, aber nicht die Pakete selber, oder?
Dann habe ich auf dem aktuellen Master noch eine Zigbee-Stick drin, der natürlich später auf dem alten Master/neuen Slave stecken bleibt. Aber in der Masterconfig definiert ist. Reicht es da auch den Adapter zu verschieben? Oder müssen die Zigbee-Geräte neu gepaart werden?

[Homoran]

@Josh sagte in Multihost: neuen Master setzen und alten als Slave einsetzen:

Wenn ich das richtig sehe, sind ja nur die Configs im Backup enthalten, aber nicht die Pakete selber, oder?

Das muss man auch etwas weiter differenzieren:
die Konfigs der ioBroker Installation sind im ioBroker Backup enthalten. Wenn du den backitUp Adapter nutzst, kannst du mit diesem auch weitere Daten sichern.

Entsprechend wird bei einem "einfachen" iobroker restore nur die Konfiguration wiederhergestellt und anschließend werden über den js-controller alle notwendigen Adapter mit den jeweils für dein eingestelltes Repo (hoffentlich stable) in der aktuellen Version installiert.
SQL und Redis sind keine Bestandteile von ioBroker!

Bei Zigbee bin ich leider nicht der richtige Ansprechpartner

[Josh]

@Homoran OK, dann muss ich wohl vorab SQL und Redis installieren. Die Configs werden dann über die entsprechenden Adapter wieder hergestellt.
Was passiert eigentlich, wenn ich einen Restore auf einem neuen ioBroker mit anderem Hostnamen und anderer IP mache? Kann man das dann mit ein "wenig" Handarbeit zurechtfrickeln? Ich könnte mir vorstellen, dass ich parallel den ioBroker in der VM/Container aufsetze und dann später die Slaves ganz neu anbinde.

[Homoran]

@Josh sagte in Multihost: neuen Master setzen und alten als Slave einsetzen:

Kann man das dann mit ein "wenig" Handarbeit zurechtfrickeln?

Vor dem Start von ioBroker nach dem restore ein iobroker host this ausführen und in den Instanzen, in denen z.B. die IP-Adresse des ioBrokers als callback-Adresse drin steht diese ändern

[Josh]

@Homoran Das hört sich übersichtlich schwierig an. Werde ich mal versuchen. Danke für deine Erklärungen.
Welches OS ist für ioBroker besser geeignet: Ubuntu oder Debian? Und hast du noch eine Meinung zu meinen Hardwarefragen eingangs?