Slave Adapter fehlen beim Multihost System aufsetzen

[Tottbeck]

N'abend zusammen,

ich hatte bisher einen Raspi3 (1GB RAM) alleine als iobroker-Instanz im Einsatz.
Dieser soll von einem Raspi4 (4GB RAM) entlasten werden der dann als Master fungiert, während der Raspi3 zum Slave degradiert werden soll.
Wie hier beschrieben https://www.iobroker.net/docu/index-24.htm?page_id=3068&lang=de
hat das mit den Kommandos "sudo iobroker multihost enable" auf dem Master und
"sudo iobroker multihost browse" und "sudo iobroker multihost connect" auf dem Slave prinzipiell auch easy funktioniert.

Auf dem Master werden mit nun beide Host angezeigt und ich kann den host auch auswählen.

Allerdings werden mir immer nur die Instanzen vom Master angezeigt, vom Slave sehe ich keine Adapter.
Der Speicherbedarf wird korrekt vom Slave ausgegeben, es ist aber nur ein Prozess aktiv
Unter Adapter kann die jeweils installierten Adapter sehen (je nach ausgewähltem host), also beim Raspi3 auch alle installierten Versionen.

Beide System sind noch per SSH erreichbar. Hier der Log vom Raspi3

host.Raspi3	2021-03-15 20:30:17.897	warn	does not start any instances on this host
host.Raspi3	2021-03-15 20:30:17.884	info	4 instances found
host.Raspi3	2021-03-15 20:30:15.329	info	added notifications configuration of host
host.Raspi3	2021-03-15 20:30:15.238	info	connected to Objects and States
host.Raspi3	2021-03-15 20:30:15.002	info	ip addresses: 192.168.178.199 2003:e0:f1a:3749:43db:f1e9:47b5:66ce fe80::f3c4:5997:245a:4cf0 10.8.0.1 fe80::b3ba:6551:aa01:a902
host.Raspi3	2021-03-15 20:30:15.001	info	hostname: Raspi3, node: v12.20.1
host.Raspi3	2021-03-15 20:30:15.000	info	Copyright (c) 2014-2021 bluefox, 2014 hobbyquaker
host.Raspi3	2021-03-15 20:30:14.991	info	iobroker.js-controller version 3.2.16 js-controller starting
host.Raspi3	2021-03-15 20:30:11.316	info	terminated
host.Raspi3	2021-03-15 20:30:11.183	info	All instances are stopped.
host.Raspi3	2021-03-15 20:30:11.182	info	instance system.adapter.tuya.0 terminated with code 156 (START_IMMEDIATELY_AFTER_STOP)
host.Raspi3	2021-03-15 20:30:10.966	info	instance system.adapter.history.0 terminated with code 156 (START_IMMEDIATELY_AFTER_STOP)
host.Raspi3	2021-03-15 20:30:10.821	info	instance system.adapter.alexa2.0 terminated with code 156 (START_IMMEDIATELY_AFTER_STOP)
tuya.0	2021-03-15 20:30:10.534	info	(1235) Terminated (START_IMMEDIATELY_AFTER_STOP): Without reason
host.Raspi3	2021-03-15 20:30:10.499	info	instance system.adapter.telegram.0 terminated with code null ()
host.Raspi3	2021-03-15 20:30:10.498	warn	instance system.adapter.telegram.0 terminated due to SIGTERM
host.Raspi3	2021-03-15 20:30:10.498	info	instance system.adapter.frontier_silicon.0 terminated with code null ()
host.Raspi3	2021-03-15 20:30:10.497	warn	instance system.adapter.frontier_silicon.0 terminated due to SIGTERM
host.Raspi3	2021-03-15 20:30:10.393	info	instance system.adapter.shelly.0 terminated with code null ()
host.Raspi3	2021-03-15 20:30:10.393	warn	instance system.adapter.shelly.0 terminated due to SIGTERM
host.Raspi3	2021-03-15 20:30:10.392	info	instance system.adapter.shuttercontrol.0 terminated with code null ()
host.Raspi3	2021-03-15 20:30:10.392	warn	instance system.adapter.shuttercontrol.0 terminated due to SIGTERM
host.Raspi3	2021-03-15 20:30:10.391	info	instance system.adapter.javascript.0 terminated with code null ()
host.Raspi3	2021-03-15 20:30:10.390	warn	instance system.adapter.javascript.0 terminated due to SIGTERM
host.Raspi3	2021-03-15 20:30:10.387	info	instance system.adapter.iot.0 terminated with code null ()
host.Raspi3	2021-03-15 20:30:10.386	warn	instance system.adapter.iot.0 terminated due to SIGTERM
host.Raspi3	2021-03-15 20:30:10.201	info	instance system.adapter.g-homa.0 terminated with code null ()
host.Raspi3	2021-03-15 20:30:10.200	warn	instance system.adapter.g-homa.0 terminated due to SIGTERM
host.Raspi3	2021-03-15 20:30:10.200	info	instance system.adapter.web.0 terminated with code null ()
host.Raspi3	2021-03-15 20:30:10.199	warn	instance system.adapter.web.0 terminated due to SIGTERM
host.Raspi3	2021-03-15 20:30:10.199	info	instance system.adapter.mihome.0 terminated with code null ()
host.Raspi3	2021-03-15 20:30:10.198	warn	instance system.adapter.mihome.0 terminated due to SIGTERM
host.Raspi3	2021-03-15 20:30:10.198	info	instance system.adapter.email.0 terminated with code null ()
host.Raspi3	2021-03-15 20:30:10.197	warn	instance system.adapter.email.0 terminated due to SIGTERM
host.Raspi3	2021-03-15 20:30:10.000	info	instance system.adapter.discovery.0 terminated with code null ()
host.Raspi3	2021-03-15 20:30:09.999	warn	instance system.adapter.discovery.0 terminated due to SIGTERM
host.Raspi3	2021-03-15 20:30:09.998	info	instance system.adapter.systeminfo.0 terminated with code null ()
host.Raspi3	2021-03-15 20:30:09.998	warn	instance system.adapter.systeminfo.0 terminated due to SIGTERM
host.Raspi3	2021-03-15 20:30:09.996	info	instance system.adapter.admin.1 terminated with code null ()
host.Raspi3	2021-03-15 20:30:09.994	warn	instance system.adapter.admin.1 terminated due to SIGTERM
host.Raspi3	2021-03-15 20:30:08.975	info	stopInstance system.adapter.telegram.0 killing pid 1222
host.Raspi3	2021-03-15 20:30:08.974	info	stopInstance system.adapter.frontier_silicon.0 killing pid 1203
history.0	2021-03-15 20:30:08.790	info	(1089) Terminated (START_IMMEDIATELY_AFTER_STOP): Without reason
host.Raspi3	2021-03-15 20:30:08.904	info	stopInstance system.adapter.shelly.0 killing pid 1202
host.Raspi3	2021-03-15 20:30:08.903	info	stopInstance system.adapter.shuttercontrol.0 killing pid 1196
host.Raspi3	2021-03-15 20:30:08.901	info	stopInstance system.adapter.web.0 killing pid 1195
host.Raspi3	2021-03-15 20:30:08.883	info	stopInstance system.adapter.systeminfo.0 killing pid 1141
host.Raspi3	2021-03-15 20:30:08.882	info	stopInstance system.adapter.mihome.0 killing pid 1126
host.Raspi3	2021-03-15 20:30:08.880	info	stopInstance system.adapter.javascript.0 killing pid 1115
host.Raspi3	2021-03-15 20:30:08.879	info	stopInstance system.adapter.iot.0 killing pid 1104
host.Raspi3	2021-03-15 20:30:08.876	info	stopInstance system.adapter.g-homa.0 killing pid 1074
host.Raspi3	2021-03-15 20:30:08.874	info	stopInstance system.adapter.email.0 killing pid 1059
host.Raspi3	2021-03-15 20:30:08.871	info	stopInstance system.adapter.discovery.0 killing pid 1035
host.Raspi3	2021-03-15 20:30:08.869	info	stopInstance system.adapter.alexa2.0 killing pid 1015
host.Raspi3	2021-03-15 20:30:08.864	info	stopInstance system.adapter.admin.1 killing pid 1004

