> ## Content Index > Fetch the complete content index at: https://lab.mackedanz.net/llms.txt > Use this file to discover other available public pages before exploring further. # Mein Backup-Server läuft nur Freitag und Samstag – und wie zwei stille Bugs die Backups monatelang killten - URL: https://lab.mackedanz.net/proxmox-backup-server-strom-bugs/ - Published: 2026-09-07T16:50:14.000Z - Updated: 2026-09-07T16:52:15.000Z - Description: PBS per HA-Steckdose nur zum Backupfenster an. Klingt simpel – drei zeitliche Fallen ließen die Sicherungen monatelang ohne Fehlermeldung scheitern. - Author: Michael Mackedanz - Tags: Proxmox, Backup, Home Assistant, Homelab *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-` 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*](https://lab.mackedanz.net/proxmox-reboot-nachts-6-uhr/)*. — 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*](#/portal/signup)*.*