Dieses Kapitel beschreibt, wie Daten und Einstellungen auf einen anderen Servern migriert werden können, z.B. wegen einem Wechsel des Servers.

Vorwort

Das Funktionsmodul Datensicherung V4 verfügt über eine Unterstützung zur Migration von Einstellungen und Daten zwischen Servern aus 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 muss eine Reihe von Punkten beachtet werden, die folgend dargestellt werden. Bitte lassen Sie sich nicht vom Umfang der Details erschrecken, das meiste davon läßt sich zügig abarbeiten und einiges muss nur in besonderen Fällen beachtet werden.

Begriffe

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. Derzeit wird eine Migration zwischen Modellreihen nur von Servern der Modellreihe 3xx/9xx auf die Modellreihe 3500 unterstützt.

Gefahrenhinweise

Die Wiederherstellung einer Datensicherung auf einen Zielserver bedeutet, die meisten bestehenden Daten und Einstellungen auf dem Zielserver zu überschreiben. Dies ist unumkehrbar.

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.
WARNUNG 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.
HINWEIS 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
Timberwolf VISU: Alle Einstellungen der Timberwolf VISU wie VISU Profile, VISU Instanzen und Widgets werden komplett zurückgesetzt und durch die Sicherung ersetzt.
Nutzer-VPN: Alle Einstellungen zum Nutzer-VPN wie Zertifikate und Profile werden komplett aus der Sicherung ersetzt.
HINWEIS 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 User-VPN Server kann dadurch nicht mehr von außen erreichbar sein und - je nach Einstellungen - kann auch die Rückroute nicht oder nicht passend konfiguriert sein.
KNX-Einstellungen: KNX Programmierung mit BAU-Schlüssel sowie die im lokalen Projektspeicher befindlichen importierten ETS Projekte (die jeweils selbst mit einem Projekt-Passwort Passwort verschlüsselt sein können) werden aus der Sicherung ersetzt (damit sind dort zuvor gespeicherte ETS Projekte gelöscht)
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.
Migration: Damit können Busmaster und Geräte angezeigt werden, die auf dem Zielserver nicht existent ist. Zum Beispiel wird der in der Modellreihe 3xx / 9xx enthaltene Busmaster bei Wiederherstellung auf einem anderen Server 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 Kanäle definiert sind, die nach einer Migration am Zielserver womöglich dort nicht existieren.
Aufzeichnungen: Alle Aufzeichnungen in Logs, Zeitserien und Logicscope (Doktormodus Aufzeichnung) werden zurück gesetzt und komplett aus der Sicherung ersetzt.
Lizenzinformationen: Lokal installierte Lizenzinformationen (für die es auch eine Kopie in der Timberwolf Cloud gibt) wird aus der Datensicherung ersetzt.
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 Wiederherstellung bereits auf dem Timberwolf Server vorhanden waren UND nicht in der Datensicherung enthalten sind, werden bei der Wiederherstellung nicht angetastet.
- ALLE TWS APP Daten Volumes werden grundsätzlich im Rahmen der Wiederherstellung geleert. Nur diejenigen TWS APP Daten Volumes, die Bestandteil der Datensicherung waren, werden durch die Wiederherstellung aus der Sicherung wieder befüllt.
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).
HINWEIS 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.
WARNUNG 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.
HINWEIS 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.
WARNUNG 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.
WARNUNG 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.

Vorbereitende Schritte vor der Migration

Zurücksetzen: Ggfls. Rücksetzen des ZIELSERVERS auf Werkszustand: Sofern Sie keine Migration auf einen fabrikneuen Server nutzen für eine klare Grundlage. Insbesondere bei gebraucht Kauf / andere Verwendung / Andere fremde Daten. Brickgefahr.
Update: Software auf aktuelle Version. ggfls. Lizenz für Insider anfragen, falls dort neuere Datensicherung vorhanden oder auf altem Server eine Insider Version installiert ist
WARNUNG Rücksetzen Admin-Passwort: Das Passwort des Benutzerkontos "admin" wird 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 durch Wiederherstellung nicht aus, falls Sie dieses Passwort JETZT NICHT VORLIEGEN haben.

Planung einer idealen Sicherung zur Nutzung für Migration

