Betrieb & Wartung

Backup & Restore

Backup & Restore

Restic Architektur

Backup & Restore

QNAP Backupziel

Backup & Restore

Synology Replikation

Backup & Restore

Recovery Ablauf

Monitoring & Alerting

Monitoring & Alerting

Überblick

Zweck

Die Infrastruktur von Hainbach 45 verwendet eine zentrale Monitoring- und Alerting-Plattform zur Überwachung kritischer Dienste und Systeme.

Ziele:

Architekturprinzip

Die Monitoring-Plattform basiert auf mehreren spezialisierten Diensten.

Die Umgebung verwendet bewusst:

Verwendete Komponenten

Dienst Funktion
Uptime Kuma Verfügbarkeitsmonitoring
ntfy Push-Benachrichtigungen
Diun Container-Update-Monitoring
Grafana Dashboards / Visualisierung
InfluxDB Zeitreihendatenbank

Hauptfunktionen

Verfügbarkeitsüberwachung

Überwachung von:

Backup-Überwachung

Restic-Backups werden überwacht mittels:

Update-Überwachung

Container- und Systemupdates werden überwacht über:

Push-Benachrichtigungen

Benachrichtigungen erfolgen zentral über:

ntfy

Benachrichtigungen werden auf mobile Geräte zugestellt.

Architekturübersicht

Die Monitoring-Kommunikation erfolgt typischerweise:

Dienste
→ Monitoring
→ ntfy
→ Smartphone

Sicherheitsprinzipien

Die Monitoring-Infrastruktur dient insbesondere:

Architekturentscheidung

Die Umgebung verwendet bewusst:

Dadurch bleibt die Monitoringplattform:

Kritikalität

Folgende Dienste gelten als besonders kritisch:

Dienst Kritikalität
ntfy hoch
Uptime Kuma hoch
Grafana mittel
InfluxDB hoch
Diun niedrig

Zugehörige Seiten

Monitoring & Alerting

Restic-Backup

Zweck

Restic dient als zentrale Backup-Lösung der H45-Infrastruktur.

Die Plattform sichert insbesondere:

Architekturprinzip

Die Backup-Strategie basiert auf folgenden Grundprinzipien:

Architekturentscheidung

Restic wird bewusst:

betrieben.

Dadurch bleiben:

Backupziele

Primärziel

System Funktion
QNAP NAS Hauptbackupziel

Sekundärziel

System Funktion
Synology NAS Replikation

Geplante Erweiterung

Zusätzlich vorgesehen:

Gesicherte Daten

Docker-Daten

Typische Verzeichnisse:

/srv/docker/

Infrastrukturdaten

Beispiele:

Smart Home

Beispiele:

Architekturübersicht

Backupfluss:

Hostsystem
→ Restic
→ QNAP NAS
→ Synology-Replikation
→ Offsite (geplant)

Backupstrategie

Die Umgebung verwendet bewusst:

systemd-Integration

Die Backups werden automatisiert über:

ausgeführt.

ntfy-Integration

Benachrichtigungen erfolgen zentral über:

ntfy

Verwendete Topics:

Topic Zweck
H45-Backup erfolgreiche Backups
H45-Alerts Fehler / Ausfälle

Minimalinvasive Integration

Die ntfy-Integration erfolgt bewusst minimalinvasiv.

Bestehende Backup-Skripte bleiben unverändert.

Die Benachrichtigungen erfolgen stattdessen über:

ExecStartPost=
OnFailure=

innerhalb von systemd.

Architekturentscheidung gegen Containerbetrieb

Restic wird bewusst nicht als Docker-Container betrieben.

Gründe:

Sicherheitsprinzipien

Die Backup-Architektur dient insbesondere:

Restore-Prinzip

Typischer Wiederherstellungsprozess:

1. Zielsystem vorbereiten
2. Daten mittels Restic zurückspielen
3. Docker-Stacks deployen
4. Dienste starten
5. Funktion prüfen

