In diesem Kapitel wird beschrieben, wie Daten und Einstellungen von einem Timberwolf Server auf einen anderen Timberwolf Server migriert werden können. Dies ist z.B. bei einem Wechsel auf ein neueres Modell des Timberwolf Servers notwendig.
Derzeit wird nur die Migration von den Modellreihen 3xx / 9xx / 25xx / 26xx auf die Modellreihe 3500 unterstützt und nur, wenn der Massenspeicher auf dem Zielserver groß genug für die Migration ist.
Zusätzlich benötigen Sie für die Migration den ElabNET USB Backup Stick (u.a. weil dieser Stick von ElabNET zertifiziert ist, automatisch erkannt wird, über das richtige Dateisystem verfügt und weil dessen Speicherplatz die Migration bei größeren Datenmengen unterstützt).
Dieses Dokument bezieht sich auf die Firmware V4 sowie zur IP 1 zur V 4.1 - oder neuer.
Das Funktionsmodul Datensicherung V 4 verfügt über eine Unterstützung zur Migration von Einstellungen und Daten zwischen Servern, auch basierend auf verschiedenen Modellreihen.
Um die Individualität des Zielservers (ID, lokale Crypto-Parameter usw.) und den Datenschutz zu erhalten und damit es keine Konflikte mit dem lokalen Netz des Zielservers nach der Migration gibt, wird aus Sicherheitsgründen kein vollständiger Klon erzeugt.
Deshalb empfehlen wir Ihnen die Prüfung nachfolgend dargestellter Punkte. Bitte lassen Sie sich nicht vom Umfang erschrecken, das meiste davon lässt sich zügig abarbeiten und einiges muss nur in besonderen Fällen beachtet werden.
In normalen Fällen ist das befolgen der Schnellanleitung ausreichend. Bitte prüfen Sie anhand der Angaben, ob dies auf Ihren Fall zutrifft oder Sie nach der vollständigen Anleitung vorgehen müssen. Wir raten Ihnen, vor Beginn der Migration einmal alles durchzulesen.
Quellserver ist derjenige Timberwolf Server, auf dem die Datensicherung angefertigt wurde
Zielserver ist derjenige Timberwolf Server, auf dem die Datensicherung wiederhergestellt wird
Migration ist der Vorgang, bei dem eine Datensicherung auf einem Zielserver wiederhergestellt wird, dessen TWS ID nicht die selbe ist wie die ID des Quellservers.
Migration zwischen Modellreihen ist eine Migration, bei welcher Quell- und Zielserver aus verschiedenen Modellreihen stammen. Unterstützt wird ausschließlich
eine Migration von Servern der Modellreihe 3xx/9xx auf die Modellreihe 3500 (ab IP 8.1 zur V4 oder neuer)
eine Migration von Servern der Modellreihe 25xx / 26xx auf die Modellreihe 3500 (ab IP 1 zur V 4.1 oder neuer)
ElabNET USB Backup Stick: Dies ist ein zertifizierter USB Stick, der mit allen Modellreihen des Timberwolf Servers und mit jeder Firmware ab V 3.5.1 genutzt werden kann. Dieser Stick wird zwingend für eine Migration benötigt, da nur mit diesem externen Datenträger eine Migration durchführbar ist. Dieser USB Stick ist nicht mit einem Server verbunden. Sie können einen Stick für die Datensicherung mehrerer Server (hintereinander) verwenden, also auch mehrere USB Sticks an einem Server anschließen.
Die Wiederherstellung einer Datensicherung auf einen Zielserver bedeutet, die meisten bestehenden Daten und Einstellungen auf dem Zielserver zu überschreiben. Dies ist unumkehrbar, sofern Sie über keine extern gespeicherte und aktuelle Datensicherung des Zielservers verfügen.
Achten Sie unbedingt darauf, dass Sie eine vollständige und lesbare Datensicherung des Zielservers haben, bevor Sie diesen Zurücksetzen und / oder darauf eine Datensicherung wiederherstellen.
Löschen Sie einen Quellserver nicht, solange Sie nicht die Migration auf den Zielserver komplett fertiggestellt und geprüft haben.
Im Einzelnen bedeutet eine Wiederherstellung aus einer Datensicherung:
Serverfunktionen und Docker Container werden suspendiert: Fast alle Subsysteme werden bei Beginn der Wiederherstellung gestoppt. Dies betrifft auch alle APPs und Docker Container. Der betreffende Timberwolf Server stoppt damit alle Services, die Kommunikation über Bussysteme und IP-Protokolle mit externen Geräten, führt keine Logiken mehr aus, speichert keine letzten Werte im Dispatcher sowie keine Logs und Zeitserien und wird nach der Wiederherstellung automatisch NEU gestartet.
Konfiguration: ALLE Einstellungen und Konfigurationen aller Funktionsmodule und Subsysteme werden zurückgesetzt und aus der Sicherung wiederhergestellt
Objekte: Alle Objekte und deren letzten bekannten Objektwerte sowie Verknüpfungen werden zurückgesetzt und aus der Datensicherung wieder hergestellt. Die Timberwolf VISU ließt bei jedem Start die letzten Objektwerte aus dem System für eine sofortige Darstellung. Im Falle einer Wiederherstellung werden womöglich sehr alte Werte vom Quellserver restauriert, die mit dem automatischen Start - eines in der Datensicherung enthaltenen VISU Profils - angezeigt werden.
Logiken: ALLE Logiken inkl. Persistenzstatus werden zurückgesetzt und aus der Datensicherung wieder hergestellt. Ein gegebenenfalls konfigurierter Doktormodus einer Logikzelle wird nur dann aus der Sicherung wieder hergestellt, wenn die betreffende Logikzelle zum Zeitpunkt der Datensicherung in der Betriebsart “Persistenz” betrieben wurde. Der Grund dafür ist, dass während der Wiederherstellung der Logik-Service gestoppt wird und damit werden alle Einstellungen zum Doktormodus zurück gesetzt, außer eine Logikzelle ist persistent.
Reverse-Proxy und Grafana: Die Konfiguration des Reverse-Proxys und Grafana Konfiguration wird komplett aus der Sicherung ersetzt.
Manuell installierte Grafana-Plugins müssen mit dem Zielsystem kompatibel sein. Andernfalls kann es nach der Wiederherstellung zu einem Startfehler von Grafana kommen.
Timberwolf VISU: Alle Einstellungen der Timberwolf VISU wie VISU Profile, VISU Instanzen und Widgets werden komplett zurückgesetzt und durch die Sicherung ersetzt. Mit Ende der Migration startet der Server neu und die VISU Instanzen werden neu gestartet und lesen die letzten verfügbaren Werte aus dem Objektverteiler aus. Diese Werte stammen jedoch aus der Sicherungsdatei und können stark veraltet sein. Weisen Sie die Nutzer der VISU darauf hin. Mit Aufnahme des Betriebes und Empfang aktueller Werte sollte sich Aktualität einstellen, sofern der Zielserver mit den selben Geräten verbunden ist und alle Transaktionen auf allen Subsystemen wie zuvor funktionieren.
Nutzer-VPN: Alle Einstellungen zum Nutzer-VPN wie Zertifikate und Profile werden komplett aus der Sicherung ersetzt. Netzwerkeinstellungen des Quellservers werden von der Sicherung nicht erfasst und damit auch nicht auf dem Zielserver wiederhergestellt. Womöglich befindet sich der Zielserver auch in einem völlig anderen Netzwerk. Der Nutzer-VPN Server könnte dadurch nicht mehr von außen erreichbar sein und - je nach Einstellungen - könnte auch die interne Rückroute nicht oder nicht passend konfiguriert sein.
KNX-Einstellungen: Die KNX Programmierung des Stacks mit BAU-Schlüssel und KNX Seriennummer sowie alle im lokalen Projektspeicher befindlichen, zuvor importierten ETS Projekte werden gelöscht und mit den Einstellungen und Projekten aus der Sicherung ersetzt. Eine erneute KNX Programmierung ist zwar nicht nötig, allerdings übernimmt der Zielserver damit die Programmierung des KNX Stacks vom Quellserver. Dies bedeutet auch, dass alle Physikalischen Adressen (“PA”) übernommen und mit Restart aktiv am Bus sind. Eine parallele Nutzung von Quell- und Zielserver bei gleichzeitigem Anschluss beider Server am KNX Bus sollten Sie daher vermeiden. Entweder der eine, oder der andere Server ist am selben KNX System angeschlossen.
Sollten Sie den Zielserver in einer anderen KNX Umgebung nutzen, dann empfehlen wir, den Zielserver erst dann am dortigen KNX Bus anzuschließen, wenn die passende Programmierung mit der ETS vorgenommen wurde. Bitte denken Sie daran, dass hierdurch KNX Objekte gelöscht oder anders belegt (mit anderen GAs, DPT) werden, die intern bereits (zu einem anderen Zweck am Quellserver) verknüpft waren. Gehen Sie daher jedes KNX Objekt einzeln durch und vergleichen GA Zuordnungen, DPT und alle internen Verknüpfungen.
Mit der Rücksicherung wird die KNX Seriennummer des KNX Stacks vom Quell-Server übernommen. Ab IP 1 zur V 4.1 wird die Seriennummer bei jedem Reboot zurückgesetzt auf die SN, die für den Ziel-Server gültig ist. Dies kann beim Programmieren der PA über die ETS zu Irritationen führen, wenn die ETS noch die “alte” SN des Quellservers im Projekt gespeichert hat. Sofern die SN zwischen Stack und ETS-Applikation unterschiedlich ist, empfehlen wir, bei Neuprogrammierung der PA, die Methode “über Programmierknopf” zu nutzen und nicht “über Seriennummer”. Nach einem erfolgten Programmiervorgang auf den Ziel-Server (egal ob PA oder nur Applikaton) ließt die ETS die SN ohnehin jeweils erneut ein und ist damit wieder korrekt für den Zielserver im KNX Projekt gespeichert. Weitere Details hierzu unter https://elabnet.atlassian.net/wiki/spaces/TSKB/pages/2443182081/Insider+Preview+1#FIX-R%C3%BCcksetzen-KNX-Stack-Seriennummer-nach-Migration-(durch-Boot).
1-Wire Einstellungen: Mit der Wiederherstellung werden ALLE 1-Wire Einstellungen zu Busmaster und 1-Wire Geräten inkl. angelegter Transaktionen aus der Sicherung restauriert. Damit können nach der Migration Busmaster und Geräte angezeigt werden, die auf dem Zielserver nicht existent sind bzw. nicht an diesem angeschlossen sind. Zum Beispiel wird der in der Modellreihe 3xx / 9xx enthaltene Busmaster bei Wiederherstellung auf einem Zielserver anderer Modellreihen auf Grundlage der Informationen der Sicherungsdatei angezeigt und muss manuell gelöscht werden. Gleiches gilt für 1-Wire Geräte die am Zielserver nicht mehr - über welchen Busmaster auch immer - genutzt werden, um das Polling nicht existenter Geräte zu sparen. Bei iButtons ist darauf zu achten, dass diese für bestimmte 1-Wire Kanäle definiert sind, die nach einer Migration am Zielserver womöglich dort nicht existieren.
Netzwerk Einstellungen und IP basierte Protokolle: Netzwerk Einstellungen werden nicht gesichert und damit auch nicht wiederhergestellt. Wir wollen damit vermeiden, dass durch eine Rücksicherung, insbesondere auf einen anderen Server (der sich womöglich parallel zum Quellserver im gleichen oder in einem völlig anderen Netzwerk befindet) Netzwerk-Einstellungen auf den Zielserver übertragen werden, die anschließend zu Netzwerk- und Zugriffsproblemen führen könnten, mit denen niemand rechnet. Daher werden Netzwerkeinstellungen nicht gesichert und bleiben durch die Migration auf dem Zielserver unangetastet. Dies erlaubt es unter anderem, den Zielserver parallel zum Quellserver zu betreiben und auf beide Server gleichzeitig administrativ zugreifen zu können. Mit dem automatischen Reboot nach erfolgter Migration starten alle Dienste mit der Ausführung entsprechend der aus der Sicherung übernommener Konfiguration. Dies bedeutet jedoch, dass IP basierte Dienste wie Modbus TCP, HTTP-/Rest-API, MQTT, IFTTT und ekey mit der IP-Konfiguration des Zielservers starten, die sich, je nach Ausführung der Migration, von der des Quellservers unterscheidet. Die über IP angesprochenen Geräte und Services sind hierauf womöglich nicht angepasst (dies betrifft auch Router und Firewalls) und es besteht die Gefahr des doppelten Ansprechens - wenn der Quellserver parallel noch aktiv ist. Bitte beachten Sie daher unsere Empfehlungen zur “Planung einer Sicherung für Migration” und zu den unten angegebenen “Schritten nach erfolgter Migration”.
Bitte beachten Sie, dass im Falle eines Rücksetzens auf Auslieferzustand, die Netzwerkeinstellungen auf DHCP zurückgesetzt werden.
Aufzeichnungen: Alle Aufzeichnungen in Logs, Zeitserien und Logicscope (Doktormodus Aufzeichnung) werden zurück gesetzt und komplett aus der Sicherung ersetzt.
Lizenzinformationen: Informationen zu Wartungsverträgen und Produktkäufe sind ausschließlich in der Timberwolf Cloud unter der jeweiligen ID gespeichert. Diese werden durch eine Migration nicht automatisch angepasst. Bitte klären Sie mit dem ElabNET Support, welche Form von Umzug / Anpassung für Ihren Fall möglich ist.
Systeminformationen des Nutzers: Im Timberwolf Server können benutzerspezifische Informationen hinterlegt werden. Diese werden gesichert und bei einer Migration vom Zielserver übernommen. Falls in diesen Systeminformationen Angaben gemacht sind, die zum Quell- aber nicht zum Zielserver passen, kann dies nach der Migration am Zielserver zu Irritationen führen.
APP-Konfigurationen des Nutzers: Im Timberwolf Server können APPs installiert worden sein. Diese Informationen sind in der Konfig-Datenbank des Servers enthalten. Bei einer Wiederherstellung aus einer Datensicherung, wird die komplette Komfig-Datenbank wiederhergestellt. Sofern sich diese gesicherte Konfiguration unterscheidet von derjenigen, die auf dem Zielserver angelegt ist, wird nur die Konfiguration aus der Datensicherung übernommen. Evt. abweichende APP Konfigurationen des Zielservers werden dabei gelöscht. Es könnten hierdurch verwaiste APP Datenvolumes entstehen, dies ist im folgenden Abschnitt beschrieben. Wenn Sie dies vermeiden möchten, dann setzen Sie den Server vor der Wiederherstellung einer Datensicherung auf Auslieferzustand zurück. Bitte beachten Sie auch die Backup-Funktionen der APPs (insbesondere Comet VISU und Edomi).
Docker Volumes und TWS APP Daten Volumes: Alle bei der Sicherung mit eingeschlossenen Docker Volumes und TWS APP Daten Volumes werden wiederhergestellt. Bereits auf dem Server vorhandene Docker Volumes und TWS APP Daten Volumes mit derselben Benennung werden komplett ersetzt.
Docker Volumes, die vor der Migration bereits auf dem Zielserver vorhanden waren UND nicht in der Datensicherung enthalten sind, werden bei der Wiederherstellung nicht angetastet (soweit nicht durch Rücksetzen auf Auslieferzustand gelöscht)
ALLE TWS APP Daten Volumes die vor der Wiederherstellung bereits auf dem Timberwolf Server vorhanden waren UND nicht in der Datensicherung enthalten sind, werden bei der Wiederherstellung nicht angetastet. Falls in der Konfigurationsdatenbank der Datensicherung APPs nicht enthalten sind, die jedoch bei Rücksicherung auf dem Server aktiv waren, dann sind anschließend nur die APPs verfügbar, die in der Konfig-DB der Datensicherung enthalten waren. Dadurch könnten APP Daten Volumes auf dem Server verbleiben, die nicht mit einer APP verbunden sind (z.B. wenn Sie seit der Datensicherung Edomi installiert haben und nun eine Rücksicherung vornehmen, welche nicht die APP Edomi enthält, dann werden die Informationen zur APP Edomi auch nicht mehr hergestellt, das vormals genutzte APP Daten Volume der zwischenzeitlichen APP Edomi kann aber auf der Platte verbleiben und ist damit verwaist.
Hinweis: Es kann möglich sein, dass man aus Portainer dieses verwaiste Volume zu einem Docker Container, z.B. SSH mappen und wieder darauf zugreifen kann.
Benutzerkonten: Lokale und verbundene globale Benutzerkonten inkl. der Passwort-Hashes werden aus der Sicherung restauriert, wobei das lokale Konto “admin” auf Werkseinstellungen zurückgesetzt wird (bitte zusätzlichen Hinweis unten beachten). Da der Zielserver ein anderes “Salz” benutzt für das Hashen der Passwörter, schlagen alle Logins mit anderem Benutzerkonten (außer “admin”) nach der Wiederherstellung fehl. Alle anderen Benutzer müssen das Passwort erneut anlegen.
Globale Benutzerkonten: Benutzerkonten vom Typ Elab ID, die ZUVOR für die Anmeldung am Zielserver freigeschaltet waren, können auch nach der Migration zur Anmeldung genutzt werden, SOFERN die Datenschutz-Einstellungen dies erlauben (Aktivierung Timberwolf Cloud & Elab ID) UND zum Anmeldezeitpunkt eine Verbindung zur Timberwolf Cloud besteht.
Neustart nach Wiederherstellung: Der Timberwolf Server wird nach der Wiederherstellung automatisch neu gestartet. Mit diesem Start werden alle Services und Dienste mit der aus der Sicherung übernommenen Konfiguration gestartet.
Hauszugang über ekey: Durch die Migration auf den Zielserver, spätestens mit der Umschaltung des Betriebes auf den Zielserver, kann die Nutzbarkeit von ekey Home oder ekey Multi ausfallen insofern ausfallen, weil sich die IP-Adresse des Zielserver ändern könnte und die Einstellungen des ekey cvLAN-Converters anzupassen ist. Achten Sie darauf, sich nicht auszuschließen, falls die Ansteuerung einer Türe über den Timberwolf Server erfolgt. der von der Migration betroffen ist.
Nur mit ElabNET USB Stick möglich: Eine Wiederherstellung von einem anderen Server kann ausschließlich mit dem “ElabNET Backup USB Stick” vorgenommen werden. Ein Umstecken einer SD- oder µSD Karte wird nicht unterstützt, da die IDs der jeweiligen Karte fest mit dem Quellserver verknüpft sind.
Prüfung auf lesbare Sicherungsdateien auf dem USB Stick: Wir empfehlen, nach jeder vorgenommener Datensicherung, den ElabNET USB Backup Stick daraufhin zu prüfen, ob die Sicherungsdateien auch lesbar sind. Bitte betätigen Sie nach Abschluss einer Datensicherung auf den Stick die Taste
[USB Speichergerät sicher entfernen] und warten die Rückmeldung ab, entfernen dann erst den Stick, warten ein paar Sekunden und stecken den Stick anschließend wieder ein und prüfen, ob die Datensicherung(en) auf dem Stick soweit lesbar sind, dass die Informationen zu diesen Datensicherungen angezeigt werden.
Rücksetzen Admin Passwort: Das Passwort des Benutzerkontos "admin" wird bei der Wiederherstellung automatisch zurücksetzt auf dasjenige Passwort, das sich auf dem Geräteetikett des ZIELSERVERS befindet. Dieses Etikett sollte sich seitlich oder unten am Zielserver befinden. Prüfen Sie - BEVOR Sie mit der Migration beginnen - dass Sie dieses Passwort auf dem Geräteetikett lesen können. Führen Sie diese Migration nicht aus, falls Sie dieses Passwort JETZT NICHT VORLIEGEN haben, weil Sie sich danach womöglich nicht mehr anmelden können.
Diese Schnellanleitung gilt für einfache Migrationen bei Austausch eines Servers ohne Besonderheiten. Bitte lesen Sie jedoch alles unten durch, bevor Sie sich entscheiden, nur nach der Schnellanleitung vorzugehen. Auf jeden Fall benötigen Sie das Passwort des Admin Kontos vom Aufkleber des Zielservers.
Quellserver updaten: Nehmen Sie am Quellserver ein Update auf Firmware IP 8.1 zur V4 oder neuer vor. Wenn Sie einer Lizenz benötigen, fragen Sie hierzu unter service at elabnet dot de unter Angabe beider Server IDs an. Machen Sie sich Notizen zu Netzwerkkonfiguration und allen Docker Containern und deren Netzwerk-Konfiguration, da diese nicht übernommen werden.
IP Protokolle, APPs und Container stoppen: Fahren Sie alle Interfaces von IP-Protokollen (Modbus TCP, MQTT, HTTP-/Rest-API, IFFFT) runter. Stoppen Sie APPs im Systemmonitor und Docker Container in Portainer.
Bussysteme abstecken: Stecken Sie KNX und 1-Wire ab
Datensicherung ausführen: Stecken Sie den USB Stick an und nehmen die Sicherung vor, schließen Sie alle APP Data Volumes und Docker Volumes ein, die Sie weiterhin nutzen wollen
Netzwerkeinstellungen des Quellservers ändern: Vermutlich ist es am Besten, wenn der Zielserver die gleichen Netzwerkeinstellungen erhält, die am Quellserver aktiv waren. Damit es keine Kollisionen gibt, stellen Sie den Quellserver auf eine andere IP um (auch durch Zuweisung per DHCP in der Fritzbox).
Zielserver auf Auslieferzustand zurück setzen und Update ausführen: Wenn der Server nicht fabrikneu ist, dann setzen Sie diesen auf Auslieferzustand zurück, damit haben Sie den maximalen Platz auf der SSD und es gibt keinen Merge mit anderen Docker Volumes usw.
Anschließend nehmen Sie ein Update auf Firmware IP 8.1 zur V4 oder neuer vor. Wenn Sie einer Lizenz benötigen, fragen Sie hierzu unter service at elabnet dot de unter Angabe beider Server IDs an.
Migration durchführen: Schließen Sie nun den USB Stick am Zielserver an und führen die Wiederherstellung durch
Netzwerkeinstellung an Quellserver anpassen: Passen Sie die Netzwerkeinstellungen so an, dass diese dem Quellserver entsprechen (den Sie vorher auf eine andere IP umgestellt haben). Insbesondere bei Verwendung von MacVLAN müssen Sie das genau gleich einrichten. Damit sollten alle IP-Dienste störungsfrei anlaufen.
Docker Container laden und instantiieren: Nehmen Sie nun Ihre zuvor anhand des Quellservers angefertigten Notizen der Docker Container und dessen Netzwerkeinstellungen und richten die Container einer nach dem anderen neu ein und passen die Netzwerkeinstellungen entsprechend an. Die wiederhergestellten Docker Volumes können Sie einfach anhängen, so dass die durch die Migration übernommenen Konfiguration und Daten einfach weiter genutzt werden können.
Bussysteme anschließen und Protokolle hochfahren: Schließen Sie nun die Bussysteme an und fahren Sie alle IP-Protokolle hoch. “Ghost-Busmaster” vom Quellserver (insbesondere der eingebaute aus 3xx/9xx) löschen. Passen Sie iButtons an den neuen Busmasterkanal an. Alles prüfen
Logiken und Verknüpfungen starten: Starten Sie spätestens jetzt womöglich vor der Sicherung angehaltene Logiken und aktiveren ggfls. den Doktormodus wieder.
Elab ID: Trennen Sie in der Benutzerverwaltung die jeweiligen Elab ID Konten und verbinden diese anschließend über die Schaltfläche “Bestehende Elab ID mit diesem Server nutzen” neu (hierfür sind die jeweiligen Passwörter anzugeben).
Lokale Benutzerkonten: Alle lokalen Benutzerkonten (bis auf admin) sind auf dem Zielserver vor Nutzung erst zu reaktivieren. Dies kann nur der Benutzer "admin" vornehmen, hierbei muss für jedes weiterhin zu nutzende lokale Benutzerkonto das Passwortes neu vergeben werden.
Nutzer-VPN prüfen: Überprüfen Sie das Nutzer-VPN. Wenn Sie die Netzwerkeinstellungen am Zielserver identisch eingerichtet haben, wie diese zuvor am Quellserver nützlich waren, dann sollte dieses weiterhin ohne Probleme nutzbar sein.
TWS VISU: Wenn alle Protokolle, Bussysteme und Logiken funktionieren, dann sollten Sie nun die VISU Instanzen starten, sofern nicht bereits erfolgt. Falls die VISU Clients sich nicht mit dem Zielserver verbinden, dann setzen Sie in den lokalen VISU Client Einstellungen jeweils den Cache zurück (dies initiiert einen neuen Schlüsselaustausch mit dem Zielserver für das VISU Protokoll)
Weitere Informationen entnehmen Sie bitte der folgenden detaillierten Anleitung.
Datensicherung Zielserver (opt.): Mit Migration werden Einstellungen und Daten des Zielservers aus der Datensicherung ersetzt. Dieser Vorgang ist unumkehrbar. Je nachdem, welche Daten und Einstellungen sich auf dem Zielserver befinden, ist es empfehlenswert, zuerst eine Datensicherung des Zielservers auf einen externen Datenträger vorzunehmen. Hierzu ist der ElabNET USB Backup Stick notwendig. Auf dem selben Stick können Sie eine Sicherung des Zielservers ablegen, als auch die Sicherung des Quellservers. Bei der Wiederherstellung zeigt Timberwolf Server stets die ID und die Modellreihe an, von der eine Datensicherung vorgenommen wurde.
Zurücksetzen des Zielservers (opt.): Ggfls. möchten Sie den Zielserver vor der Migration auf den Auslieferzustand zurücksetzen, um jegliche Einstellungen und Daten zu löschen. Dies ist dann empfehlenswert, wenn der Server zuvor anderweitig in Benutzung war, z.B. gebraucht gekauft wurde.
Ebenfalls kann ein Rücksetzen auf Auslieferzustand erforderlich sein, wenn die SSD des Zielservers so ausgenutzt ist, dass die bei der Wiederherstellung temporär zu entpackenden Dateien nicht ausreichend Platz hätten.
Durch ein solches Rücksetzen wird eine komplette Bereinigung durchgeführt und der maximal mögliche freie Speicherplatz freigegeben, jedoch auch alles komplett gelöscht. Bitte beachten Sie, dass dies auch auf alle Ihre Docker Container, Docker Volumes und APP Daten Volumes zutrifft. Bitte unterbrechen Sie die Stromzufuhr hierbei nicht, da sonst die Gefahr besteht, dass der Rücksetzprozess zu einem Zeitpunkt unterbrochen wird, der einen anschließenden Reboot verhindert. Dies ist ein theoretischer Hinweis. Es wurde bisher nur einmal ein Timberwolf Server wegen einer Unterbrechung der Versorgungsspannung während des Rücksetzprozesses in einen Zustand versetzt, dass ein anschließender Reboot nicht möglich war. Falls dies passieren soll, wenden Sie sich bitte an den Support.
Update Zielserver: Bitte führen Sie ein Update der Firmware auf möglichst die gleiche Version durch, wie diese der Quellserver hat.
Falls dies nicht möglich ist, weil nur eine neuere Version für den Update zur Verfügung steht, dann führen Sie das Update auf die neuere verfügbare Version durch. Wir empfehlen mindestens die aktuellste verfügbaren Insider Preview zur V4 zu nutzen oder - soweit verfügbar - die Firmware V4 oder neuer. Sofern die Hauptversion V4 noch nicht verfügbar ist, fragen Sie bitte beim Support nach einer Interim Insider Lizenz an.
Update Quellserver: Bitte führen Sie ein Update der Firmware auch auf dem Quellserver durch, nach Möglichkeit auf die selbe Firmware Version bei der Zielserver.
Bussysteme abstecken: Wir empfehlen Ihnen, die Bussysteme KNX und 1-Wire vor Beginn der Migration vom Zielserver abzustecken. Damit soll vermieden werden, dass es zu unkontrollierter Interaktionen mit dem Bus kommt, insbesondere bei paralleler Nutzung beider Server am selben Bussystem mit geklonten Adressen (hier PA am KNX-TP). Dies gilt auch, wenn der Zielserver an einem komplett anderen KNX Bus genutzt werden soll. Hier wäre es gefährlich, wenn der Server mit der Konfiguration des Quellservers startet, im Falle einer abweichenden GA Struktur.
Verfügbarkeit Admin Passwort prüfen: Das Passwort des Benutzerkontos "admin" am Zielserver wird bei der Migration zurücksetzt auf dasjenige Passwort, das sich auf dem Geräteetikett des Zielservers befindet. Dieses Etikett sollte sich seitlich oder unten am Zielserver befinden. Prüfen Sie unbedingt - BEVOR Sie mit der Migration beginnen - dass Sie dieses Passwort vorliegen haben. Führen Sie diese Migration nicht aus, falls Sie dieses Passwort NICHT VORLIEGEN haben.
Wenn Sie die Migration der Einstellungen und Daten auf einen anderen Timberwolf Server planen, dann empfehlen wir, den Quellserver vor der Sicherung so anzupassen, dass es weder bei parallelem Doppelbetrieb noch bei der Nutzung des Zielservers in einem anderen technischen Umfeld als der Quellserver zu unerwarteten Problemen kommen kann.
Der Zielserver wird nach der Wiederherstellung der Sicherung automatisch gestartet und nimmt sofort seine Funktionen mit den neuen Einstellungen auf. Dies bedeutet, dass der Zielserver über alle Subsysteme und angeschlossenen Bussysteme zu kommunizieren beginnt, Logiken ausgeführt, Zeitreihen ergänzt werden und eine eingerichtete VISU publiziert wird. Dies kann, insbesondere beim parallelem Betrieb zum Quellserver im gleichen Netz, aber auch bei Migration zu einem Server in einer anderen Umgebung, zu Interaktionen kommen, die je nach Umfang der Konfiguration schwer überblickbar sein können.
Die sicherste Vorgehensweise besteht darin, alle Funktionen des Quellservers soweit möglich zu suspendieren, erst dann die Sicherung vorzunehmen, am Zielserver keine Bussysteme parallel anzustecken und erst dann zu migrieren.
VOR der Sicherung:
Informieren: Wir empfehlen alle anderen Nutzer in diesem smarten Gebäude darüber zu informieren, dass es durch die vorbereitenden Maßnahmen zu einer eingeschränkten Nutzbarkeit von Funktionen kommen kann.
Stoppen Sie alle APPs und Docker Container: Insofern APPs und / oder Docker Container auch auf dem Zielserver genutzt werden sollen, dann sollten deren Volumes mit in die Sicherung eingeschlossen werden. Da offene Dateien nicht gesichert werden können, empfehlen wir Ihnen die betreffenden APPs zu stoppen und die Docker Container zu suspendieren.
Mit diesen Einstellungen starten APPs und Container auch nicht nach erfolgter Migration. Bitte notieren Sie ALLE Einstellungen der betreffenden Docker Container in Portainer, da diese Informationen NICHT gesichert und wiederhergestellt werden.
APPs stoppen: TWS APPs stoppen Sie im Systemmonitor
Docker Container suspendieren: Docker Container suspendieren Sie im Portainer
Grafana: Überprüfen Sie, ob Plug-ins installiert sind und ob diese mit der CPU-Architektur des Zielservers kompatibel sind. Entfernen Sie nicht genutzte und inkompatible Plug-ins.
Timberwolf VISU Instanzen beenden: Stoppen Sie alle Timberwolf VISU Instanzen, damit die VISU nicht mehr veröffentlicht wird. Dies dient dazu, dass keine falschen Anzeigen entstehen durch nachfolgende Schritte und die VISU auch nicht nach Migration automatisch am Zielserver gestartet wird (mit veralteten, da zwischengespeicherten Werten aus der Datensicherung)
Logiken und Verknüpfungen prüfen: Im nächsten Schritt werden wir Sie bitten, alle IP-basierenden Protokolle zu suspendieren. Dies kann zu Problemen mit laufenden Logiken und Verknüpfungen führen. Bitte prüfen Sie Ihre Automatisierungen und Logiken hinsichtlich der nachfolgend angeratenen Suspendierung aller IP-Protokolle und Dienste. Prüfen Sie auch alle Logiken hinsichtlich der Persistenzeinstellungen, da hiermit der aktuelle Status einer Logik mitgespeichert und nach Migration am neuen Server genau mit diesem Status fortgesetzt wird. Bei komplexen Custom-Logiken mit mehrfachen Status kann dies am Zielserver unvorhersehbar sein. Solche Logiken sollten Sie stets stoppen.
Alle IP-Protokolle und Dienste suspendieren: Stoppen Sie die Ausführung aller IP-Dienste in den Verbindungseinstellungen, soweit dies betrieblich möglich ist. Dies gilt für Modbus TCP, HTTP-/Rest-API, MQTT und IFTTT. Bei der Sicherung wird diese suspendierte Einstellung der IP-Protokolle mit gespeichert, damit starten diese Dienste am Zielserver nach der Migration nicht und damit nicht unkontrolliert und schon gar nicht doppelt und parallel zum Quellserver und mit anderen Netzwerkeinstellungen. Prüfen Sie zuvor die Auswirkungen ausbleibender Interaktionen über diese IP-Dienste in Verbindung mit Logiken und anderen Bussystemen. Ggfls. müssen Sie Logiken deshalb anhalten bzw. auch die Kommunikation über KNX / 1-Wire / Modbus RTU einschränken oder stoppen.
Systeminformationen des Nutzers: Passen Sie ggfls. die Angaben in den Systemeinstellungen des Nutzers so an, dass nach der Migration keine Irritationen in der Web-APP des Zielservers entstehen (etwa weil Sie die ID des Quellservers sich in Kopf-. und Fußzeilen oder auf der Anmeldeseite anzeigen lassen, Farbkodierungen bei mehreren Servern nutzen usw.
Nehmen Sie nun die Sicherung am Quellserver so vor, wie in diesem Kapitel beschrieben und schließen Sie alle Volumes der APPs und Container mit ein, die am Zielserver weiter genutzt werden sollen: Datensicherung vornehmen
Bitte beachten Sie ZUVOR alle obenstehenden Informationen, insbesondere die Gefahrenhinweise und die vorbereitenden Schritte.
Stick einstecken: Stecken Sie den ElabNET Backup USB Stick aus dem Quellserver in den USB Port des Zielservers und öffnen das Funktionsmodul Datensicherung.
Datensicherung auswählen: Wählen Sie aus der Liste die richtige Sicherung aus. Klappen Sie hierzu über das “Detail”-Symbol die Informationen zur Sicherung aus
Wiederherstellen starten: Starten Sie nun die Wiederherstellung über das Symbol mit der linksdrehenden Uhrzeiger. Die Rücksicherung kann je nach Umfang eine halbe bis eine Stunde betragen.
Bitte beachten Sie, dass der Zielserver nach der Wiederherstellung automatisch startet und alle Dienste und Prozesse entsprechend der Konfiguration zu laufen beginnen. Lesen Sie hierzu auch oben die Gefahrenhinweise.
Bitte lesen Sie die Hinweise genau (diese sind in dieser Anleitung enthalten) und bestätigen anschließend die rote Schaltfläche
Wichtige Maßnahmen NACH der Migration (auf anderen Server gleiches Modell bzw. anderen Server unterschiedliches Modell)
Systeminformationen des Nutzers: Passen Sie ggfls. die Angaben in den Systemeinstellungen des Nutzers an den Zielserver an.
Netzwerkeinstellungen prüfen: Die Netzwerkeinstellungen wurden durch die Migration nicht berührt, womöglich durch ein Rücksetzen auf Auslieferzustand jedoch auf DHCP umgestellt. Da diese Einstellungen jedoch gegenüber denen des Quellserver abweichen sind, könnten Anpassungen erforderlich sein. Beachten Sie die folgende Liste.
MacVLAN: Prüfen Sie, ob der Quellserver mit MacVLAN Einstellungen betrieben wurde und diese oder ähnliche am Zielserver einzurichten sind.
Netzwerk: Prüfen Sie als nächstes, ob DNS-Server, Firewalls, NAT-Regeln, Port-Forwarding für Nutzer VPN sowie das Routing im Netz des Zielservers anzupassen sind an die IP des Zielservers und testen Sie alle diesbezüglichen Basisfunktionen. Insbesondere sollten die Verbindungen zur Timberwolf Cloud, zu den NTP-Servern und ggfls. zu MQTT Servern im Internet funktionieren. Prüfen Sie auch die Erreichbarkeit der von den IP-Protokollen anzusprechenden Dienste.
Proxy: Überprüfen Sie nun alle Reverse-Proxy-Ziele auf Funktion (soweit nicht Zugriffe auf APPs bzw. Docker Container erfolgen, diese werden erst in einem späteren Schritt gestartet
ekey: Insofern Sie ekey Home oder ekey Multi einsetzen, dann ist der ekey cvLAN-Konverter an die neue IP-Adresse des Timberwolf Servers anzupassen, damit die UDP Pakete aus dem ekey System weiterhin an den Timberwolf Server zugestellt werden.
KNXnet/IP: Prüfen Sie die Nutzung der Tunnel durch dritte Dienste und Geräte. Dieser Schritt ist auch davon abhängig, wann die KNX TP Verbindung am Zielserver wieder in Betrieb genommen wird, was ein untenstehender Schritt ist.
IP-Protokolle und Dienste starten: Insofern Sie IP-Protokolle vor der Sicherung am Quellserver gestoppt hatten, gehen Sie diese nun Protokoll- und Dienstweise durch und starten diese einzeln und prüfen Sie die Funktion (bis auf IFTTT). Ggfls. müssen Sie auch Logiken hierbei berücksichtigen und weitere Busprotokolle.
MQTT: Das Protokoll MQTT benötigt zur Funktion einen MQTT Broker. Oftmals ist dieser in einem Docker Container am Timberwolf Server installiert. Bitte achten Sie darauf, dass Sie den MQTT Broker gemäß Anleitung MQTT Broker in einem Docker Container installieren neu installieren.
KNX Seriennummer von der ETS auslesen lassen: Durch den Boot des Zielservers nach der Migration wurde die - zunächst mit Rücksicherung vom Quell-Server übernommene KNX SN - wieder passend auf die zur Server-Hardware zugehörige SN zurück gesetzt. Allerdings wurde auch die PA und die gesamte Installation übernommen. In der ETS ist von der Programmierung des Quell-Servers noch die SN des Quell-Servers gespeichert. Damit die ETS nun die korrekte SN des Zielservers kennt, empfehlen wir, die Programmierung der PA und / oder der Applikation durchzuführen und hier die Identifizierung über “Drücken der Programmiertaste” vorzunehmen (und nicht über die Seriennummer). Weitere Details hierzu unter https://elabnet.atlassian.net/wiki/spaces/TSKB/pages/2443182081/Insider+Preview+1#FIX-R%C3%BCcksetzen-KNX-Stack-Seriennummer-nach-Migration-(durch-Boot).
Docker Container laden und instantiieren: Insofern Docker Container auch auf dem Zielserver genutzt werden sollen, dann sollten Sie deren Docker Volumes bereits mit in die Sicherung eingeschlossen haben.
Die Konfiguration der Docker Container selbst und auch die Docker Images sind nicht Bestandteil der Sicherung und werden auch nicht wieder hergestellt. Weil es ist das Konzept von Docker, dass Container aus dem Repository neu geladen und instantiiert werden. Zudem wird dann auch das Image geladen, dass für die Architektur des Zielservers passend ist.
Nehmen Sie nun Ihre am Quellserver angefertigten Notizen und richten die Container einer nach dem anderen ein und passen auch die Netzwerkeinstellungen entsprechend an. Die wiederhergestellten Docker Volumes können Sie einfach anhängen, so dass die durch die Migration übernommenen Konfiguration und Daten einfach weiter genutzt werden können.
Bussysteme anstecken: Dieser Schritt kann von der Reihenfolge abhängig sein von anderen Protokollen und den implementierten Logiken. Prüfen Sie für Ihre eingerichtete Automatisierung, an welcher Stelle der Migration die Bussysteme am Besten wieder angesteckt werden.
Bitte achten Sie darauf, dass der Zielserver alle KNX Programmierungen des Quellservers übernommen hat und diesbezüglich ein KLON mit identischen PAs und GA-Zuordnungen ist.
Identisches KNX Bussystem wie Quellserver: Wenn Sie den KNX-TP des Zielservers anschließen möchten, klemmen Sie zuvor die Verbindung des Quellservers vom KNX-TP ab.
Unterschiedliches KNX Bussystem wie Quellserver: Nehmen Sie eine passende Programmierung aus der ETS über KNXnet/IP vor und prüfen die interne Verknüpfung der KNX Objekte. Schließen Sie erst danach den Timberwolf Server an den neuen KNX Bus an.
1-Wire: Nach der Migration erscheinen “Ghost” Busmaster, die das System vom Quellserver gelernt hat, aber am Zielserver womöglich nicht vorhanden sind, insbesondere wenn es sich um im Server eingebaute Busmaster handelt wie bei der 3xx/9xx Serie. Diese “Ghost” Busmaster können Sie einfach löschen, dies hat keine Folgen. Die 1-Wire Busse stecken Sie nun an den anderen 1-Wire Kanälen an, die Erkennung erfolgt automatisch. iButton Einstellungen sind mit 1-Wire Kanälen verknüpft und müssen einzeln händisch angepasst werden
Logiken und Verknüpfungen starten: Starten Sie spätestens jetzt die zuvor angehaltenen Logiken, dies jeweils abhängig von der Wiederinbetriebnahme der Protokolle und Dienste sowie der Bussysteme. Da der Doktormodus nur bei Logikzellen mit Perstistenz wieder eingeschaltet wurde (sofern zum Zeitpunkt der Sicherung aktiviert) dann sollten Sie den Doktormodus wieder entsprechend aktivieren.
Elab ID: Benutzerkonten vom Typ Elab ID, die vor der Migration für die Anmeldung am Zielserver freigeschaltet waren, können nach der Migration zur Anmeldung genutzt werden, sofern die Datenschutz-Einstellungen dies erlauben (Aktivierung Timberwolf Cloud & Elab ID) und zum Anmeldezeitpunkt (künftig, irgendwann) eine Verbindung zur Timberwolf Cloud besteht (weil die Verknüpfung des Zielservers mit Elab ID´s ist in der Timberwolf Cloud hinterlegt.
Elab ID Benutzerkonten, die zuvor auf dem Quellserver genutzt wurden: Trennen Sie in der Benutzerverwaltung die jeweiligen Elab ID Konten und verbinden diese anschließend über die Schaltfläche “Bestehende Elab ID mit diesem Server nutzen” neu (hierfür sind die jeweiligen Passwörter anzugeben). Dieser Schritt ist insbesondere ERFORDERLICH, falls Sie IFTTT auf dem Quellserver benutzt haben und IFTTT auf dem Zielserver weiterbetreiben möchten, da die Verbindung zum IFTTT Service auf einer Elab ID basiert und deren Re-Verknüpfung mit dem Zielserver essentiell für die weitere Nutzung mit IFTTT ist.
Lokale Benutzer: Die Anmeldung mit LOKALEN Benutzerkonten ist zunächst nicht möglich, da jeder Server einen individuellen “Salt” beim hashen des Passwortes nutzt und der Abgleich mit der Daten der Passwort Hashwerte vom Quellserver nicht mehr passt. Alle lokalen Benutzerkonten sind auf dem Zielserver nun zu reaktivieren. Dies kann nur der Benutzer "admin" vornehmen, Hierbei muss für jedes weiterhin zu nutzende lokale Benutzerkonto das Passwortes neu vergeben werden, damit dieses mit dem “Salt” des Zielservers in der Passwort-Hashwerte-Datei abgelegt wird. Das Kennwort des Benutzerkonto “admin” wurde durch die Migration selbst auf Werkseinstellungen zurückgesetzt und entspricht der Angabe auf dem Geräteetikett.
Nutzer-VPN: Die Konfiguration des Nutzer-VPN wurde aus dem Quellserver übernommen. Da der Zielserver womöglich über andere Netzwerkeinstellungen verfügt bzw. sich zusätzlich in einem anderen Netzwerk befindet, sollten Sie die Funktion prüfen. Evt. sind Einstellungen der lokalen Firewall, Portfreigaben usw. anzupassen.
Support-VPN: Der Status und die Konfiguration des Support-VPN sind nicht in der Datensicherung enthalten und werden auch nicht wieder hergestellt. Prüfen Sie den Status und Konfiguration des Support-VPN nach der Migration, ob dieses Ihren Wünschen entspricht.
TWS VISU: Wenn alle Protokolle, Bussysteme und Logiken funktionieren, dann sollten Sie nun die VISU Instanzen starten. Falls die VISU Clients sich nicht mit dem Zielserver verbinden, dann setzen Sie in den lokalen VISU Client Einstellungen jeweils den Cache zurück (dies initiiert einen neuen Schlüsselaustausch mit dem Zielserver für das VISU Protokoll)