Mein Backup-Server läuft nur Freitag und Samstag – und wie zwei stille Bugs die Backups monatelang killten

Den Proxmox Backup Server nicht rund um die Uhr laufen zu lassen, spart Strom und Verschleiß. Der Aufbau ist in zehn Minuten erklärt. Die Fallen darin haben mich Monate an unbemerkt fehlgeschlagenen Backups gekostet.

TL;DR

Der PBS wird per schaltbarer Steckdose über Home Assistant nur zum Backupfenster eingeschaltet, ein Skript auf dem PBS fährt ihn danach wieder herunter. Zwei voneinander unabhängige Fehler sorgten dafür, dass der wöchentliche Job scheiterte – ohne dass es je eine sichtbare Fehlermeldung gab. Ein dritter, subtilerer kam beim Aufräumen dazu.

Der Aufbau

• HA-Automation schaltet die Steckdose Freitag und Samstag um 23:45 ein.
• Backups starten 23:55 (2-TB-Datastore Freitag, 4-TB-Datastore Samstag).
• Ein Skript läuft auf dem PBS per Cron alle 10 Minuten, prüft, ob noch ein Task läuft oder eine Verbindung auf Port 8007 offen ist, und fährt den Server sonst herunter.
• Danach übernimmt der PBS seine eigene Wartungskette: Prune 00:30, Garbage Collection 01:00, Verify 02:00.

Klingt wasserdicht. War es nicht.

Bug 1: Die Zehn-Sekunden-Regel, die „fünf Minuten" heißen sollte

Eine zweite HA-Automation soll die Steckdose wieder abschalten, wenn die Leistung unter 10 W fällt – als Sicherheitsnetz, falls das Skript mal nicht runterfährt. Der numeric_state-Trigger hatte ein for: von 10 Sekunden, obwohl die Beschreibung „5 Min" sagte.

Beim Hochfahren zieht so ein Server nicht gleichmäßig Strom. Ein kurzer Dip unter 10 W im Boot – ein paar Sekunden – reichte, damit der Trigger nach 10 Sekunden feuerte und der Automation die Steckdose direkt wieder abklemmte. Ergebnis: PBS war rund fünf Minuten nach dem Einschalten wieder tot, lange bevor 23:55 irgendein Backup starten konnte. Der Job auf der Proxmox-Seite lief in „can't connect … Connection timeout".

Bug 2: Der erste Check kommt zu früh

Selbst mit korrigiertem for: wäre es weiter schiefgegangen. Der Cron-Rhythmus ist */10 – der erste Lauf des Shutdown-Skripts nach dem 23:45-Boot landet um 23:50. Da läuft noch kein Backup (Start ist 23:55), es besteht keine Verbindung auf 8007. Das Skript stellte „nichts los" fest und fuhr brav herunter. Fünf Minuten vor dem Start.

Fix: ein Uptime-Guard ganz oben im Skript.

UP=$(cut -d. -f1 /proc/uptime)
[ "$UP" -lt 900 ] && exit 0     # in den ersten 15 min nie herunterfahren

Beide Bugs zusammen erklären, warum das in last -x monatelang als Muster sichtbar war – der PBS ging jede Backupnacht kurz nach dem Einschalten wieder aus. Aufgefallen ist es nicht, weil die PBS-eigene Mailbenachrichtigung ins Leere läuft: Postfix hat keinen Relayhost, /var/mail/root existiert gar nicht. Die „Benachrichtigung bei Fehler" gab es also nie.

Bug 3: Runtergefahren zwischen GC und Verify

Nach den ersten beiden Fixes lief das Backup – aber der Verify-Job nicht. Das Skript fuhr den Server so gegen 01:20–01:40 herunter: nach der Garbage Collection, aber vor dem 02:00-Verify. Der Verify startete nie und wurde von PBS erst beim nächsten manuellen Einschalten als überfällig nachgeholt (einmal live beobachtet: um 14:06 nachmittags, als ich den Server für die Weboberfläche kurz anschaltete).

Fix: ein Wartungsfenster-Guard. Zwischen 23:00 und 02:15 fährt das Skript grundsätzlich nicht herunter – das deckt Backup, Prune, GC und den Verify-Start ab. Der Cron-Bereich wurde bis in die 5. Stunde verlängert, damit ein langer Verify danach noch sauber abgewartet wird.

Und ein Bug beim Fix selbst

Die erste Version der Task-Erkennung nutzte grep -c … || echo 0. grep -c gibt bei null Treffern 0 aus und beendet sich mit Exit-Code 1 – der || echo 0-Teil hängte ein zweites 0 an. Ergebnis: "0\n0", der anschließende Integer-Vergleich warf einen Fehler, und das Skript wäre nie mehr zum Herunterfahren gekommen. Behoben durch Weglassen von || echo 0 und ${VAR:-0} beim Auslesen.

Die eigentliche Lehre

Ein stromgesteuerter PBS hat keine funktionierende „sag mir Bescheid, wenn was klemmt"-Kette. Du musst nach jeder Backupnacht aktiv nachsehen – Task-Log auf der PBS-Seite, last -x für das Ein-/Ausschaltmuster – und darfst dich nicht darauf verlassen, dass „keine Mail" gleich „alles gut" heißt.

Checkliste

• for:-Dauern in Leistungs-getriggerten Automationen gegen die Beschreibung prüfen – Sekunden vs. Minuten
• Shutdown-Skript mit Uptime-Guard (/proc/uptime < 900 → nichts tun)
• Wartungsfenster-Guard, der Backup und Prune/GC/Verify abdeckt – nicht nur das Backup
• Vor jedem Skript-Deploy: alte Version als .bak-<datum> sichern
• grep -c nie mit || echo 0 kombinieren – ${VAR:-0} nehmen
• Nach jeder Backupnacht das PBS-Task-Log lesen. „Keine Fehlermail" ist bei diesem Aufbau kein Signal.

Verwandte Notiz: Nachts um 6 startet mein Proxmox-Server neu. — Der komplette Backup-Zeitplan – vzdump täglich plus PBS wöchentlich, Zeitfenster, Retention, die Prune/GC/Verify-Kette – als fertige Vorlage ist der Kern meines Guide „Proxmox + Home Assistant ausfallsicher". Und ganz unabhängig davon: Sieh heute einmal in dein Backup-Log. Dann hier entlang.