v1.3.1

Was kaputt war

Die Zeile [DB] ✅ Dump OK (512) stand 20 Tage in Folge in deinem Log – und sie war reine Anzeigekosmetik mit fataler Nebenwirkung. du -h zählt belegte Blöcke, nicht die Dateigröße. Auf deinem ZFS-Dataset bedeutet das:

Datei	du -h	wirkliche Größe
leer	512	0 B
100 000 B	512	98 K
pg_dump	512	73,8 MB

Die erste Zahl einer leeren Datei ist ein Block, nicht ihr Inhalt. Deine Backups waren also die ganze Zeit in Ordnung – ich habe in der Fehlersuche deshalb zu früh geschlossen, der Dump sei leer.

Was jetzt anders ist

Die Größenangabe stimmt. Alle fünf du-Aufrufe gehen über human_size, das --apparent-size nutzt. Wo GNU coreutils fehlt, fällt es auf wc -c zurück.

Ein leerer Dump gilt als Fehler. pg_dump kann mit Rückgabewert 0 zurückkommen, obwohl kaum etwas geschrieben wurde. PABO prüft den Dump jetzt zusätzlich auf Mindestgröße, Zahl der CREATE/COPY-Anweisungen und den Abschlussmarker database dump complete, den ein echter pg_dump immer schreibt. Statt nur eines Exit-Codes nennt die Meldung den konkreten Grund:

❌ Backup fehlgeschlagen
🔴 Fehler: [DB] PostgreSQL-Dump
⚠️ pg_dump meldete Erfolg, der Dump ist aber unbrauchbar: Abschlussmarker fehlt – vermutlich abgebrochen

Nebenbei gefunden

grep -c kann bei einem Fehlschlag mehrzeilig werden und hat damit in der Dump-Prüfung eine Arithmetik-Abstürzung ausgelöst (syntax error in expression). Normalisiert.

Tests: 163 bestanden, 0 fehlgeschlagen.