Aktualisierung

Vorgehen für die Aktualisierung einer Einzelrechner-Installation an Ort und Stelle. Mehrinstanz-Aufbauten (Lastverteiler davor, zwei Anwendungsrechner) behandelt dieses Dokument nicht — sagen Sie Bescheid, dann schreiben wir es.

Vorbereitung

  1. Versionshinweise lesen. Versionen mit Kompatibilitätsbrüchen sind dort ausgewiesen. Diesen Schritt bitte nicht überspringen.
  2. Sicherung anlegen. Die Datenbank und, falls gesetzt, Ihren Encryption:Key — siehe Sicherung & Wiederherstellung. Das ist das Einzige, was zwischen Ihnen und einer missglückten Aktualisierung steht.
  3. Alarme für das Wartungsfenster stummschalten. Unter /settings/silences eine flottenweite Stummschaltung anlegen (Geltungsbereich: alle Server, alle Regeln) für die erwartete Ausfallzeit. Sonst weckt die kurze Nichterreichbarkeit während des Neustarts die Rufbereitschaft.

Vorgehen — Windows-Dienst

# 1. Dienst anhalten
sc.exe stop "SqlServerHealthMonitor"

# 2. Installationsordner für den Rückweg kopieren
Copy-Item C:\Apps\SqlServerHealthMonitor C:\Apps\SqlServerHealthMonitor.backup-$(Get-Date -Format yyyyMMdd) -Recurse

# 3. Neue Programmdateien darüberlegen
# (den Ordner vorher nicht löschen — die Unterordner DataProtection-Keys und Certs unangetastet lassen)
dotnet publish -c Release -r win-x64 --self-contained false -o C:\Apps\SqlServerHealthMonitor

# 4. Wieder starten
sc.exe start "SqlServerHealthMonitor"

# 5. Protokoll auf Migrationsausgaben und "Application started" beobachten
Get-Content C:\Apps\SqlServerHealthMonitor\logs\*.log -Tail 200 -Wait

Vorgehen — Linux mit systemd

sudo systemctl stop sshm
sudo cp -a /opt/sshm /opt/sshm.backup-$(date +%Y%m%d)
sudo -u sshm dotnet publish -c Release -r linux-x64 --self-contained false -o /opt/sshm
sudo systemctl start sshm
sudo journalctl -u sshm -f

Vorgehen — Docker

docker pull sqlserverhealthmonitor:NEW_TAG
docker stop sshm
docker rm sshm
docker run -d --name sshm \
    -p 8443:8443 \
    -v sshm-keys:/root/.local/share/SqlServerHealthMonitor \
    -e ASPNETCORE_ENVIRONMENT=Production \
    -e ConnectionStrings__DefaultConnection="..." \
    sqlserverhealthmonitor:NEW_TAG
docker logs -f sshm

Das benannte Volume sshm-keys nimmt die DataProtection-Schlüssel über den Neuaufbau des Containers mit. Lassen Sie es weg, müssen sich nach der Aktualisierung alle Benutzer neu anmelden; die verschlüsselten Verbindungszeichenfolgen sind davon nicht betroffen.

Was beim Start passiert

Die Anwendung wendet EF-Core-Migrationen automatisch an, solange DatabaseSettings:EnableAutomaticMigrations auf true steht (Standard). Bei einem sauberen Start sehen Sie etwa:

Applying migration '20260603071304_RemoveSlackChannel'.
Applying migration '20260601...'.

Schlägt eine Migration fehl, beendet sich die Anwendung mit einem Rückgabewert ungleich null und schreibt den Fehler ins Protokoll. Die Datenbank bleibt auf dem vorherigen Schema — Sie können ohne Überraschungen zurückrollen.

Migrationen von Hand ausführen (etwa wenn automatische Migrationen abgeschaltet sind):

# Erfordert die passende Version der EF-Core-Kommandozeile
cd /opt/sshm
dotnet ef database update

Die Aktualisierung überprüfen

Nachdem „Application started“ im Protokoll steht:

  1. /health/detailed aufrufen — beide Prüfungen sollten Healthy melden.
  2. /Settings/License aufrufen — hier wird die Version angezeigt. Prüfen.
  3. /dashboard aufrufen — die Serverliste füllt sich innerhalb eines Aktualisierungszyklus.
  4. Unter /Settings/Notifications für jeden aktiven Kanal eine Testbenachrichtigung auslösen. Schließen Sie nicht von „keine Fehler im Protokoll“ auf „die Kanäle funktionieren“ — bei abweichenden Einstellungen tun sie stillschweigend nichts.
  5. Die Wartungs-Stummschaltung aus Schritt 3 der Vorbereitung wieder entfernen.

Zurückrollen

Falls sich die neue Version danebenbenimmt:

  1. Dienst anhalten.
  2. Datenbank: aus der vor der Aktualisierung angelegten Sicherung zurückspielen. EF-Core-Migrationen laufen nur vorwärts — im Produktivbetrieb lassen sie sich nicht rückgängig machen.
  3. Programmdateien: zurück auf den Ordner .backup-JJJJMMTT wechseln.
  4. Neu starten.

Genau deshalb ist die Datenbanksicherung nicht verhandelbar.