Scheinbar wurden alle Instanzen auf dem Raspi3 abgeschaltet wegen "SIGTERM". Muss ich ich erst von Hand auf dem Raspi4 installieren und die Config rüber kopieren? Ich hatte das so verstanden (oder gehofft), dass der Master die bereits vorhanden Slave-Instanzen anzeigt und man die einfach unter Server dem gewünschten host zuteilt und so z.B. die Instanzen vom Master auf den Slave umziehen kann.
Ich habe erstmal den Slave per "iobroker setup custom" wieder entkoppelt. Der funktioniert dann auch wieder normal.
Ist der Raspi3 mit seinem 1GB so überfordert, so dass ich keinen Mulithost mehr (fehlerfrei) aktivieren kann?

[Homoran]

@tottbeck
ganz falsche Herangehensweise!

alles wird über den Master installiert und verwaltet.
auf einem neuen slave darf nichts außer Controller und evtl. admin drauf sein!

Backup vom pi 3 ziehen und auf den Pi4 spielen.
pi3plattmachen minimale Installation aufspielen und an den master binden
dann gewünschten instanzen vom pi4 auf den pi3 verlagern

[Tottbeck]

@homoran
Danke für den Hinweis.
Auf dem Raspi3 nutze ich 8 GPIOs für Relaiskarten und zyklisch wird per Bluetooth der benachbarte PV-Wandler ausgelesen. D.h. die Sachen müssen zwingend auf dem Raspi3 bleiben.
Wenn die Relais nicht funktionieren, geht z.B. auch meine Klingel nicht mehr, deswegen muss ich da etwas vorsichtiger vorgehen, sonst bekomme ich von der Regierung Ärger
Die GPIOs habe ich über den Systeminfo-Adapter definiert und nutze die per Blockly.
D.h. die Systeminfo muss auf dem Raspi3 laufen aber das Script kann auch auf dem Raspi4 laufen, da der die Systeminfo-Objekte kennt, korrekt?
Sind da Latenzzeiten zu befürchten oder ist das vernachlässigbar ?

