Sicherung & Wiederherstellung

Die Kurzfassung in zwei Sätzen: Sichern Sie die Überwachungsdatenbank — und, falls Sie einen eigenen Encryption:Key gesetzt haben, diesen Schlüssel gleich mit. Die Datenbank enthält alles, was das Produkt weiß; der Verschlüsselungsschlüssel ist das einzige Artefakt, das sich nicht neu erzeugen lässt, denn ohne ihn sind die verschlüsselten Spalten dieser Datenbank dauerhaft unlesbar.

Was zu sichern ist

Was Warum Standardablage
Überwachungsdatenbank Gesamte Konfiguration, Serverinventar, Alarmregeln, Verlauf, Prüfprotokoll, verschlüsselte Geheimnisse Dort, wo Ihr Überwachungs-SQL-Server liegt
Encryption:Key, falls gesetzt Der AES-256-Schlüssel, der Verbindungszeichenfolgen und Benachrichtigungsgeheimnisse entschlüsselt. Ist er weg, sind diese Spalten verloren appsettings.json, eine Umgebungsvariable oder Ihr Geheimnisspeicher — wo immer Sie ihn hinterlegt haben
Lizenzdatei RSA-signierter Lizenzumschlag Pfad aus appsettings.json:Licensing:LicenseFilePath (Standard: license.lic neben der Anwendungsdatei)
appsettings.json samt umgebungsspezifischer Overlays Verbindungszeichenfolge und Startkonfiguration Neben der Anwendungsdatei bzw. /app im Container
HTTPS-Zertifikat Ihr von einer CA ausgestelltes Zertifikat, falls installiert SecuritySettings:CertificatePath oder der Zertifikatsordner
DataProtection-Schlüsselordner Nur Komfort — siehe unten Windows: %LOCALAPPDATA%\SqlServerHealthMonitor\DataProtection-Keys
Linux: ~/.local/share/SqlServerHealthMonitor/DataProtection-Keys

bin/, obj/ und wwwroot/lib/ können Sie auslassen — die stellt der Installer wieder her.

Welcher Schlüssel wirklich zählt

Es sind zwei verschiedene Schlüsselsysteme im Spiel, und nur eines davon ist kritisch.

Kritisch ist der Verschlüsselungsschlüssel (Encryption:Key). Verbindungszeichenfolgen zu überwachten Servern und die Geheimnisse der Benachrichtigungskanäle (Microsoft-365-Zugangsdaten, PagerDuty-Routing-Key, Teams-Webhook) liegen in einem enc:v2:-Umschlag: AES-256-GCM mit einem festen Schlüssel. Dieser stammt aus Encryption:Key, sofern Sie einen konfiguriert haben, andernfalls aus einem in die Anwendung eingebauten Standardschlüssel. Mit dem eingebauten Standard müssen Sie nichts zusätzlich sichern — er bedeutet aber auch, dass jeder, der eine Kopie der Programmdatei besitzt, eine entwendete Datenbank entschlüsseln kann. Die Verschlüsselung schützt also eine abhandengekommene reine Datenbanksicherung und sonst nichts. Wenn Ihnen das nicht genügt, setzen Sie einen eigenen 32-Byte-Base64-Schlüssel — und behandeln ihn von da an wie eine Datenbanksicherung. Geht er verloren, gibt es keinen Weg zurück.

Der DataProtection-Schlüsselordner ist nicht mehr kritisch. Das Framework nutzt ihn weiterhin für Anmelde-Cookies, Antiforgery-Token, das selbstsignierte HTTPS-Zertifikat und um verbliebene enc:v1:-Werte älterer Versionen zu lesen. Geht er verloren, werden alle Benutzer abgemeldet und das selbstsignierte Zertifikat wird neu erzeugt — ärgerlich, aber nicht fatal. Ihre verschlüsselten Spalten überleben, weil sie als enc:v2: unter dem festen Schlüssel liegen. Ältere Dokumentation (und frühere Fassungen dieser Seite) hat diesen Ordner als das Artefakt beschrieben, das niemals verloren gehen darf; seit der Umstellung auf enc:v2: stimmt das nicht mehr.

Beim Start verschlüsselt die Anwendung jede Zeile, die noch enc:v1: oder Klartext ist, auf den aktuellen Umschlag um. Eine Zeile, die sie nicht entschlüsseln kann, bleibt unangetastet und wird protokolliert, niemals überschrieben — ein fehlender Altschlüssel kostet Sie also diesen einen Wert, nicht die ganze Spalte.

