Farbschema: Hell
Sie befinden sich hier: start » de » Dokumentation » Datenintegration und Datenzugriff » WKL Database Gateway » Betrieb » So sichern Sie den Verwaltungsspeicher, stellen ihn wieder her und ziehen um

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:

TeilSicherung
Konfigurationsdatei (appsettings*.json)mit dem Programm; enthält keine Geheimnisse
Verwaltungsspeicher und Protokolldateiregelmäßig mit dem Befehl backup-store, der beide sichert
Hauptschlüssel, Dienstschlüssel, Zertifikatskennwortgetrennt vom Speicher, etwa in einem Kennworttresor
Zertifikat für HTTPSwie 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 mit 2.
  • Leserecht auf den Speicher. Lesen dürfen ihn nur das Dienstkonto und die Administratoren; die Aufgabe läuft deshalb als SYSTEM oder 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:

  1. Dienst beenden: Stop-Service Wkl.Data.Gateway.
  2. Die Speicherdatei durch die Sicherung ersetzen und die Dateien -wal und -shm daneben 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 unter Gateway:Store:Path eingestellte, nach dem Installationspaket %ProgramData%\Wkl.Data.Gateway\gateway.db. Ebenso die Protokolldatei durch die Sicherung …-logs.db ersetzen (Ort nach Gateway:Store:LogPath, sonst gateway-logs.db neben 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.
  3. Dienst starten: Start-Service Wkl.Data.Gateway.
  4. 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:

MeldungUrsacheAbhilfe
„die Datei hat die Schemafassung N, dieser Dienst kennt nur bis M“Die Sicherung stammt von einer neueren Fassung des DienstesDieselbe 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 sieDer Hauptschlüssel passt nicht zur SicherungDen 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:

  1. Dienst installieren, Konfigurationsdatei übernehmen, Adressen und Zertifikat anpassen.
  2. 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 -logs daneben (gateway.db und gateway-logs.db).
  3. Den bisherigen Hauptschlüssel unter derselben Kennung bereitstellen.
  4. 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 -wal und -shm; eine Kopie mitten in einem Schreibvorgang kann einen halben Stand enthalten. Immer backup-store verwenden.
  • 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.

Verwandte Themen

de/wiki/data-conectivity/database-gateway/operations/backup.txt · Zuletzt geändert: von Wolfgang van der Stille