v1.3.0

1. Stiller Ausfall wird gemeldet

Bisher hat jeder Timer nach oben Erfolg gemeldet, aber nirgends nachgesehen, wann das letzte Backup war. Ein toter Backup-Timer sieht damit genauso aus wie ein guter Tag ohne Backup – und genau das ist das Problem.

Nach jedem erfolgreichen Lauf schreibt PABO jetzt einen Zeitstempel, und jeder reguläre Lauf prüft dessen Alter:

❌ Kein erfolgreiches Backup seit 3 Tagen
📅 Letztes Backup vor 3 Tagen
⏳ Erwartet: mindestens alle 2 Tage
🔎 Grund: prüfe den Backup-Timer (systemctl list-timers | grep paperless)

Die Prüfung sitzt in allen drei erzeugten Skripten, nicht nur im Backup. Das ist der entscheidende Punkt: Ein toter Timer erreicht sonst keinen Aufruf, und genau deshalb wäre eine Prüfung im Backup selbst nutzlos.

STALE_BACKUP_DAYS steuert die Schwelle, Standard 2 Tage, im Setup einstellbar und in der Config änderbar. Ohne den Schlüssel gilt der Standardwert, bestehende Configs laufen unverändert.

Was das nicht leistet: Fällt der Host komplett aus – kein Strom, keine Platte, kein Netz –, schweigt auch dieser Check. Er ist die Ergänzung zu einer externen Überwachung, nicht deren Ersatz.

2. Logs rotieren sich selbst

Das Backup-Log war auf einem Host bereits 6,2 MB groß und wuchs unbegrenzt weiter. Das Setup legt jetzt eine Regel unter /etc/logrotate.d/paperless-backup an: wöchentlich, acht Generationen, komprimiert. Vorhandene Regeln werden nicht überschrieben, und fehlt logrotate auf dem System, läuft alles unverändert weiter.

3. Der Restore-Test prüft den DB-Dump wirklich

Bisher genügten die ersten fünf Zeilen des Dumps und die Existenz der Datei. Ein mitten im Schreiben abgeschnittener Dump wäre durchgegangen – und du hättest es erst bei einem echten Restore gemerkt.

Geprüft werden jetzt:

• Mindestgröße
• Zahl der SQL-Anweisungen
• der Abschlussmarker database dump complete, den ein echter pg_dump immer schreibt

Läuft der Datenbank-Container, kommt eine Syntaxprüfung per psql hinzu. Dann ist die Meldung nicht mehr „die Datei sieht gut aus", sondern „der Dump ist lesbar".

4. Die Dateisystem-Warnung greift endlich

Der Vergleich lief über df --output=source. Bei einem BIND-Mount meldet das das Datenverzeichnis als anderes Gerät, obwohl der Speicher derselbe ist – der Hinweis „Repo liegt auf derselben Platte" blieb also aus. PABO löst den Mountpunkt jetzt über findmnt auf und fällt auf df zurück.

5. run_setup() aufgeteilt

397 Zeilen Frageblock sind jetzt neun Funktionen mit Namen. run_setup() hat 91 Zeilen und liest sich als Ablauf. Das Verhalten ist unverändert; ein Befehlsvergleich vor und nach dem Umbau ergibt null verlorene Zeilen.