Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[hmanfred]

Mein ioBroker läuft unter Proxmox in einem Container.

Nun habe ich eine neue virtuelle Maschine mit Debian 11 installiert und dort die ioBroker Grundinstallation. Per Backitup-Adapter habe ich dann einen Backup (lag auf dem NAS) meiner ioBroker Installation restored. Das lief auch problemlos.

Nach dem Restore ist nun der neue ioBroker nicht mehr erreichbar. Anpingen lässt sich die Maschine, der Web-Zugriff sagt aber "Die Website ist nicht erreichbar192.168.1.122 hat die Verbindung abgelehnt.".

Der einzige wesentliche Unterschied ist, dass die Maschine, aus der der Backup stammt eine andere IP hat. Kann es daran liegen? Wie komme ich hier weiter?

Hier noch das LOG vom Restore:

[DEBUG] [iobroker] Start ioBroker Restore ...
[DEBUG] [iobroker] iobroker controller daemon is not running
[DEBUG] [iobroker] host.ioBroker OK.
[DEBUG] [iobroker] Removing current installation of iobroker.admin
[DEBUG] [iobroker] removed 22 packages in 5s
[DEBUG] [iobroker] 37 packages are looking for funding
[DEBUG] [iobroker] run `npm fund` for details
[DEBUG] [iobroker] Removing current installation of iobroker.backitup
[DEBUG] [iobroker] removed 124 packages in 4s
[DEBUG] [iobroker] 30 packages are looking for funding
[DEBUG] [iobroker] run `npm fund` for details
[DEBUG] [iobroker] Removing current installation of iobroker.discovery
[DEBUG] [iobroker] removed 45 packages in 3s
[DEBUG] [iobroker] 18 packages are looking for funding
[DEBUG] [iobroker] run `npm fund` for details
[DEBUG] [iobroker] host.ioBroker Clear all objects and states...
[DEBUG] [iobroker] clean 142 objects...
[DEBUG] [iobroker] clean 102 states...
[DEBUG] [iobroker] host.ioBroker done.
[DEBUG] [iobroker] host.ioBroker Processed 0/15747 objects
...
[DEBUG] [iobroker] host.ioBroker Processed 15600/15747 objects
[DEBUG] [iobroker] 15747 objects restored.
[DEBUG] [iobroker] host.ioBroker Processed 0/13315 states
...
[DEBUG] [iobroker] host.ioBroker Processed 13200/13315 states
[DEBUG] [iobroker] 13315 states restored.
[DEBUG] [iobroker] host.ioBroker Upload user file "sayit.0/tts.userfiles/gong.mp3
...
[DEBUG] [iobroker] host.ioBroker Upload user file "vis.0/senderlogos/wdr5.png
[DEBUG] [iobroker] Reinstalling adapter "admin" from "iobroker.admin@6.2.22"
[DEBUG] [iobroker] added 75 packages in 14s
[DEBUG] [iobroker] 22 packages are looking for funding
[DEBUG] [iobroker] run `npm fund` for details
[DEBUG] [iobroker] Reinstalling adapter "backitup" from "iobroker.backitup@2.4.12"
[DEBUG] [iobroker] added 74 packages in 10s
[DEBUG] [iobroker] 26 packages are looking for funding
[DEBUG] [iobroker] run `npm fund` for details
[DEBUG] [iobroker] Forced restore - executing setup ...
[DEBUG] [iobroker] System successfully restored!
[DEBUG] [iobroker] ioBroker Restore completed successfully
[EXIT] 0

[Homoran]

@hmanfred sagte in ioBroker nach Restore nicht mehr erreichbar:

ioBroker Restore completed successfully

wie lange hast du gewartet?
nach dieser Meldung werden erst alle Adapter installiert. Da darf keine weiterer Eingriff erfolgen bis das fertig ist

[hmanfred]

@homoran
Hmm... ich weiss jetzt nicht mehr ob ich länger als eine Viertelstunde gewartet habe.

Ich habe jetzt mal das iobroker Verzeichnis umbenannt und eine neue Grundinstallation gemacht. Dann den Restore.
Die Meldung "Restore and Restart completed successfully!!" steht nun im Backitup.

