Seite 8 von 8

Re: Umzug von einem Wolf auf einen anderen

Verfasst: Do Feb 15, 2024 3:43 pm
von Mibr85
Super Sache mit der Volumensicherung :-)

Re: Umzug von einem Wolf auf einen anderen

Verfasst: Do Feb 15, 2024 4:01 pm
von Robert_Mini
Super Sache! Überraschung gelungen!

Danke und lg
Robert

Re: Umzug von einem Wolf auf einen anderen

Verfasst: Sa Feb 17, 2024 6:37 pm
von StefanW
Hi zusammen,

die neue Backup Funktionen sind seit gestern bei den DEV Testern.

Es gibt noch eine Überraschung:

Der Restore beherrscht nun die Migration von der Modellreihe 3xx/9xx auf die Modellreihe 3500


Bedeutet, es können 99,9% restauriert werden. Wegen den 0.1% bitte die Anleitung im Wiki lesen (an der noch gearbeitet wird), auch hinsichtlich der Reihenfolge und der Vermeidung von Doppelbetrieb zweier Server mit beinahe identischen Einstellungen, Logiken, Verbindungen (insbesondere via IP, die anderen lassen sich ja abstecken).

Damit ist der Grund dieses Threads, zumindest für diese Paarung 3xx/9xx auf 3500 gelöst.

Alle Details hier im Thread zum neuen Backup V4: viewtopic.php?p=54307#p54307


lg

Stefan

Re: Umzug von einem Wolf auf einen anderen

Verfasst: So Feb 18, 2024 7:41 pm
von tobi42
Wow!!! Einfach eine schöne Überraschung. Freue mich auf einen baldigen Test. Vielen Dank!

Re: Umzug von einem Wolf auf einen anderen

Verfasst: Do Feb 22, 2024 9:09 pm
von StefanW
Hallo zusammen,

da nun die IP 8 seit gestern verfügbar ist, die nun auch die Migration von 3xx/9xx auf 3500 unterstützt:

BITTE ABWARTEN bis wir die Informationen im Wiki veröffentlicht haben. Das dauert noch ein wenig, weil es kann im Detail eine Menge sein, die zu beachten ist und ich möchte Euch bitten, uns noch ein oder zwei Tage zu geben, bis wir das fertig geschrieben, rewieved und freigeschaltet haben.

Ich werde dazu informieren.

Merci

Stefan

Re: Umzug von einem Wolf auf einen anderen

Verfasst: Fr Feb 23, 2024 11:22 pm
von StefanW
Hallo zusammen,

es ist heute Abend bei Nachtests ein Problem aufgetreten mit der Migration von Docker Volumes von 3xx/9xx auf 3500. Es wird vermutlich bald einen Fix (als IP 8.1 oder 9) dazu geben.

Weitere Informationen hier: viewtopic.php?f=64&t=4982&p=54471#p54471

Ich bitte weiterhin die Nutzer mit Migration abzuwarten, bis wir alle Informationen dazu im Wiki zusammen getragen haben und mit Nachtests verifiziert. Wird nicht mehr lange dauern, aber ist leider ein wenig komplex.

lg

Stefan

Re: Umzug von einem Wolf auf einen anderen

Verfasst: Sa Feb 24, 2024 4:05 pm
von StefanW
Hallo Foristen, es gibt einen

Fix zur IP 8 mit IP 8.1 für Migration von Docker Volumes von 3xx/9xx auf 3500.

Mit IP 8 wurde ein Leistungsmerkmal eingeführt, um Docker Volumes sichern und wiederherstellen zu können.

Leider gab es einen Fehler bei der Migration von Docker Volumes in der speziellen Konstellation von Timberwolf Servern der Modellreihe 3xx/9xx auf Timberwolf Server der Modellreihe 3500 der dazu führt, dass man die umgezogenen Volumes unter Umständen nicht nutzen konnte und dann von Hand per SSH hätte transferieren müssen (Dateirechte).
Für diesen Fall stellen wir ab sofort einen FIX als IP 8.1 zur Verfügung.