[Homoran]

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

die Systeminfo muss auf dem Raspi3 laufen

aber über den pi4 dort installiert werden

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

das Script kann auch auf dem Raspi4 laufen, da der die Systeminfo-Objekte kennt,

solange das script nicht auf die Hardware zugreifen muss, ja!

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Sind da Latenzzeiten zu befürchten oder ist das vernachlässigbar ?

ich denke das sollte nicht merklich sein

[Tottbeck]

@homoran
Tja, jetzt habe ich schon wieder etwas komisches hinbekommen.
Ich habe das Raspi3-Backup in den Raspi4 eingespielt. Der Raspi3 war dabei noch eigenständig aktiv, also nicht als Slave verbunden.
Der admin vom Raspi 4 war danach auch nach längere Wartezeit nicht erreichbar. Laut "iobroker list instances" ist auf dem Raspi4 alles wie erwartet vorhanden, aber als host Raspi3 eingetragen, der ja (noch) nicht verbunden ist.
Ich habe alle Instanzen außer den Admin auf dem Raspi4 gestoppt (falls das Probleme machen sollte), das änderte aber nichts.
Dann habe ich noch einen neuen admin hinzugefügt (host Raspi4), der ging auch nicht
Plötzlich ging der neue admin, aber warum auch immer ist der Raspi3 plötzlich der Master und der Raspi4 der Slave. Ich weiß nicht wie ich das hinbekommen habe. Auf dem Raspi3 habe ich nie ein "iobroker multihost enable" gemacht.
Ich kann jetzt zwar wie gewünscht die Instanzen auf dem Raspi3/Raspi4 verteilen und aktivieren, aber die Datenbank liegt auf dem leistungsschwächeren Raspi3

pi@Raspi4:/opt/iobroker $ iobroker multihost status
No configuration change needed.


Multihost discovery server: disabled
Discovery authentication:   enabled
Persistent activation:      disabled
Objects:                    file on 192.168.178.199
States:                     file on 192.168.178.199

pi@Raspi3:~ $ iobroker multihost status
No configuration change needed.


Multihost discovery server: disabled
Discovery authentication:   enabled
Persistent activation:      disabled
Objects:                    file on 192.168.178.199
States:                     file on 192.168.178.199

[Tottbeck]

Was ich noch nicht erwähnt hatte:
Aufgefallen ist mir das erst, nachdem ich ein "iobroker host this" auf dem Raspi4 versucht habe, welches ich scheinbar direkt nach restore des Raspi3-Backups hätte machen müssen, wie ich danach gelesen habe.
Da kam die Meldung ich müsste den iobroker stoppen auch nachdem ich ein "iobroker stop" gemacht habe, weil der Raspi4 da scheinbar schon als Slave mit dem Raspi3 verbunden war.