IP-Dienste die mit dritten interagieren und daraus Steuerungen / Logiken auslösen und / oder an an dere Bussysteme über Verknüpfungen weiterleiten ausknipsen. Nur eine Verbindung
Persistenz prüfen

Maßnahmen nach erfolgter Migration

Wichtige Maßnahmen NACH der Migration (auf anderen Server gleiches Modell bzw. anderen Server unterschiedliches Modell)

Elab ID: Benutzerkonten vom Typ Elab ID, die VOR der Migration durch Wiederherstellung für die Anmeldung am ZIELSERVER freigeschaltet waren, können auch nach der Wiederherstellung zur Anmeldung genutzt werden, SOFERN die in der Sicherungsdatei hinterlegten Datenschutz-Einstellungen dies erlauben oder die Datenschutzeinstellungen anschließend angepasst werden (hierbei Aktivierung Timberwolf Cloud & Elab ID) UND zum Anmeldezeitpunkt (künftig, irgendwann) eine Verbindung zur Timberwolf Cloud besteht (weil die Verknüpfung des ZIELSERVERS zur Elab ID in der Timberwolf Cloud hinterlegt ist und dies durch die Rücksicherung nicht berührt wird)
Sie müssen in der Benutzerverwaltung alle ElabID trennen und dann über die Schaltfläche “Bestehende Elab ID mit diesem Server nutzen” neu verbinden (hierfür sind die jeweiligen Passwörter anzugeben).

Elab ID Benutzerkonten, die zuvor auf dem QUELLSERVER angelegt wurden, von dem die Datensicherung stammt und NICHT für die Nutzung mit dem ZIELSERVER ZUVOR freigeschaltet wurden, können anschließend erst dann wieder am ZIELSERVER genutzt werden, wenn diese jeweils durch den Benutzer "admin" zuerst getrennt und anschließend über die Schaltfläche “Bestehende Elab ID mit diesem Server nutzen” erneut verbunden werden. Für diese Verknüpfung wird das jeweilige Passwort benötigt.

HINWEIS 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 IFTTT ist.
Benutzerverwaltung: Die Anmeldung mit LOKALEN Benutzerkonten ist zunächst nicht mehr möglich. Nur der Benutzer "admin" kann eine Reaktivierung für jedes LOKALE Benutzerkonto durch Vergabe eines Passwortes vornehmen. Das Kennwort des Benutzerkonto “admin” wurde durch die Migration auf Werkseinstellungen zurückgesetzt und entspricht der Angabe auf dem Geräteetikett.
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 die Konfiguration des Support-VPN nach der Migration, ob diese Ihren Wünschen entspricht.
TWS VISU: Falls der VISU Client sich nicht mehr mit dem Zielserver verbindet, dann setzen Sie in den lokalen VISU Client Einstellungen den Cache zurück (dies initiiert einen neuen Schlüsselaustausch mit dem Zielserver für das VISU Protokoll)

Systeminformationen

Datenschutzeinstellungen

Achtung bei IP-Services, KNX PAs, grünes Kabel

Wichtige Maßnahmen NACH der Wiederherstellung

Doktormodus ggfls. wieder aktivieren (weil komplett für alle Logiken ohne Persistenz durch Restart des Services zurückgesetzt)
IFTTT: Zeigt neue Server an, die Applets müssen umgesetzt werden. Beachten Sie dazu die separate Anleitung im Unterkapitel.
Dazu rufen Sie die Web-APP bzw. die APP von IFTTT auf um Applets zu bearbeiten.

Zusätzlich, falls Sie den Server vor der Rücksicherung auf Auslieferzustand zurückgesetzt haben

Netzwerkkonfig wurde dadurch auf DHCP geändert, damit andere IP und in Portainer nachführen

Zusätzlich, bei geänderter IP und / oder einem anderen Netz mit geänderter Namensauflösung

Portainer nachführen, MacVLAn etc. macVLAN Netzwerkkonfig wird nicht restauriert, andere IP und in Portainer nachführen
Prüfen Reverse-Proxy-Ziele
ekey anpassen im Falle einer anderen IP
Firewalls, Filter, NAT-Regeln, Port-Forwardung, Routing, MQTT Einschränkungen und sonstige Geräte anpassen im Falle einer anderen IP, PiHole
KNXnet/IP Nutzung durch dritte Dienste / geräte prüfen
Kompletter Chec

Migration auf ANDEREN Server