Dieses Upgrade auf IP 8.1 muss nur dann installiert werden, wenn Sie in der nächsten Zeit Docker Volumes von 3xx/9xx auf 3500 migrieren möchten. Ansonsten ist der Fix dann auch in der IP 9 enthalten, an der bereits gearbeitet wird (und auf die man sich freuen darf).

lg

Stefan

Re: Umzug von einem Wolf auf einen anderen

Verfasst: So Feb 25, 2024 3:37 pm
von StefanW
Verehrte Foristen, es ist vollbracht, wir haben soeben die

Artikelserie zu Datensicherung / Wiederherstellung und Migration
im Wiki Online gestellt.


Link: https://elabnet.atlassian.net/l/cp/FctE2Hm6

Bitte durchsehen ob das alles so verständlich und nachvollziehbar ist.


==> Wir wären sehr für Tests dankbar mit Rückmeldung

An diesem Projekt haben wir in drei Stufen über mehrere Monate parallel zu den anderen Entwicklungen gearbeitet. Ich hoffe es findet Eure Zustimmung und erleichtert Euch die Migration - den Umzug von einem Wolf auf den anderen Wolf - ganz maßgeblich.

Bitte nicht vom Umfang der Dokumentation abschrecken lassen, wir waren hier nur gründlich mit allen Informationen, in den üblichen Fällen ist alles viel einfacher, insbesondere wenn alter und neuer Server nicht parallel an den selben Bussystemen und aktiven IP-Protokollen betrieben werden sollen

Für den einfacheren Fall gibt es eine Schnellanleitung. Trotzdem bitte alles durchlesen, damit jeder für sich entscheiden kann, auf welche Themen er mehr achten muss und welche ihn nicht betreffen.


lg

Stefan

Re: Umzug von einem Wolf auf einen anderen

Verfasst: Mo Feb 26, 2024 2:41 pm
von carpi2001
Hallo Stefan,

dann mache ich mal den Anfang. Ich habe gerade anhand der Anleitung im Wiki erfolgreich meinen 960er Timberwolf auf den 3500er migriert. Folgende Kleinigkeiten sind mir dabei aufgefallen:

Fahren Sie alle Interfaces von IP-Protokollen (Modbus TCP, MQTT, HTTP-/Rest-API, IFFFT) runter

Was genau ist hier gemeint? Ein Interface ist ja eigentlich eth0. Vermutlich soll das das Subsystem deaktiviert werden; das habe ich zumindest gemacht.

Stecken Sie KNX und 1-Wire ab

Muss KNX abgesteckt werden, oder reicht es auch, das KNX Subsystem zu deaktivieren. 1-Wire kann man ja nicht deaktivieren, oder?
Ggfs. spart man sich einen Gang zum Verteilerschrank....

Netzwerkeinstellungen des Quellservers ändern

Zusätzlicher Hinweis für Fritz!Box (hat nichts mit dem Timberwolf zu tun): Wird eine feste IP über DHCP vergeben und soll der neue Server diese IP übernehmen, muss zuerst für den alten Server eine neue Adresse konfiguriert und der alte Server dann neu gestartet werden. Sonst kann die alte IP Adresse bei der Fritz!Box nicht beim neuen Server als feste Adresse hinterlegt werden. Evtl. meckert die Fritz!Box dann immer noch, dass die IP Adresse in Benutzung ist. Dann halt erstmal beim neuen Server die IP statisch konfigurieren.

Container

War bei mir kein großes Ding, da ich nur Portainer und MQTT als Container habe. Wenn man hier mehr Container hat, muss man sich für den Umzu etwas Zeit einplanen, da doch einiges an Handarbeit erforderlich ist.

MQTT Broker

Die bisherige Einstellung für Verschlüsselung war - zumindest bei mir - "Automatische Anpassung an MQTT Broker". Damit war keine Verbindung möglich. Erst mit Verschlüsselung "Deaktiviert" klappte die Verbindung.

1-Wire

Alle meine (41) Sensoren wurden gefunden und liefern Daten (obwohl sie vorher auf drei Stränge verteilt werden und jetzt parallel geschaltet sind). Im Dashboard steht bei Qualität noch 50%, ich nehme aber an, dass das aufgrund der Zeit ist, wo 1-Wire noch nicht physikalisch angeschlossen war.