Und noch weitere Fragen (sorry)
Ist das ein großes Problem wenn die Datenbank auf dem Raspi3 bleibt bzgl Auslastung, ansonsten wäre ich so schon fast glücklich Z.B. bei VIS-Diagramme (im Raspi4) müssen dann alle Daten vom Raspi3 gesaugt werden, korrekt ?
Noch eine Frage: Kann ich Blockly-Scripte auch auf Master/Slave aufteilen. Benötige ich dann zwei javascript-Instanzen? Es geht mir da um Ausfallsicherheit. Würde der Slave das Blocky/Instanzen noch weiter abarbeiten, wenn der Master ausfällt oder ist dann Feierabend ?

Danke für Euere Geduld.

[Homoran]

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Der Raspi3 war dabei noch eigenständig aktiv, also nicht als Slave verbunden.

nicht gut!
dadurch läuft die gleiche Installation doppelt, und wenn du nicht nach dem restore und vor dem start iobroker host this gemacht hast kann genau das passieren.

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Ist das ein großes Problem wenn die Datenbank auf dem Raspi3 bleibt bzgl Auslastung,

leider ja.
1GB RAM und bis zu 100MB je Instanz kommt dann bei etwa 10-15 Instanzen an die Grenzen

Den Rest hast du ja auch schon erkannt.

• erst den Pi4 komplett aufsetzen
• dann erst einen neuen "leeren" pi3 an den Pi4 binden
  • ggf ist es mit iobroker setup custom noch eindeutiger
  • beide Systeme müssen unterschiedliche Hostnamen haben, da darüber die Zuordnungen stattfinden

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Kann ich Blockly-Scripte auch auf Master/Slave aufteilen. Benötige ich dann zwei javascript-Instanzen?

Ja und ja

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Es geht mir da um Ausfallsicherheit.

das nutzt nichts, da der slave ohne Master nicht funktioniert

[Tottbeck]

@homoran
Danke für Deine Klasse Unterstützung.

Bzgl der Speicherauslastung.
Vom ungewollten Master Raspi3 habe ich fast alle Instanzen auf den Raspi4 geschoben (was super umgesetzt ist), so dass der jetzt mit 3 Prozessen deutlich entspannter läuft.

Datenträger verfügbar: 42.1 %, gesamte RAM-Nutzung: 317 MB / Frei: 66% = 611 MB [Host: Raspi3 - 3 Prozesse]

RAM sollte also reichen. Ich habe mir eher um die CPU-Last Sorgen gemacht, da der Raspi4-Slave, der ja die meisten Aufgaben hat, nun ständig auf die Master-Datenbank im Raspi3 zugreifen muss.
Bisher habe ich aber keine negativen Auswirkungen bemerkt.

Beim Slave Raspi4 scheint es übrigens noch einen Fehler bei der Speicherberechnung zu geben, den 317% frei hätte ich gerne

Datenträger verfügbar: 83.4 %, gesamte RAM-Nutzung: 1638 MB / Frei: 317% = 2.928 MB [Host: Raspi4 - 20 Prozesse]

Achso noch was: Muss das "backitup" zwingend auf dem Master laufen ? Zumindest schmeisst der mir auf dem Raspi4-Slave als host einen Fehler.

[Homoran]

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Muss das "backitup" zwingend auf dem Master laufen ?

Muss nicht unbedingt, aber die zu speichernden Daten sind ja alle auf dem Master (bis auf Daten, die von einer Hardware außerhalb des ioBrokers gespeichert werden)

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Zumindest schmeisst der mir auf dem Raspi4-Slave als host einen Fehler.

1.) welchen genau?
2.) dann ist ggf. etwas nicht sauber konfiguriert

[Tottbeck]

@homoran sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

1.) welchen genau?
2.) dann ist ggf. etwas nicht sauber konfiguriert

Gestartet...
[DEBUG] [iobroker] - host.Raspi4 3107 states saved
[DEBUG] [iobroker] - host.Raspi4 3711 objects saved
[ERROR] [iobroker] - host.Raspi4 Cannot pack directory /opt/iobroker/node_modules/iobroker.js-controller/tmp/backup: Error: EACCES: permission denied, open '/opt/iobroker/backups/iobroker_2021_03_17-17_43_29_backupiobroker.tar.gz'
[ERROR] [iobroker] - host.Raspi4 Cannot pack directory /opt/iobroker/node_modules/iobroker.js-controller/tmp/backup: Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed
[DEBUG] [iobroker] - done