Sicherungsrhythmus

  • Datenbank — derselbe Rhythmus wie bei Ihren übrigen Produktivdatenbanken, typischerweise nächtlich FULL und stündlich LOG.
  • Verschlüsselungsschlüssel, Lizenz, appsettings.json — bei jeder Änderung einmal. Sie sind winzig und ändern sich nur, wenn Sie sie ändern.
  • DataProtection-Schlüsselordner — optional. Nimmt man ihn wöchentlich mit, ersparen Sie Ihren Benutzern nach einem Neuaufbau des Rechners die erneute Anmeldung.

Wiederherstellung

Nach Verlust der Überwachungsdatenbank

  1. Datenbank auf denselben oder einen anderen SQL Server zurücksichern.
  2. ConnectionStrings:DefaultConnection anpassen, falls sich Server- oder Datenbankname geändert haben.
  3. Sicherstellen, dass derselbe Encryption:Key konfiguriert ist wie zuvor — oder keiner, falls Sie den eingebauten Standard verwendet haben.
  4. Neu starten. Die verschlüsselten Spalten sind sofort wieder lesbar.

Nach Verlust des DataProtection-Schlüsselordners (Datenbank intakt)

  1. Neu starten. Es werden neue Schlüssel erzeugt.
  2. Alle Benutzer sind abgemeldet und müssen sich neu anmelden.
  3. Falls Sie das selbstsignierte Zertifikat verwendet haben, wird ein neues erzeugt — Clients, die dem alten manuell vertraut haben, müssen dem neuen vertrauen.
  4. Überwachung, Verbindungszeichenfolgen und Benachrichtigungsgeheimnisse sind nicht betroffen.

Nach Verlust des eigenen Encryption:Key (Datenbank intakt)

Das ist der schlimmste Fall — und er tritt nur ein, wenn Sie einen eigenen Schlüssel konfiguriert hatten.

  1. Die Anwendung startet, aber jeder unter dem verlorenen Schlüssel verschlüsselte Wert lässt sich nicht entschlüsseln. Verbindungszeichenfolgen kommen leer zurück, dadurch erscheint jeder überwachte Server als nicht erreichbar; Benachrichtigungskanäle schlagen fehl.
  2. Der Startvorgang protokolliert jede Zeile, die er nicht entschlüsseln konnte, und lässt den Geheimtext stehen. Es wird also nichts stillschweigend zerstört — lesbar ist aber auch nichts.
  3. Die Wiederherstellung ist manuelle Neueingabe:
    • /Servers → jeden Server bearbeiten → Verbindungszeichenfolge erneut einfügen → Speichern.
    • /Settings/Notifications → das Geheimnis jedes Kanals erneut eingeben → Speichern.
  4. Setzen Sie einen neuen Encryption:Key (oder entfernen Sie die Einstellung, um auf den eingebauten Standard zurückzufallen), bevor Sie etwas neu eingeben — damit die neuen Werte unter einem Schlüssel landen, den Sie noch haben.

Eine Abkürzung gibt es nicht. Genau deshalb gehört der Schlüssel in den Sicherungsplan.

Nach Verlust von allem

  1. Neuinstallation gemäß Inbetriebnahme.
  2. Überwachungsdatenbank zurücksichern.
  3. appsettings.json samt Encryption:Key zurücksichern — oder, wenn der Schlüssel weg ist, der manuellen Neueingabe oben folgen.

Prüfen, ob die Sicherung den Schlüssel enthält

Wenn Encryption:Key in appsettings.json gesetzt ist, vergewissern Sie sich, dass diese Datei selbst im Sicherungssatz liegt — nicht nur die Datenbank:

Select-String -Path "C:\Apps\SqlServerHealthMonitor\appsettings.json" -Pattern '"Key"'

Stammt der Schlüssel stattdessen aus einer Umgebungsvariablen oder einem Geheimnisspeicher, prüfen Sie, dass dieser Speicher gesichert wird und dass Sie den Wert auch wirklich wieder auslesen können. Ein Schlüssel, den Sie nicht abrufen können, ist ein verlorener Schlüssel.

Notfallübung

Einmal jährlich, oder vor jeder größeren Aktualisierung:

  1. Überwachungsdatenbank und appsettings.json auf einen Testrechner zurücksichern.
  2. Die Testinstanz in ein nicht produktives Netz stellen, damit sie niemanden echt alarmiert.
  3. Prüfen:
    • Das Dashboard lädt.
    • Die Serverliste verbindet sich — das beweist, dass die Verbindungszeichenfolgen entschlüsselt wurden.
    • Die Testschaltflächen unter /Settings/Notifications funktionieren — das beweist, dass die Kanalgeheimnisse entschlüsselt wurden.
  4. Testumgebung abbauen.

Schlägt der Verbindungstest auf der zurückgesicherten Kopie fehl, während er produktiv funktioniert, fehlt Ihrer Sicherung der Verschlüsselungsschlüssel. Beheben Sie das, bevor Sie ihn brauchen.