Sonstiges

Ich und meine Frau hatten noch Bookmarks auf Grafana, die müssen natürlich auch auf den neuen Server umgestellt werden.

Insgesamt kann ich sagen, dass der Umzug weitestgehend reibungslos verlaufen ist und die Downtime minimal war.
Es ist natürlich nicht mit einem Firmwareupdate einer Fritz!Box zu vergleichen, ein bisschen Zeit muss man sich schon einplanen, mit der Anleitung im Wiki war aber alles kein Problem.

SG
Bernd

Re: Umzug von einem Wolf auf einen anderen

Verfasst: Mo Feb 26, 2024 7:51 pm
von StefanW
Hallo Bernd,

vielen lieben Dank für Deine Rückmeldung, ist sehr wertvoll für uns und die Community
carpi2001 hat geschrieben: Mo Feb 26, 2024 2:41 pm
Fahren Sie alle Interfaces von IP-Protokollen (Modbus TCP, MQTT, HTTP-/Rest-API, IFFFT) runter
Was genau ist hier gemeint? Ein Interface ist ja eigentlich eth0. Vermutlich soll das das Subsystem deaktiviert werden; das habe ich zumindest gemacht.
Bei allen IP basierten Protokollen (bis auf ekey) gibt es eine Möglichkeit das virtuelle Interface des Subsystem zu deaktivieren, hier bei MQTT:

Bild

carpi2001 hat geschrieben: Mo Feb 26, 2024 2:41 pmStecken Sie KNX und 1-Wire ab
Muss KNX abgesteckt werden, oder reicht es auch, das KNX Subsystem zu deaktivieren. 1-Wire kann man ja nicht deaktivieren, oder?
Ggfs. spart man sich einen Gang zum Verteilerschrank....

Lieber abstecken. Weil wenn man KNX deaktiviert, dann aktiviert sich das beim nächsten Neustart wieder. Hat man nun den Quellserver am gleichen KNX wie den Zielserver und es gibt einen Stromausfall oder man bootet den Quellserver neu, dann wird dessen KNX wieder aktiv und kommuniziert mit dem Bus, parallel zum geklonten Zielserver. Besser abstecken

carpi2001 hat geschrieben: Mo Feb 26, 2024 2:41 pmNetzwerkeinstellungen des Quellservers ändernContainer
War bei mir kein großes Ding, da ich nur Portainer und MQTT als Container habe. Wenn man hier mehr Container hat, muss man sich für den Umzu etwas Zeit einplanen, da doch einiges an Handarbeit erforderlich ist.

Da nun die Docker Volumes übernommen werden, sollten es nur eine Handvoll Parameter sein und bei komplexeren Netzwerkeinstellungen zwei Hände voll. Muss man dann vom alten Server abschreiben und übernehmen (oder Copy Paste mit zwei Portainer Fenstern)

Geht nicht anders, weil andere Architektur braucht ohnehin andere Images.

carpi2001 hat geschrieben: Mo Feb 26, 2024 2:41 pmSonstiges
Ich und meine Frau hatten noch Bookmarks auf Grafana, die müssen natürlich auch auf den neuen Server umgestellt werden.

Danke, guter Hinweis, nehme ich noch auf

carpi2001 hat geschrieben: Mo Feb 26, 2024 2:41 pmInsgesamt kann ich sagen, dass der Umzug weitestgehend reibungslos verlaufen ist und die Downtime minimal war. Es ist natürlich nicht mit einem Firmwareupdate einer Fritz!Box zu vergleichen, ein bisschen Zeit muss man sich schon einplanen, mit der Anleitung im Wiki war aber alles kein Problem.
Ist ja auch kein Firmware-Update sondern ein fast-klonen eines Servers mit bis zu mehreren tausend Objekten, zig-tausend Verknüpfungen über zig Protokolle hinweg, Logik und mehrere hundert Millionen Log- und Zeitserien-Einträge und die Volumes.

Dafür meine ich, geht es echt schnell, weil 99,99% gehen automatisch.

lg

Stefan