Linuxguide

Backup-Monitoring – Ausfaelle fruehzeitig erkennen 2025

Automatische Ueberwachung ob Backups erfolgreich laufen

S
SeeColors IT
11. Juni 20264 Min. Lesezeit130 Aufrufe

Warum Backup-Monitoring essentiell ist

Haeufigste Backup-Fehler:
  - Disk voll → Backup bricht still ab
  - Netzwerkfehler → Backup haengt
  - Passwort geaendert → Authentication Error
  - Service nicht gestartet → kein Backup
  - Konfigurationsfehler nach Update

Symptom: System "laeuft" aber Backups seit Tagen fehlgeschlagen
Entdeckung: Erst wenn Wiederherstellung benoetigt wird

Monitoring-Loesung: Healthchecks (Dead-Man-Switch)
  "Wenn ich nicht innerhalb von X Stunden gemeldet habe → ALARM!"

Healthchecks.io (empfohlen)

# Healthchecks.io (kostenlos bis 20 Checks)
# Oder self-hosted: healthchecks/healthchecks (Docker)

# Docker-Selbsthosting
docker run -d     --name healthchecks     -p 8000:8000     -e SECRET_KEY=geheimer-key     -e SITE_ROOT=http://healthchecks.firma.local:8000     ghcr.io/healthchecks/healthchecks

# Check anlegen:
# Web-UI → + Add Check
# Name: "Server01 Restic Backup"
# Schedule: Every day at 03:00 (cron: 0 3 * * *)
# Grace time: 1 hour

# Ping-URL erhalten: https://hc/ping/UUID

# In Backup-Script einbauen:
BACKUP_URL=https://healthchecks.firma.local/ping/UUID-HIER

# Erfolg pingen:
restic backup ... && curl -fsS --retry 3 BACKUP_URL

# Bei Fehler starten pingen:
curl -fsS --retry 3 "BACKUP_URL/start"
restic backup ... || curl -fsS --retry 3 "BACKUP_URL/fail"
curl -fsS --retry 3 BACKUP_URL

Systemd + E-Mail-Alert

# Backup-Service mit OnFailure-Handler

# /etc/systemd/system/[email protected]
cat << 'EOF' > /etc/systemd/system/[email protected]
[Unit]
Description=E-Mail Alert fuer fehlgeschlagenen Backup-Job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-alert.sh %i
EOF

# /usr/local/bin/backup-alert.sh
cat << 'EOF' > /usr/local/bin/backup-alert.sh
#!/bin/bash
SERVICE="$1"
HOST=$(hostname)
echo "BACKUP FEHLER auf $HOST: Service $SERVICE fehlgeschlagen!" |
    mail -s "[ALERT] Backup Fehler: $SERVICE auf $HOST" [email protected]
EOF
chmod +x /usr/local/bin/backup-alert.sh

# Backup-Service erweitern:
cat << 'EOF' >> /etc/systemd/system/restic-backup.service
[Unit]
OnFailure=backup-alert@%n.service
EOF

systemctl daemon-reload

Prometheus + Grafana Backup Dashboard

# restic-exporter (Prometheus-Metriken fuer Restic)
docker run -d     --name restic-exporter     -e RESTIC_REPO=/backup/server     -e RESTIC_PASSWORD_FILE=/root/.restic-password     -p 8080:8080     restic-exporter:latest

# Metriken:
# restic_backup_files_new (neu gesicherte Dateien)
# restic_backup_duration_seconds (Backup-Dauer)
# restic_last_snapshot_timestamp (letzter Snapshot)

# Grafana Alert: Wenn letzter Snapshot > 25h → ALERT!

FAQ

Wie lange sollte die Grace Time bei Healthchecks sein?
Backup-Dauer x 2 + 1h. Wenn ein Backup normalerweise 30 Min dauert: Grace Time = 2h. Bei Netzwerkproblemen laeuft Backup laenger.

Fazit

Backup-Monitoring mit Healthchecks (Dead-Man-Switch-Prinzip) ist das einfachste und zuverlaessigste Monitoring: kein Ping = sofortiger Alarm.

Backup-Monitoring fuer KMU in Heidelberg, Mannheim und der Rhein-Neckar-Region. Beratung anfragen.

Artikel teilen

War dieser Artikel hilfreich?

Dein Feedback hilft uns, bessere Inhalte zu erstellen.

Kommentar hinterlassen

Verwandte Artikel