Kopie von ioBroker auf einen Slave-RPI 4
-
@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: der neue PI4 mit nur PIVCCU drauf langweilen
Weshalb nicht piVCCU auf dem bestehen ioBroker-Pi 4?
Da ich den Pi 4 zu Weihnachten erhalten habe und für etwas nutzen will.
-
@paul53 sagte:
Weshalb nicht piVCCU auf dem bestehen ioBroker-Pi 4?
Bei mir war es wegen der besseren Position
-
@igor123 sagte: Da ich den Pi 4 zu Weihnachten erhalten habe und für etwas nutzen will.
Das ist ein tolles Argument, um ein komplexeres System mit mehr Fehlermöglichkeiten aufzubauen.
-
@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
ich dachte am Slave - oder was eurer Meinung nach am Sinnvollsten ist?
- alle Instanzen deinstallieren (ich habe beim letzten Test wirklich alles incl. admin deinstalliert)
Vom Master, also vom derzeit laufenden System, alle Instanzen deinstallieren?
Falls ja kann ich das nicht ohne weiteres laufen bzw. wäre mir zu unsicher dass ich es, aus welchen Grund auch immer, nicht am selben Tag zum laufen bekomme und dann stehe ich beispielsweise ohne Licht da...
-
@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Das ist ein tolles Argument, um ein komplexeres System mit mehr Fehlermöglichkeiten aufzubauen.
Ich muss gerade schmunzeln. Ich hatte hier lange auch einen secondary host 'ohne Not, nur weil es geht' laufen. Hab ich die Tage auch wieder aufgelöst. Ist ja auch ein Widerspruch zum KISS-Prinzip.
-
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Vom Master, also vom derzeit laufenden System, alle Instanzen deinstallieren?
nein!
auf dem neuen, der dann Slave werden soll
-
@thomas-braun sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Das ist ein tolles Argument, um ein komplexeres System mit mehr Fehlermöglichkeiten aufzubauen.
Ich muss gerade schmunzeln. Ich hatte hier lange auch einen secondary host 'ohne Not, nur weil es geht' laufen. Hab ich die Tage auch wieder aufgelöst. Ist ja auch ein Widerspruch zum KISS-Prinzip.
Dito!
nur weil es geht!
-
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Vom Master, also vom derzeit laufenden System, alle Instanzen deinstallieren?
Nein, es sind die voreingestellten Adapter auf dem frischen ioBroker gemeint, bevor der zum 'Nebenhost' degradiert wird.
-
@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: Da ich den Pi 4 zu Weihnachten erhalten habe und für etwas nutzen will.
Das ist ein tolles Argument, um ein komplexeres System mit mehr Fehlermöglichkeiten aufzubauen.
Naja, aber mit den neuen Pi könnte ich bspw. diverse Loggings laufen die durchaus mehr RAM benötigen würden beim abfragen.
bspw für alle Heizkörperthermostate, oder der Wetterstation oder diversen sensoren oder oder oder. -
@igor123 sagte: Vom Master, also vom derzeit laufenden System, alle Instanzen deinstallieren?
Nein, natürlich vom künftigen Slave.
-
@thomas-braun sagte:
bevor der zum 'Nebenhost' degradiert wird.
@paul53 sagte:
vom künftigen Slave.
Wie war das jetzt politisch korrekt?
Ich glaube "secondary Host" -
zweiter Nebenhorst*In
-
Ich kann mich da auch noch nicht dran gewöhnen und benutze noch Slave
@thomas-braun sagte in Kopie von ioBroker auf einen Slave-RPI 4:
zweiter Nebenhorst*In
das sind dann Nebenhostende
-
@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Ich kann mich da auch noch nicht dran gewöhnen und benutze noch Slave
@thomas-braun sagte in Kopie von ioBroker auf einen Slave-RPI 4:
zweiter Nebenhorst*In
das sind dann Nebenhostende
na gut, dann haben wir das zumindest geklärt
Also ist eine Kopie des derzeitigen PI's auf den neuen PI nicht einfach so möglich?
Oder soll ich lieber den neuen PI als aktiven Backup nutzen, dass bei Ausfall automatisch der neue PI genutzt wird? ist sowas überhaupt möglich? -
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Also ist eine Kopie des derzeitigen PI's auf den neuen PI nicht einfach so möglich?
Wozu soll das dienen? Das ist ja dann kein Multihost mehr.
Oder soll ich lieber den neuen PI als aktiven Backup nutzen, dass bei Ausfall automatisch der neue PI genutzt wird? ist sowas überhaupt möglich?
Ja, das ist auch möglich. Hab mir das auch mal angeschaut als ich den 'Nebenhostenden' rausgeworfen habe. Das ganze Setup war mir dann aber zu komplex.
-
@igor123 said in Kopie von ioBroker auf einen Slave-RPI 4:
Da ich den Pi 4 zu Weihnachten erhalten habe und für etwas nutzen will.
Na, da fallen mir aber andere Dinge ein, für die ich den noch nutzen könnte, als "nur so" einem unterbeschäftigten RPi noch einen weiteren noch mehr unterbeschäftigten RPi zur Seite zu stellen!
-
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Also ist eine Kopie des derzeitigen PI's auf den neuen PI nicht einfach so möglich?
Warum?
das ist dann kein Multihost, sonder eine eigenständige Installation
Bei einem Multihost muss und wird alles über den Admin des primären Hosts (aka Master) administriert -
@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Also ist eine Kopie des derzeitigen PI's auf den neuen PI nicht einfach so möglich?
Warum?
das ist dann kein Multihost, sonder eine eigenständige Installation
Bei einem Multihost muss und wird alles über den Admin des primären Hosts (aka Master) administriertNein nein natürlich dann auf Multihost Umstellen
nur erstmal weniger zum konfigurieren zu haben - das war mein Hintergedanke warum 1:1 kopie -
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
nur erstmal weniger zum konfigurieren zu haben
du hast nach dem wie ich es beschrieben habe gar nichts zu konfigurieren.
Du weist nach der Erstellung der Multihostumgebung über den Admin mit nur einem(?) Klick nur einen anderen Host zu -
@homoran
Ahsoo okay - dachte da wäre sonnst noch was zu machen.
na dann befolge ich mal deine Anleitung und würde mich ggf. hier nochmals rühren.Danke euch nochmals für die echt schnelle und tolle unterstützung
LG