Besonderheiten

Die Umgebung verwendet bewusst:

Dadurch bleibt die Backupplattform:

Dokumentation

Restic-Repositories

Optional Screenshot der Restic-Struktur einfügen

ntfy-Backupmeldungen

Optional Screenshot der Backup-Benachrichtigungen einfügen

systemd-Services

Optional Screenshot der systemd-Units einfügen

Alerting

Alerting

ntfy

Alerting

Diun

Alerting

OS-Updates

Alerting

Push-Benachrichtigungen

Docker Betrieb

Docker Betrieb

Allgemein

Zielsetzung

Die meisten Produktivdienste der Infrastruktur Hainbach 45 werden containerisiert mittels Docker betrieben.

Der Einsatz von Docker ermöglicht:

Die zentrale Verwaltung erfolgt über Portainer.

Architektur

Die Docker-Plattform wird ausschließlich auf dem App-Server betrieben.

Komponente Funktion
Docker Engine Container Runtime
Portainer CE Verwaltungsoberfläche
Docker Volumes Persistente Daten
Docker Networks Container-Kommunikation
NGINX Proxy Manager Veröffentlichung von Diensten

Architekturübersicht

[Abbildung: Docker-Containerlandschaft App-Server]

Grundprinzipien

Für den Betrieb gelten folgende Grundsätze:

Persistente Daten

Alle produktiven Anwendungen speichern ihre Daten außerhalb des Containers.

Beispiele:

Anwendung Speicherort
Nextcloud Docker Volume
Vaultwarden Docker Volume
Grafana Docker Volume
InfluxDB Docker Volume
BookStack Docker Volume
ntfy Docker Volume

Dadurch bleiben Daten bei Container-Neuerstellung erhalten.

Netzwerkkonzept

Container kommunizieren über dedizierte Docker-Netzwerke.

Externe Zugriffe erfolgen grundsätzlich über:

Client → DNS → NGINX Proxy Manager → Container

Direkte Portfreigaben sollen vermieden werden.

Containerverwaltung

Die Administration erfolgt über Portainer.

Aufgaben:

Backup

Container selbst werden nicht gesichert.

Gesichert werden:

Die Sicherung erfolgt mittels Restic.

Updates

Verfügbare Container-Updates werden über Diun erkannt.

Ablauf:

  1. Diun meldet neues Image
  2. Update wird manuell geprüft
  3. Container wird aktualisiert
  4. Funktionstest durchführen
  5. Monitoring prüfen

Automatische Containerupdates werden nicht eingesetzt.

Monitoring

Folgende Bereiche werden überwacht:

Die Überwachung erfolgt über:

Wiederherstellung

Im Fehlerfall erfolgt die Wiederherstellung in folgender Reihenfolge:

  1. Debian installieren
  2. Docker installieren
  3. Portainer installieren
  4. Stacks wiederherstellen
  5. Docker Volumes wiederherstellen
  6. Container starten
  7. Funktionstest durchführen

Verantwortlichkeit

Verantwortliches System:

Verwaltungswerkzeug:

Docker Betrieb

Container Standards

Zielsetzung

Diese Standards definieren die einheitliche Bereitstellung und Verwaltung von Docker-Containern innerhalb der Infrastruktur Hainbach 45.

Ziel ist eine konsistente, wartbare und reproduzierbare Umgebung.

Containernamen

Containernamen werden grundsätzlich klein geschrieben.

Schema:

Beispiele:

Hostnamen

Server erhalten sprechende Hostnamen.

Beispiele:

Docker Netzwerke

Netzwerke erhalten eindeutige Namen.

Beispiele:

Volumes

Persistente Daten werden ausschließlich in Docker Volumes gespeichert.

Schema:

-data

Beispiele:

Reverse Proxy

Jeder veröffentlichte Dienst erhält:

Direkte Portfreigaben sind zu vermeiden.

Logging