• Der Versuch in einen anderen Tab zu wechseln wird vom Browser mit der Warnung versehen "...Einige Daten wurden nicht gespeichert. Verwerfen?".
• Rückkehr ins Einstellungsmenü des Backitup geht ohne Warnung.
• Klick auf den "Instanzen"-Tab: nur die drei Basisinstanzen "Admin", "Backitup" und "Discovery" werden aufgelistet. "Admin" und "Discovery" ohne ihre Icons (Zahnrad bzw. Fernglas)
• Klick auf Setup von Admin. Folgendes Bild:
  
  Darunter alles weiß, kein Setup wird gezeigt.

Ich lasse die VM jetzt mal ein paar Stunden blubbern. Vielleicht dauern die Prozesse nach dem Restore ja wirklich seeeeehr lange.

[Homoran]

@hmanfred sagte in ioBroker nach Restore nicht mehr erreichbar:

Vielleicht dauern die Prozesse nach dem Restore ja wirklich seeeeehr lange.

je nach Leistungsfähigkeit der Hardware gerne mal 1h und mehr.
hast du mal den Browsercache geleert?

Aber vielleicht ist das wieder ein Container-Ding

[hmanfred]

Jetzt habe ich den Hinweis "Einige Daten wurden nicht gespeichert. Verwerfen?" beim Wechsel in einen anderen (ioBroker)Tab ignoriert und OK geklickt. Ergebnis:

[Homoran]

@hmanfred zu der Meldung gibt es einen Thread.
was kommt denn bei dem aufgeforderten Vorgehen raus?

unmittelbar bei einem Restore oder dem (n) ersten Aufruf(en) könnte das aber normal sein.

[hmanfred]

@homoran

​ [2022-10-05T13:00:31.057Z] ws connection error: CLOSE_ABNORMAL
error @ :8081/socket.io/socket.io.js:68
​ [2022-10-05T13:00:31.058Z] Start reconnect 0
7821.a0b80bed.chunk.js:12 [2022-10-05T13:00:31.058Z] ws connection error: CLOSE_ABNORMAL
(anonymous) @ 7821.a0b80bed.chunk.js:12
7821.a0b80bed.chunk.js:12 [2022-10-05T13:00:31.120Z] Start reconnect 0
​ [2022-10-05T13:00:31.147Z] Try to connect
7821.a0b80bed.chunk.js:12 [2022-10-05T13:00:31.150Z] Try to connect
​ WebSocket connection to 'ws://192.168.1.122:8081//adapter/backitup?sid=1664974831147' failed: 
SocketClient.connect @ :8081/socket.io/socket.io.js:140
​ [2022-10-05T13:00:33.193Z] Start reconnect 1
​ [2022-10-05T13:00:33.194Z] ws connection error: CLOSE_ABNORMAL
error @ :8081/socket.io/socket.io.js:68
​ [2022-10-05T13:00:33.194Z] Reconnect is already running 1
7821.a0b80bed.chunk.js:12 [2022-10-05T13:00:34.163Z] No READY flag received in 3 seconds. Re-init
(anonymous) @ 7821.a0b80bed.chunk.js:12
socket.io.js:396 WebSocket connection to 'ws://192.168.1.122:8081/?sid=1664974831150&name=admin' failed: WebSocket is closed before the connection is established.
SocketClient.close @ socket.io.js:396
7821.a0b80bed.chunk.js:12 [2022-10-05T13:00:34.163Z] Start reconnect 1
7821.a0b80bed.chunk.js:12 [2022-10-05T13:00:34.164Z] ws connection error: CLOSE_ABNORMAL
(anonymous) @ 7821.a0b80bed.chunk.js:12
27821.a0b80bed.chunk.js:12 [2022-10-05T13:00:34.164Z] Reconnect is already running 1
​ [2022-10-05T13:00:34.205Z] Try to connect
7821.a0b80bed.chunk.js:12 [2022-10-05T13:00:35.164Z] Try to connect
socket.io.js:140 WebSocket connection to 'ws://192.168.1.122:8081/?sid=1664974835164&name=admin' failed: 

usw. Das geht dann endlos so weiter.

Noch etwas - die Konsole der VM zeigt folgende Meldung (keine Ahnung wann die entstand):

[Homoran]

@hmanfred sagte in ioBroker nach Restore nicht mehr erreichbar:

die Konsole der VM

@hmanfred sagte in ioBroker nach Restore nicht mehr erreichbar:

