Backup-Status pruefen
Backups sind nur nuetzlich, wenn sie funktionieren. So pruefst du den Status.
🤔 Warum Backup-Status pruefen?
Ein Backup, das nicht funktioniert, ist schlimmer als kein Backup - es vermittelt falsche Sicherheit.
Haeufige Backup-Probleme
- ✗ Backup-Job laeuft nicht mehr (nach Update, Neustart)
- ✗ Speicherplatz voll → Backup fehlgeschlagen
- ✗ Zugangsdaten geaendert → Keine Verbindung zum Backup-Ziel
- ✗ Backup korrupt → Restore funktioniert nicht
- ✗ Nur Teile wurden gesichert → Wichtige Daten fehlen
Murphy's Law
"Ein Backup, das nie getestet wurde, wird genau dann versagen, wenn du es brauchst." Regelmaessig pruefen und Test-Restores durchfuehren!
🖥️ Proxmox Backup-Status
Backup-Jobs in Proxmox VE pruefen.
Web-UI
- Datacenter → Backup
- Backup-Jobs anzeigen - sind alle "Enabled"?
- Klick auf Job → "Last Run" zeigt letztes Ergebnis
- Storage → Backups zeigt alle vorhandenen Backups
# Backup-Jobs anzeigen
cat /etc/pve/jobs.cfg
# Letzte Backup-Logs
ls -la /var/log/vzdump/
# Letztes Backup-Log lesen
cat /var/log/vzdump/vzdump-*.log | tail -100
# Alle Backups auf einem Storage
pvesm list local --content backup
# Backup-Datei-Integritaet pruefen
vzdump --info /var/lib/vz/dump/vzdump-qemu-100-*.vma.zst
Was pruefen?
- Last Run: Wann lief das Backup zuletzt?
- Status: "OK" oder Fehlermeldung?
- Groesse: Plausibel oder verdaechtig klein?
- Alle VMs/CTs: Sind wirklich alle gesichert?
🐳 Docker & Restic Backups
Backup-Status fuer Docker-Volumes und Restic-Repositories.
# Letzten Snapshot anzeigen
restic -r /backup/repo snapshots --latest 1
# Alle Snapshots
restic -r /backup/repo snapshots
# Repository-Integritaet pruefen
restic -r /backup/repo check
# Speicherverbrauch
restic -r /backup/repo stats
# Backup-Inhalt anzeigen (Dateien im letzten Snapshot)
restic -r /backup/repo ls latest
# Cron-Logs (Systemd)
journalctl -u cron --since "24 hours ago"
# Oder klassisches Cron-Log
cat /var/log/cron.log | tail -50
# Backup-Skript manuell testen
/path/to/backup-script.sh
# Exit-Code pruefen
echo $? # 0 = OK, alles andere = Fehler
Automatische Backups schweigen oft
Cronjobs zeigen Fehler nicht an wenn sie fehlschlagen! Alerting einrichten oder regelmaessig manuell pruefen.
☁️ Nextcloud & Cloud-Backups
Backup-Status fuer Nextcloud und andere Cloud-Dienste.
Nextcloud
- Admin-Einstellungen → System → pruefen ob Wartungsmodus aktiv
- Datenbank-Backup separat pruefen (nicht nur Dateien!)
- config/config.php muss gesichert sein
Paperless-ngx
- Export-Funktion unter Einstellungen nutzen
- Prueft, dass media/ UND data/ gesichert werden
- Datenbank (SQLite oder PostgreSQL) nicht vergessen
Bitwarden/Vaultwarden
- Regelmaessigen Export erstellen (verschluesselt!)
- data/ Verzeichnis muss im Backup sein
- SQLite-Datenbank ist kritisch
# PostgreSQL - letztes Backup
ls -la /backup/postgresql/
# Backup-Integritaet testen
pg_restore --list /backup/postgresql/dump.sql.gz
# MySQL/MariaDB
ls -la /backup/mysql/
gunzip -t /backup/mysql/dump.sql.gz # Integritaet pruefen
# SQLite (Paperless, Vaultwarden)
sqlite3 /backup/db.sqlite3 "PRAGMA integrity_check;"
🔄 Test-Restore durchfuehren
Der einzig sichere Test: Tatsaechlich wiederherstellen und pruefen!
Test-Restore Checkliste
- ☐ Auf separatem System/VM wiederherstellen (nicht produktiv!)
- ☐ Service startet erfolgreich
- ☐ Daten sind vollstaendig
- ☐ Datum der Daten ist korrekt (nicht uralt)
- ☐ Anmeldung funktioniert
- ☐ Wichtige Funktionen testen
# VM auf anderem Storage wiederherstellen (Test)
qmrestore /var/lib/vz/dump/vzdump-qemu-100-*.vma.zst 999 --storage local
# Container wiederherstellen
pct restore 999 /var/lib/vz/dump/vzdump-lxc-200-*.tar.zst
# Test-VM starten und pruefen
qm start 999
# Nach Test: VM loeschen
qm stop 999
qm destroy 999
# Temporaeres Verzeichnis erstellen
mkdir /tmp/restore-test
# Einzelne Dateien wiederherstellen
restic -r /backup/repo restore latest --target /tmp/restore-test --include "/wichtige/datei.txt"
# Inhalt pruefen
ls -la /tmp/restore-test/
cat /tmp/restore-test/wichtige/datei.txt
# Aufraeumen
rm -rf /tmp/restore-test
Test-Restore Rhythmus
- Monatlich: Kritische Systeme (Datenbank, Passwort-Manager)
- Quartalsweise: Alle anderen Services
- Nach Aenderungen: Backup-Konfiguration oder Service-Updates
🔔 Backup-Alerting einrichten
Automatisch benachrichtigt werden wenn Backups fehlschlagen.
# In /etc/pve/jobs.cfg (Backup-Job)
vzdump: backup-daily
...
mailnotification always
mailto admin@example.com
# Oder nur bei Fehlern:
mailnotification failure
# Backup mit E-Mail bei Fehler
restic -r /backup/repo backup /data || \
echo "Backup fehlgeschlagen!" | mail -s "BACKUP FAILED" admin@example.com
# Oder mit Healthcheck-URL (Uptime Kuma, etc.)
restic -r /backup/repo backup /data && \
curl -fsS https://uptime.example.com/api/push/xxx > /dev/null
# Cronjob-Beispiel mit Logging
# 0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
Monitoring-Integration
Noch besser: Backup-Status in Uptime Kuma oder Wazuh integrieren. So siehst du auf einen Blick ob alle Backups laufen.
💽 Backup-Speicherplatz
Genug Platz fuer Backups und Retention beachten.
# Allgemein
df -h
# Backup-Verzeichnis
du -sh /var/lib/vz/dump/
du -sh /backup/
# Proxmox Storage
pvesm status
# Restic Repository
restic -r /backup/repo stats
| Retention | Bedeutung |
|---|---|
| keep-daily=7 | 7 taegliche Backups behalten |
| keep-weekly=4 | 4 woechentliche Backups |
| keep-monthly=6 | 6 monatliche Backups |
Alte Backups loeschen
Retention-Policy einrichten! Sonst laufen Backups ins Unendliche und der Speicher wird voll. Dann schlagen neue Backups fehl.
Backup-Loesung gesucht?
Wir richten zuverlaessige Backups mit Monitoring und Alerting fuer dich ein.
Beratung anfragen →