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, 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 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 & Wissenswertes

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.
  WARNUNG Mit Ende der Migration startet der Server neu und die VISI 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.
  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 könnte dadurch nicht mehr von außen erreichbar sein und - je nach Einstellungen - könnte auch die interne ntRückroute nicht oder nicht passend konfiguriert sein.

• KNX-Einstellungen: Die KNX Programmierung des Stacks mit BAU-Schlüssel sowie alle im lokalen Projektspeicher befindlichen, zuvor importierten ETS Projekte werden gelöscht und mit den Einstellungen und Projekten aus der Sicherung ersetzt.
  HINWEIS Eine erneute KNX Programmierung ist zwar nicht nötig, allerdings übernimmt der Zielserver damit die Programmierung des KNX Stacks vom Quellserver. Sollten Sie den Zeielserver in einer anderen KNX Umgebung nutzen, dann empfehlen wir, den Zielserver nicht am KNX Bus anzuschließen, sondern erst eine passende Programmierung mit der ETS vorzunehmen.

• 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.
  HINWEIS 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.

• 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 sind.

• 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 nicht aus, falls Sie dieses Passwort NICHT VORLIEGEN haben.

Planung einer idealen Sicherung zur Nutzung für Migration

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 einem Zielserver in einem anderen technischen Umfeld als der Quellserver zu unerwarteten Problemen kommen kann.

Der Zielserver wird nach der Wiederherstellung der Sicherung automatisch gestartet und wird dann sofort seine Funktionen mit den neuen Einstellungen aufnehmen. 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 bein 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önnten.

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. Damit vermeiden Sie doppelte und parallele Interaktionen zweier Server mit gleichen Einstellungen.

• 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

Durchführen der Migration

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