läuft unter Proxmox in einem Container.

was denn nun?

@hmanfred sagte in ioBroker nach Restore nicht mehr erreichbar:

folgende Meldung

hab ich keine Ahnung von

[hmanfred]

@homoran sagte in ioBroker nach Restore nicht mehr erreichbar:

@hmanfred sagte in ioBroker nach Restore nicht mehr erreichbar:

die Konsole der VM

@hmanfred sagte in ioBroker nach Restore nicht mehr erreichbar:

läuft unter Proxmox in einem Container.

was denn nun?

Sorry für die späte Antwort. Ich bin momentan zu sehr in anderen Dingen eingespannt...

Die Prodiktivmaschine läuft in einem Container. Der Restore wurde in einer "echten" VM gemacht. Dort steht auch die oben erwähnte Meldung.

Die VM hat inzwischen eine Uptime von fast 9 Tagen. Das WebUi von ioBroker ist nicht erreichbar.
ioBroker status sagt:

Ich hoffe, jemend hier kann mir - mit meinem begrenzten Linux-Wissen - helfen, dem Problem auf die Spur zu kommen.

[Homoran]

@hmanfred was sagt iobroker list instances ?

[hmanfred]

@homoran sagte in ioBroker nach Restore nicht mehr erreichbar:

@hmanfred was sagt iobroker list instances ?

Außer admin und backitup stehen alle auf "disabled". Das ist wohl die richtige Spur...

Nach "iobroker start all" laufen sie nun alle.

Web ist auf Port 8082 erreichbar, admin auf 8081 aber nicht.

Liegt das an der nicht passenden IP-Aresse? Beim admin-Adapter steht (mit "list instances") "bind: 192.168.1.20". Das ist die IP der Produktivmaschine. Die mit dem Restore hat eine andere, mit der ich sie allerdings versuche anzusprechen.

[hmanfred]

Läuft! :grin:

Ursache war offensichtlich ein falsches Setup des Admin-Adapters in der Produktivmaschine. Dort war der Zugriff nicht auf 0.0.0.0 sondern auf die IP der Maschine engestellt - die Hilfe zum Adapter sagt, dass unbedingt 0.0.0.0 gelassen werden soll. Weiß der Deibel, warum das verstellt war.

Nach Änderung ein Backup gemacht, in der neuen Maschine engespielt - läuft.

Danke @Homoran - du hast mich letztendlich auf die richtige Spur gebracht.

[Homoran]

@hmanfred sagte in ioBroker nach Restore nicht mehr erreichbar:

Außer admin und backitup stehen alle auf "disabled".

keine Nacherzählungen, immer zeigen!

https://forum.iobroker.net/topic/51555/hinweise-für-gute-forenbeiträge/1

[hmanfred]

@homoran sagte in ioBroker nach Restore nicht mehr erreichbar:

keine Nacherzählungen, immer zeigen!
Nun denn:

Hier war unter "IP-Adresse" die Adresse des Hosts (bei mir 192.168.1.20) eingestellt, was beim Backup/Restore übernommen wurde und offensiochtlich zu den Problemen führte.

[hmanfred]

Leider läuft aber nun noch nicht alles.

Nach Shutdown der alten Produktivmaschine habe ich bei der neuen die IP auf die altbekannte (192.168.1.20) umgestellt. Alle Adapter starten. Nur VIS läuft nicht - ich komme weder an die Weboberfläche noch in den Editor. Klick auf den Schraubenschlüssel zeigt:

Irgendwelche Tipps?

[DJMarc75]

@hmanfred

iobroker upload all

[crunchip]

@hmanfred sagte in ioBroker nach Restore nicht mehr erreichbar:

ich bei der neuen die IP auf die altbekannte (192.168.1.20) umgestellt.

Wo, in der VM, statisch?

[hmanfred]

@crunchip sagte in ioBroker nach Restore nicht mehr erreichbar:

@hmanfred sagte in ioBroker nach Restore nicht mehr erreichbar:

ich bei der neuen die IP auf die altbekannte (192.168.1.20) umgestellt.

Wo, in der VM, statisch?

Richtig, in der /etc/network/interfaces

[hmanfred]

@djmarc75 sagte in ioBroker nach Restore nicht mehr erreichbar:

@hmanfred

iobroker upload all

Funktioniert! Danke!!!