Monatsrückblick Januar/Februar 2026 ist online!

[Rene.Home]

das kann ich mal versuchen..Danke.. wäre schön wenn es so einfach geht

[arteck]

@Rene.Home ja ist es

alten iob stoppen
neuen auch.. muss aber frisch sein

ordner kopieren

neuen starten ..

wenn nix startet

iob host this

auf der konsole
und wieder starten und warten. log kannst du beobachten.. da werden erstmal alle adapter neu istalliert.

[Marc Berg]

Das Kopieren des Verzeichnisses ist natürlich ein valider Weg (wenn der User weiß, was er tut).

Aus meiner Sicht wäre es aber der richtige Weg gewesen, iob setup custom auf dem alten Server aufzurufen, die IP für die Objects/States DB von 192.168.178.53 zu ändern auf 127.0.0.1. Das Backup davon kann man dann problemlos auf den neuen Server einspielen, die Connection zeigt dann immer auf den lokalen Server.

EDIT: und wahrscheinlich wird die Verbindung auf die DB nach dem Kopieren immer noch auf den alten Server zeigen. Damit hat man sich dann ein Master/Slave Konstrukt geschaffen, Glückwunsch.

[Rene.Home]

@arteck das funktioniert zumal nicht... leider

[Marc Berg]

@Rene.Home sagte:

das funktioniert zumal nicht

Mach's, wie ich geschrieben habe.

EDIT: vorher am besten ioBroker nochmal neu installieren. Wer weiß, wie der Stand nun ist.

[arteck]

@Rene.Home was hat nicht funktioniert. ?? LOGS ?? in dem Ordner ist alles was iobroker braucht..

[Marc Berg]

@arteck sagte:

in dem Ordner ist alles was iobroker braucht..

...inkl. der iobroker.json, in der bei ihm bei States und Objects-DB offensichtlich die IP den alten Hosts steht.

[Rene.Home]

@Marc-Berg sagte:

Der Befehl "iob setup custom" hat die IP Adresse in der entsprechenden Configuration nicht auf 127.0.0.0 geändert. Hier stand immer noch die alte drin. Ich habe das jetzt mal via GUI geändert und den IOBroker neu gestartet... nun werde ich mal ein Backup ziehen und das dann in der neuen Instance einspielen... mal sehen was passiert

[Marc Berg]

@Rene.Home sagte:

127.0.0.0

127.0.0.1 !!!!!

Und zeigen, was du da tust.

[arteck]

@Marc-Berg sagte:

...inkl. der iobroker.json, in der bei ihm bei States und Objects-DB offensichtlich die IP den alten Hosts steht.

deshalb

iob host this

aber ohne LOG's geht nix

[Marc Berg]

@arteck sagte:

iob host this

ändert lediglich den Hostnamen. An der DB-Config wird damit nichts getan.

[Homoran]

@Rene.Home sagte:

wollte nun alle Adapter, Skripte und weiter Einrichtungen auf den neuen Server (die neue IOBroker Instance) kopieren..

Da wird nix kopiert!
Das passiert alles wie gewünscht mit dem Restore

[arteck]

@Marc-Berg und die müsste immer noch auf local host zeigen 127.0.0.1.. ausser du hast ein Multihost..

dem iobroker ist es wumpe welche ip die Maschiene hat Datentechnisch auser du hast ein Multihost.
redis ist auf localhost konfiguriert und jsonl genauso.

[Marc Berg]

@arteck sagte:

dem iobroker ist es wumpe welche ip die Maschiene hat Datentechnisch

Dem ioBroker ist es keinesfalls Wumpe, welche IP in der iobroker.json unter "Host" steht

Denn zu dieser IP verbindet er sich. Ich sprach mit keinem Wort davon, dass es erheblich sei, welche IP der Host hat.

[Homoran]

@Marc-Berg sagte:

Dem ioBroker ist es keinesfalls Wumpe, welche IP in der iobroker.json unter "Host" steht

Gilt diese Einstellung denn nicht nur für Multihost?

[Marc Berg]

@Homoran sagte:

Gilt diese Einstellung denn nicht nur für Multihost?

Nein. Wenn ich diese Einstellungen per iob setup custom (oder über den Admin) auch auf einem Singlehost verbiege, dann startet der ioBroker nicht mehr. Denn das sind die primären Einstellungen, anhand derer ioBroker weiß, wo die Datenbank ist. (und welcher Typ)

Nochmal: der TE hat auf dem alten Host die IP dest Hosts angegeben (statt 127.0.0.1). Diese Einstellung handelt man sich per Backup oder auch durch das Kopieren des Verzeichnisses auf dem neuen Host ein.

Also entweder man korrigiert vorher auf dem alten Host und spielt das danach angefertigte Backup ein, oder man wurschtelt an der iobroker.json nach Kopieren / Restore rum.

[arteck]

@Marc-Berg sagte:

Denn zu dieser IP verbindet er sich. Ich sprach mit keinem Wort davon, dass es erheblich sei, welche IP der Host hat.

jaha .. und das ist bei einer single host installation IMMER localhost.. IMMER also wumpe..
bei einer multi Host installation steht da die ip des Master (meistens) . bzw die IP wo die jsonl bzw redis läuft (und bei mir sogar die des Sentinels)

und das muss nicht zwingend die IP des Master sein....

aber das ist nicht Ziel dieses Threads..

also zurück zum Thema..

[Marc Berg]

@arteck sagte:

jaha .. und das ist bei einer single host installation IMMER localhost.. IMMER also wumpe..

Da kannst du "IMMER" noch zehn Mal groß hier hin schreiben, es stimmt halt nicht. Wenn du bei einem Singlehost die IP-Adresse in der iobroker.json von localhost/127.0.0.1 änderst auf einen ungültigen Wert, dann startet ioBroker nicht mehr.

Und wie der TE geschrieben hat, wurde die DB auf dem alten Host restored. Komisch, wo doch immer localhost genommen wird ...

also zurück zum Thema..

Leider ist genau das o.g. hier das Thema.

[arteck]

@Marc-Berg sagte:

Da kannst du "IMMER" noch zehn Mal groß hier hin schreiben, es stimmt halt nicht. Wenn du bei einem Singlehost die IP-Adresse in der iobroker.json von localhost/127.0.0.1 änderst auf einen ungültigen Wert, dann startet ioBroker nicht mehr.

warum sollte man diese adresse ändern ?? bei einer single host installation ??ausser man verlagert die Datan woanders an eine andere Maschiene...
und JA es ist logisch, dass der iobroker dann nicht mehr startet (hab nie gegenteil behauptet) den da liegen auch die Daten.. also wo ist das Problem ??

single install = localhost , ausser wenn die Daten EXTRA woanders liegen, manueller Eingriff
multihost = meistens die IP des Master, oder halt der Maschiene wo die Daten liegen

also nochmal da der TE Ersteller NUR ein single host hat liegen die Daten auf localhost..
und es ist dem restore egal. da dies auch so übernommen wird (single host)

ausser der hat da manuell was gefummelt..was ich nicht von ausgehe

[Marc Berg]

@arteck sagte:

ausser der hat da manuell was gefummelt..

Richtig, das ist mein Hinweis. Und das Gefummel kopiert man sich mit deiner Methode und /oder einem Restore auf den neuen Host. Deshalb vorher geradeziehen. Nichts anderes habe ich behauptet.