Lag wohl an den Rechte für den backups-Ordner, ich habe die von 755 auf 775 (+group write) gesetzt.

[Homoran]

chso, ich dachte bei der Installation kam der Fehler

[Tottbeck]

@homoran, @simatec
Ich mache das hier nochmal auf, weil ich jetzt beim Backup-Wiederherstellen ein Problem habe.
Siehe https://forum.iobroker.net/post/776412

Ich habe den BackItUp auf dem Slave (Raspi4) laufen, der Backups auf meinem NAS ablegt (4,1MB, + 150kB Javascript).
Ich bin mir nicht sicher wie ich die Hosttyp-Einstellung gemacht habe, kann ich ja leider nicht mehr nachschauen. Auf dem Master hatte ich (meine ich) keine BackItUp-Instanz, aber die für das BackUp relevanten Sachen sind fast ausschließlich auf dem Slave.

Nach einem Absturz kann ich das BackUp nur noch über die Konsole wiederherstellen.

Auf dem Slave geht es per Konsole überhaupt nicht. Auf dem Master (Raspi3) prinzipiell schon, aber die BackUp sind im Slave-Ordner bzw auf dem NAS. Wenn ich das Backup in den lokalen Master-Ordner einspiele, funktioniert das Restore scheinbar, aber danach sind keine Instanzen zu sehen auf beiden hosts. iobroker ist aktiv aber admin usw laufen nicht.
Ein Altes Backup (bevor ich BackItUp benutzte habe glaube ich) vom 17.03.2021 (das passt genau zu diesem alten Thread) eingespielt. Das funktioniert, aber dann fehlt mir natürlich ein ganzes Jahr.
Da habe ich dann BackItUp-Adapter im alten Backup aktiviert und versucht das neue Backup darüber einzuspielen. Aber auch ohne Erfolg. Was kann ich noch versuchen ?

[Homoran]

@tottbeck ich lese mir den alten Thread nicht nochmals durch.
Aber der backitup gehört auf den Master. dabei werden alle States und Einstellungen des Slaves mit gesichert.

Lediglich für Instanzen, die weitere Software verwenden benötigt man backitup auf dem Slave

[Tottbeck]

@homoran
Danke, ja da würde er wohl besser hingehören, bringt mir jetzt aktuell allerdings nichts. Hatte die Frage "Muss das "backitup" zwingend auf dem Master laufen ?" damals gestellt, deswegen der alte Thread) aber deine Antwort dazu wohl fehlinterpretiert.
Ich hatte angenommen das BackItUp funktional gleich arbeitet und daher den performanteren Slave gewählt.

Die meisten Instanzen auf dem Slave, aber die Daten dazu sind dann ja trotzdem auf dem Master.
Die BackUps sehen von der Größe her vollständig aus, zumindest so groß wie vorherigen Backups vom Master.
Aber ich müsste doch dann wenigstens das Backup, das der Slave erstellt hat dort auch wiederherstellen können.
Das mache ich aber mit einer neuen unkonfigurierten BackItUp-Instanz. Muss ich da vorher noch etwas einstellen z.B. bzgl. host-typ? (Slave habe ich schon probiert).

[Homoran]

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Aber ich müsste doch dann wenigstens das Backup, das der Slave erstellt hat dort auch wiederherstellen können

da kann aber nichts drin sein, wenn der Multihost korrekt aufgesetzt wurde.
Alle Informationen liegen auf dem Master.

lediglich die Instanzen, die vor der Einbindung ins Multihost System auf dem Hosts waren (üblicherweise admin, discovery) könnten gesichert werden.

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Muss ich da vorher noch etwas einstellen z.B. bzgl. host-typ? (Slave habe ich schon probiert).

kannte ich gar nicht. Gab es früher wohl nicht.
Hab gerade nachgesehen. Bei mir steht da single, obwohl es der Master ist.
Restore der Slaves hat damit aber trotzdem geklappt.
Muss mich dazu mal schlau machen.

[Tottbeck]

@homoran
Danke: Bei "host-typ" war ich mir jetzt auch nicht sicher, dann gab es damals wohl noch nicht.
Der Multihost hat zumindest 1 Jahr anstandslos funktioniert, trotz der nicht idealen Master/Slave Zuordnung.

