So sichern Sie den Verwaltungsspeicher, stellen ihn wieder her und ziehen um
Alles, was die Verwaltung einstellt – Datenquellen, Regeln, Personen, Schlüssel, zweite Faktoren, Anmelderegeln –, steht in einer Datei: dem Verwaltungsspeicher. Ohne Sicherung ist das bei einem Plattenausfall verloren, und jede Person braucht neue Schlüssel und einen neu eingerichteten zweiten Faktor.
Lösungsübersicht
Eine Installation besteht aus vier Teilen, die Sie getrennt sichern:
| Teil | Sicherung |
|---|---|
Konfigurationsdatei (appsettings*.json) | mit dem Programm; enthält keine Geheimnisse |
| Verwaltungsspeicher und Protokolldatei | regelmäßig mit dem Befehl backup-store, der beide sichert |
| Hauptschlüssel, Dienstschlüssel, Zertifikatskennwort | getrennt vom Speicher, etwa in einem Kennworttresor |
| Zertifikat für HTTPS | wie jedes Serverzertifikat |
Der Speicher allein öffnet keine Datenbank: Die Verbindungszeichenfolgen und die Geheimnisse der
zweiten Faktoren darin sind mit dem Hauptschlüssel verschlüsselt. Ohne Hauptschlüssel ist eine
Sicherung wertlos. Das Installationspaket legt ihn als Datei geheim\hauptschluessel.key im
Datenordner %ProgramData%\Wkl.Data.Gateway an.
Umsetzung
Sichern aus der Verwaltungsanwendung – für zwischendurch, etwa vor einer größeren Änderung:
Öffnen Sie Übersicht und wählen Sie in der Befehlsleiste Speicher sichern. Die Kopie
entsteht auf dem Rechner des Dienstes im Ordner sicherungen neben dem Speicher, unter einem Namen
nach dem Zeitpunkt (gateway-JJJJMMTT-hhmmss.db, die Protokolldatei daneben als
gateway-JJJJMMTT-hhmmss-logs.db); die Meldung nennt die Datei. Den Ort wählt der
Dienst, nicht die Anwendung. Weitere > Speicher prüfen oder ein Klick auf die Kachel
Pflege prüft den Speicher, ohne etwas zu ändern. Dieser Ordner liegt auf derselben Platte wie der
Speicher: Für einen Plattenausfall braucht es zusätzlich die regelmäßige Sicherung an einen anderen
Ort, wie folgt.
Sichern als regelmäßige Aufgabe – im laufenden Betrieb, auf dem Rechner des Dienstes. Der Befehl
backup-store schreibt eine in sich stimmige Kopie des Speichers und eine der Protokolldatei, auch
während der Dienst schreibt, prüft beide und endet mit 0; er überschreibt nichts. Mit
--to-folder wählt er den Dateinamen nach dem Zeitpunkt (gateway-JJJJMMTT-hhmmss.db und
gateway-JJJJMMTT-hhmmss-logs.db), sodass eine tägliche Aufgabe immer neue Dateien schreibt. Den
Hauptschlüssel braucht er nicht. Die Protokolldatei kann bis zu ihrer eingestellten Größe wachsen
(Gateway:Store:LogMaxMegabytes, Vorgabe 4 096 MB); planen Sie Platz und Dauer der Sicherung danach.
Voraussetzungen, die eine geplante Aufgabe erfüllen muss:
- Arbeitsverzeichnis = Programmordner. Die Befehle lesen die Konfiguration (
appsettings*.json) aus dem Arbeitsverzeichnis; fehlt sie dort, findet der Befehl keinen Speicher und endet mit2. - Leserecht auf den Speicher. Lesen dürfen ihn nur das Dienstkonto und die Administratoren; die Aufgabe läuft deshalb als
SYSTEModer als Administrator. - Ziel auf einer anderen Platte oder einem anderen Rechner, damit ein Plattenausfall nicht Speicher und Sicherung zugleich trifft.
Beispiel (PowerShell als Administrator; Installation mit dem Installationspaket):
$program = Join-Path $env:ProgramFiles 'Wkl\Data Gateway' $action = New-ScheduledTaskAction -Execute (Join-Path $program 'Wkl.Data.Gateway.exe') ` -Argument 'backup-store --to-folder "E:\Sicherung\Datendienst"' -WorkingDirectory $program $trigger = New-ScheduledTaskTrigger -Daily -At 2am Register-ScheduledTask -TaskName 'Datendienst sichern' -Action $action -Trigger $trigger ` -User 'NT AUTHORITY\SYSTEM' -RunLevel Highest
Prüfen Sie danach einmal mit Start-ScheduledTask -TaskName 'Datendienst sichern', dass eine Datei
entsteht und die Aufgabe das Ergebnis 0 meldet (Get-ScheduledTaskInfo). Alte Sicherungen löscht
der Befehl nicht; die Aufbewahrungsfrist legen Sie selbst fest und räumen den Zielordner entsprechend
auf.
Wiederherstellen – auf demselben Rechner, als Administrator:
- Dienst beenden:
Stop-Service Wkl.Data.Gateway. - Die Speicherdatei durch die Sicherung ersetzen und die Dateien
-walund-shmdaneben löschen. Kopieren, nicht verschieben (Copy-Item): Eine kopierte Datei erbt die Rechte des Datenordners, zu denen das Dienstkonto gehört. Eine verschobene behält die Rechte der Sicherung, die nur das sichernde Konto und die Administratoren nennen; der Dienst könnte sie dann nicht lesen. Die Speicherdatei ist die unterGateway:Store:Patheingestellte, nach dem Installationspaket%ProgramData%\Wkl.Data.Gateway\gateway.db. Ebenso die Protokolldatei durch die Sicherung…-logs.dbersetzen (Ort nachGateway:Store:LogPath, sonstgateway-logs.dbneben dem Speicher). Ohne sie startet der Dienst mit leerem Anmelde- und Lastprotokoll. Bewahren Sie die ersetzten Dateien auf, bis die Prüfung in Schritt 4 bestanden ist. - Dienst starten:
Start-Service Wkl.Data.Gateway. - In der Verwaltungsanwendung prüfen: Übersicht – die Kachel Pflege meldet den Speicher in Ordnung, die Kachel Datenquellen gestört zeigt 0 – und je Datenquelle Verbindung prüfen.
Startet der Dienst nicht, nennt das Ereignisprotokoll den Grund. Die zwei häufigsten:
| Meldung | Ursache | Abhilfe |
|---|---|---|
| „die Datei hat die Schemafassung N, dieser Dienst kennt nur bis M“ | Die Sicherung stammt von einer neueren Fassung des Dienstes | Dieselbe oder eine neuere Fassung installieren; eine Sicherung lässt sich nicht auf eine ältere Fassung zurückführen |
| Datenquellen lassen sich nicht öffnen, der Start nennt sie | Der Hauptschlüssel passt nicht zur Sicherung | Den Schlüssel bereitstellen, unter dem die Sicherung geschrieben wurde |
Eine Sicherung einer älteren Fassung stellt der Dienst beim Start auf seine Fassung um und legt
vorher eine Kopie gateway.db.v<alt>-<Zeitpunkt>.bak an.
Umziehen – auf einen neuen Rechner:
- Dienst installieren, Konfigurationsdatei übernehmen, Adressen und Zertifikat anpassen.
- Die Sicherung als Speicherdatei ablegen, in einem eigenen Verzeichnis, das nur das Dienstkonto und die Administratoren lesen dürfen, und die Sicherung der Protokolldatei unter dem Namen der Speicherdatei mit angehängtem
-logsdaneben (gateway.dbundgateway-logs.db). - Den bisherigen Hauptschlüssel unter derselben Kennung bereitstellen.
- Starten und prüfen wie beim Wiederherstellen.
Ergebnis: Personen, Schlüssel und zweite Faktoren gelten weiter; sie hängen am Speicher und am Hauptschlüssel, nicht am Rechner.
Hinweise
- Datei nicht einfach kopieren. Neben der Datei liegen
-walund-shm; eine Kopie mitten in einem Schreibvorgang kann einen halben Stand enthalten. Immerbackup-storeverwenden. - Was nach der Sicherung geändert wurde, ist nach dem Wiederherstellen verloren – auch danach ausgestellte Schlüssel, die der Dienst dann abweist.
- Was nach der Sicherung gesperrt wurde, ist nach dem Wiederherstellen wieder offen: gesperrte Schlüssel, gesperrte Personen, zurückgesetzte zweite Faktoren. Sperren Sie sie nach dem Wiederherstellen erneut, bevor der Dienst wieder erreichbar ist.
- Neue Adresse nach dem Umzug: Die Clients müssen sie erfahren – Access-Anwendungen verknüpfen ihre Tabellen neu, die Verwaltungsanwendung bekommt die Adresse auf der Anmeldekarte. Ein in Windows gespeicherter Schlüssel gilt je Adresse und muss einmal neu gespeichert werden.
- Falscher Hauptschlüssel nach dem Umzug: Passt er nicht, verweigert der Dienst den Start und nennt jede betroffene Datenquelle; verändert wird nichts.
- Rechte der kopierten Datei: Eine kopierte Speicherdatei erbt die Rechte des Ordners, in den sie kopiert wird. Ist er offener als nur Dienstkonto und Administratoren, nennt der Start jedes weitere Konto in einer Warnung.
- Sicherungen enthalten lesbare Namen, Regeln, Personen und das Änderungsprotokoll, die Sicherung der Protokolldatei dazu Anmeldungen mit Adressen und Personen. Bewahren Sie sie unter Verschluss auf.
Die Rückgabewerte von backup-store stehen unter Befehle am Server: backup-store.