Wartung, Backups und Fehlerdiagnose: Unterschied zwischen den Versionen
Status-Monitor in Wartungsablauf eingebunden |
MongoDB-Sicherungsverfahren verknüpft |
||
| (Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) | |||
| Zeile 29: | Zeile 29: | ||
| Dokumentation || Übereinstimmung von Projektseite und tatsächlichem System | | Dokumentation || Übereinstimmung von Projektseite und tatsächlichem System | ||
|} | |} | ||
== Datenbanksicherung == | |||
Das tägliche logische Backup der zentralen Datenbank ist unter [[MongoDB sichern und wiederherstellen]] beschrieben. | |||
== Vor einer Änderung sichern == | == Vor einer Änderung sichern == | ||
| Zeile 79: | Zeile 82: | ||
* keine neue Fehlerserie in den Logs | * keine neue Fehlerserie in den Logs | ||
* Dokumentation und tatsächlicher Zustand stimmen überein | * Dokumentation und tatsächlicher Zustand stimmen überein | ||
== Zentraler Server == | |||
Der geprüfte Istzustand und das Berechtigungsmodell sind unter [[Zentraler MegBes-Server – Inventur und Administration]] dokumentiert. | |||
[[Kategorie:MegBes]] | [[Kategorie:MegBes]] | ||
Aktuelle Version vom 7. August 2026, 13:08 Uhr
Wartung, Backups und Fehlerdiagnose
[Bearbeiten]Zweck
[Bearbeiten]Regelmäßige Wartung hält zentrale und lokale MegBes-Komponenten sicher, nachvollziehbar und wiederherstellbar. Änderungen erfolgen projektweise und mit dokumentiertem Rückkehrweg.
Status-Monitor
[Bearbeiten]Der zentrale Status-Monitor unter status.megbes.de zeigt die Health-Zustände der konfigurierten External- und Internal-Instanzen. Ein grüner Status bestätigt die Erreichbarkeit des jeweiligen Management-Endpunkts, aber nicht automatisch den vollständigen Signalweg bis zur Medienstation.
Regelmäßige Kontrollen
[Bearbeiten]| Bereich | Prüfung |
|---|---|
| Container | Laufzustand, Neustarts und aktuelle Fehler im Log |
| Betriebssystem | verfügbare Sicherheitsaktualisierungen und freier Speicherplatz |
| Netzwerk | Erreichbarkeit, DynDNS-Auflösung und Routerweiterleitung |
| Zertifikate | Gültigkeitsende und korrekte Projektzuordnung |
| MegBes-Release | installierter Stand gegenüber freigegebenem Stand |
| Medienstationen | Erreichbarkeit, Rückmeldungen und automatischer Wiederanlauf |
| Dokumentation | Übereinstimmung von Projektseite und tatsächlichem System |
Datenbanksicherung
[Bearbeiten]Das tägliche logische Backup der zentralen Datenbank ist unter MongoDB sichern und wiederherstellen beschrieben.
Vor einer Änderung sichern
[Bearbeiten]Zu erfassen beziehungsweise zu sichern sind mindestens:
- projektspezifische Konfiguration ohne ungeschützte Weitergabe von Geheimwerten
- Containerdefinition, Portzuordnungen und Dateimounts
- aktuell eingesetzter MegBes-Release
- Zertifikats- und Keystore-Dateien in geschützter Ablage
- kundenspezifische Skripte und Stationssoftware
- für Raspberry-Pi-Stationen gegebenenfalls ein geprüftes SD-Karten-Abbild
- Datum, Anlass und verantwortliche Person der Sicherung
Eine Sicherung gilt erst als belastbar, wenn Ablageort, Lesbarkeit und vorgesehener Wiederherstellungsweg geprüft wurden.
Sicherer Wartungsablauf
[Bearbeiten]- Istzustand und konkrete Störung beziehungsweise Wartungsaufgabe dokumentieren.
- Projektbezogene Konfiguration und Release feststellen.
- Rückkehrweg und benötigte Sicherungen vorbereiten.
- Änderung nur an einer klar abgegrenzten Stufe durchführen.
- Logs und unmittelbare Erfolgskriterien prüfen.
- Gesamten Signalweg mit einem kontrollierten Test durchlaufen.
- Stationszustände und Wiederanlauf prüfen.
- Ergebnis und neuen Istzustand auf der Projektseite dokumentieren.
Fehlerdiagnose nach Ebenen
[Bearbeiten]- Bedienoberfläche und Authentifizierung
- `megbes-external` und dessen Containerlog
- DNS, DynDNS und öffentliches Routing
- Router, Portweiterleitung und lokale Firewall
- `megbes-internal` und dessen Anwendungslog
- UDP-Weg im Ausstellungsnetz
- Medienstation, Empfängersoftware und konkrete Befehle
Details: Routing und Signalweg.
Sichere Abbruchpunkte
[Bearbeiten]Die Arbeit wird abgebrochen und der letzte bekannte Zustand wiederhergestellt, wenn die Projektzuordnung unklar ist, eine Änderung mehrere Kundencontainer unerwartet betrifft, Geheimwerte fehlen oder nicht eindeutig zugeordnet sind, keine belastbare Sicherung existiert oder sich der bisherige Release nicht bestimmen lässt.
Nachkontrolle
[Bearbeiten]- öffentliche Anwendung erreichbar
- interner Server erreichbar
- mindestens ein repräsentativer Steuerbefehl erfolgreich
- Rückmeldung einer stationsgesteuerten Station erfolgreich
- keine neue Fehlerserie in den Logs
- Dokumentation und tatsächlicher Zustand stimmen überein
Zentraler Server
[Bearbeiten]Der geprüfte Istzustand und das Berechtigungsmodell sind unter Zentraler MegBes-Server – Inventur und Administration dokumentiert.