Die Größe der Backups hat sich damals nach Umstieg auf BackItUp (17.03.21) quasi nicht verändert. Vorher habe ich das Backup direkt per cronjob ausgeführt. Daher dachte ich das Backup ist komplett.

iobroker_2022_03_13-02_00_10_name__backupiobroker.tar.gz	4.508.030	13.03.22 01:59	-a--
iobroker_2022_03_12-02_00_10_name__backupiobroker.tar.gz	4.506.209	12.03.22 01:59	-a--
..
iobroker_2021_03_19-02_00_10_name__backupiobroker.tar.gz	3.548.369	19.03.21 01:59	-a--
iobroker_2021_03_18-02_00_10_name__backupiobroker.tar.gz	3.525.277	18.03.21 01:59	-a--
iobroker_2021_03_17-17_55_54_name__backupiobroker.tar.gz	3.527.346	17.03.21 17:55	-a--
2021_03_17-01_01_03_backupiobroker.tar.gz	3.514.860	17.03.21 01:00	-a--
2021_03_16-01_01_13_backupiobroker.tar.gz	3.508.618	16.03.21 01:02	-a--
2021_03_15-01_01_04_backupiobroker.tar.gz	3.508.132	15.03.21 01:00	-a--
2021_02_11-01_01_04_backupiobroker.tar.gz	3.631.483	10.02.21 21:42	-a--

Die letzte backup.json ist auch immerhin 27MB groß und enthält soweit ich das sagen kann alle Objekte.
Wenn ich z.B. die Module, wo ich noch viel gemacht habe, daraus extrahieren können, wäre mir auch schon viel geholfen.

[Tottbeck]

Die states.json und objects.json vom Master habe ich noch manuell gesichert.
Damit hätte ich doch alle Objekte wiederhergestellt, oder ?
Die javascripts sind getrennt wiederherstellbar.
Dann müsste ich "nur" noch die Adaptereinstellungen und das vis wiederherstellen.(Ich versuche gerade nachzuvollziehen, was ich in dem Jahr alles verändert habe)

Das wiederherstellen über BackItUp klappt ja leider nicht. Vermutlich weil dabei der iobroker gestoppt wird und die Master/Slave Verbindung fehlt.

[DEBUG] [iobroker] Start ioBroker Restore ...
[ERROR] [iobroker] Stop iobroker first!
[DEBUG] [iobroker] ioBroker Restore completed successfully
[EXIT] 99 **** Restore was canceled!! ****

Gerade nochmal probiert, wenn ich das Backup auf dem Master einspiele (egal ob über Backitup oder Konsole), rödelt er zwar 20 Minuten durch, aber danach ist keine Instanz mehr vorhanden. (logs.txt)

[Homoran]

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Das wiederherstellen über BackItUp klappt ja leider nicht. Vermutlich weil dabei der iobroker gestoppt wird und die Master/Slave Verbindung fehlt.

nein!
weil die notwendigen Informationen nicht auf den Slave gehören, sondern auf den Master

[Tottbeck]

@homoran sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

weil die notwendigen Informationen nicht auf den Slave gehören, sondern auf den Master

Jetzt habe ich es doch noch iwie hinbekommen.
Ich hatte mich schon dabei gesehen wie ich die ganzen Änderungen wieder einbringe.

Ich habe nochmal auf dem Master das manuell rüberkopierte Backup per Konsole wiederhergestellt.
Diesmal hatte er komischerweise aber die Instanzen per "iob list instances" angezeigt, allerdings deaktiviert. Den admin per konsole aktiviert, danach durfte ich die Instanzen erst alle vom Master auf den Slave schupsen (der Master hätte die überhaupt nicht gepackt.)
D.h. es läuft wieder.

BackItUp läuft jetzt auf dem Master. Der gerade angelegte Backup ist (fast) genauso groß wie vorher. D.h. der Inhalt des Backups war vorher schon vollständig aber leider nicht (so einfach) wiederherstellbar.

@Homoran: Danke für Deine Geduld.

[Homoran]

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Diesmal hatte er komischerweise aber die Instanzen per "iob list instances" angezeigt, allerdings deaktiviert

das ist normal. Unter Backitup kann man auswählen "Starte alle Instanzen"

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

BackItUp läuft jetzt auf dem Master.