Containerlogs verbleiben lokal auf dem Hostsystem.

Für Fehleranalysen wird primär Portainer verwendet.

Sicherheit

Folgende Grundsätze gelten:

Dokumentation

Jeder Produktivcontainer wird dokumentiert.

Mindestens:

Docker Betrieb

Neuen Container bereitstellen

Zielsetzung

Neue Dienste werden standardisiert bereitgestellt.

Dadurch bleiben Betrieb, Dokumentation und Wiederherstellung nachvollziehbar.

Vorbereitung

Vor der Installation prüfen:

Deployment

Container werden bevorzugt als Docker Stack bereitgestellt.

Ablauf:

  1. Docker Compose erstellen
  2. Stack in Portainer anlegen
  3. Container starten
  4. Funktion prüfen

Netzwerk

Container werden in das erforderliche Docker-Netzwerk eingebunden.

Beispiele:

Reverse Proxy

Falls extern oder intern erreichbar:

  1. DNS-Eintrag erstellen
  2. Proxy Host anlegen
  3. SSL-Zertifikat aktivieren
  4. Funktionstest durchführen

Monitoring

Nach Bereitstellung:

Abschluss

Folgende Punkte müssen erfüllt sein:

Docker Betrieb

Container Updates

Zielsetzung

Container werden kontrolliert und nachvollziehbar aktualisiert.

Automatische Updates werden nicht eingesetzt.

Update-Erkennung

Verfügbare Updates werden erkannt über:

Benachrichtigungen erfolgen über:

Updateprozess

  1. Update-Meldung prüfen
  2. Release Notes lesen
  3. Backupstatus prüfen
  4. Container aktualisieren
  5. Funktion testen
  6. Monitoring prüfen

Durchführung

Aktualisierung über:

Dabei wird das aktuelle Image neu geladen.

Funktionstest

Nach jedem Update prüfen:

Rollback

Bei Problemen:

  1. Vorheriges Image verwenden
  2. Stack erneut deployen
  3. Backup nur im Ausnahmefall zurückspielen

Dokumentation

Größere Versionssprünge werden dokumentiert.

Beispiele:

Docker Betrieb

Backup-Konzept

Zielsetzung

Container selbst sind austauschbar.

Gesichert werden ausschließlich persistente Daten und Konfigurationen.

Backup-Prinzip

Nicht gesichert:

Gesichert:

Backup-Werkzeug

Für alle Server wird Restic verwendet.

Vorteile:

Backupziel

Primäres Ziel:

Sekundäres Ziel:

Sicherungsumfang

Beispiele:

Nextcloud

Vaultwarden

Grafana

InfluxDB

BookStack

Überwachung

Backupstatus wird überwacht über:

Wiederherstellung

Ablauf:

  1. Docker installieren
  2. Volumes wiederherstellen
  3. Stack bereitstellen
  4. Container starten
  5. Funktionstest durchführen

Grundsatz

Ein Container muss jederzeit ohne Datenverlust neu erstellt werden können.

Docker Betrieb

Netzwerke

Zielsetzung

Docker Netzwerke dienen der logischen Trennung und Kommunikation von Containern.

Grundprinzip

Container kommunizieren nicht direkt über das physische Netzwerk.

Die Kommunikation erfolgt über Docker-Netzwerke.

Vorteile

Netzwerktypen

Proxy

Enthält:

Monitoring

Enthält:

Backend

Interne Kommunikation zwischen Diensten.

Veröffentlichung

Externe Zugriffe erfolgen ausschließlich über:

DNS → Reverse Proxy → Container

Direkte Containerports sind zu vermeiden.

Fehleranalyse

Prüfen:

Docker Betrieb

Lifecycle

Übersicht

Jeder Container durchläuft einen definierten Lebenszyklus.

Planung

Vor Deployment prüfen:

Bereitstellung

Deployment über:

Betrieb

Während des Betriebs:

Wartung

Regelmäßig:

Außerbetriebnahme

Vor dem Entfernen:

  1. Daten sichern
  2. Abhängigkeiten prüfen
  3. Dokumentation aktualisieren

Entfernung

Löschen:

Volumes nur löschen, wenn keine Daten mehr benötigt werden.

Updates

Updates

Debian Updates

Zielsetzung

Die Linux-Server der Infrastruktur werden regelmäßig aktualisiert, um Sicherheitslücken zu schließen und die Systemstabilität zu gewährleisten.

Betroffene Systeme:

Updateüberwachung

Verfügbare Updates werden automatisch erkannt.

Überwachung erfolgt über:

Prüfroutine

Vor jedem Update prüfen:

Durchführung

Aktualisierung:

sudo apt update
sudo apt upgrade

Falls erforderlich:

sudo apt full-upgrade

Neustart

Nach Kernel-Updates oder sicherheitsrelevanten Änderungen kann ein Neustart erforderlich sein.

Prüfung:

needs-restarting -r

oder

cat /var/run/reboot-required

Kontrolle

Nach dem Update prüfen:

Verantwortlichkeit

Systemadministrator

Updates

Container Updates

Zielsetzung

Container werden kontrolliert aktualisiert.

Automatische Updates sind nicht aktiviert.

Update-Erkennung

Diun überwacht alle Containerimages.

Benachrichtigung erfolgt über:

Standardprozess

  1. Update-Meldung prüfen
  2. Changelog lesen
  3. Backupstatus kontrollieren
  4. Update durchführen
  5. Funktionstest durchführen

Durchführung

Portainer öffnen

Stack auswählen

Redeploy:

Kontrolle

Prüfen:

Rollback

Falls erforderlich:

Backups werden nur im Ausnahmefall eingespielt.

Updates

NAS Updates

Zielsetzung

NAS-Systeme werden regelmäßig aktualisiert.

Betroffene Systeme:

Vorbereitung

Vor Updates prüfen:

Synology

Aktualisierung über:

Systemsteuerung → Aktualisierung & Wiederherstellung

Prüfen:

QNAP

Aktualisierung über:

System → Firmware Update

Prüfen:

Nachkontrolle

Prüfen:

Dokumentation

Größere Versionswechsel dokumentieren.

Updates

Netzwerkgeräte Updates

Zielsetzung

Router, Switche und Access Points werden regelmäßig aktualisiert.

Betroffene Systeme

Vorbereitung

Vor Updates prüfen:

Durchführung

Verwaltung über Omada Controller.

Pfad:

Devices → Firmware → Upgrade

Reihenfolge

Empfohlene Reihenfolge:

  1. Controller
  2. Access Points
  3. Switche
  4. Router

Nachkontrolle

Prüfen:

Dokumentation

Firmwarestände regelmäßig erfassen.

Updates

Update Strategie

Grundsatz

Updates werden kontrolliert und nachvollziehbar durchgeführt.

Automatische Produktivupdates werden nicht eingesetzt.

Priorisierung

Kritisch

Sicherheitslücken

Bearbeitung:

Hoch

Stabilitätsprobleme

Bearbeitung:

Normal

Funktionsupdates

Bearbeitung:

Wartungsfenster

Empfohlen:

Vermeiden:

Kontrollpunkte

Nach jedem Update prüfen:

Dokumentation

Größere Änderungen werden dokumentiert.

Updates

Reboot Strategie

Zielsetzung

Neustarts erfolgen kontrolliert und möglichst selten.

Reihenfolge

Einzelserver

  1. Backup prüfen
  2. Dienste stoppen
  3. Neustart durchführen
  4. Funktionstest

Infrastruktur

Falls mehrere Systeme betroffen:

  1. Router
  2. Switches
  3. Edge-Server
  4. App-Server
  5. IoT-Server

Nachkontrolle

Prüfen:

Dokumentation

Ungeplante Neustarts dokumentieren.

Troubleshooting