backup: Dump als Stream mit Runner-Stopp und Retries, README nachziehen

Script-Ueberarbeitung aus dem Live-Betrieb nachcommittet: Runner-Stopp
gegen das SQLite-Journal-Race, Dump als Stream (tar.gz statt zip),
3 Versuche mit Retry. README dokumentiert das neue Verfahren und den
aktuellen Pausen-Zustand des Crons (Backlogs CFGMON-09).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

README.md

@@ -67,14 +67,16 @@ Cloud-Firewall, ohne die Zertifikatsprüfung zu brechen.
 
 ## Backup & Restore
 
-Warm-Backup (laufender Betrieb, nächtlich per Cron des Users `rantanplan`):
-
-```bash
-docker exec -u git -w /tmp thread-net-git-gitea-1 \
-  gitea dump -c /data/gitea/conf/app.ini -f /tmp/gitea-dump.zip
-docker cp thread-net-git-gitea-1:/tmp/gitea-dump.zip /opt/backup/gitea-dump-$(date +%F).zip
-docker exec thread-net-git-gitea-1 rm /tmp/gitea-dump.zip
-```
+Warm-Backup: nächtlich um 03:17 per Cron des Users `rantanplan`
+(`backup/gitea-backup.sh`, Log: `/opt/backup/backup.log`).
+**Derzeit pausiert** (Cron auskommentiert, seit 2026-07-30): die Backups
+sollen off-host in ein Borg-Repo auf einer Storage Box, bis dahin bleibt
+der letzte Dump vom 2026-07-30 liegen — siehe CFGMON-09 im Repo
+`sorb/Backlogs`. Das Skript
+stoppt kurz den Runner (SQLite-Journal-Race bei `gitea dump`), streamt
+den Dump ohne Zwischenkopie (`gitea dump --type tar -f - | gzip`) und
+behält **nur den neuesten Stand** auf dem Host — die 38-G-Platte trägt
+nicht mehr. Manuell: einfach das Skript ausführen.
 
 Restore auf frischem Host: Volume `thread-net-git_gitea-data` anlegen,
 Dump-Zip entpacken (`gitea-repo.zip` → `/data/git/repositories`,
@@ -84,7 +86,7 @@ https://docs.gitea.com/administration/backup-and-restore
 
 **Off-Host-Kopie nicht vergessen** — ein Backup auf demselben Host schützt
 nicht vor Plattenverlust:
-`scp -P 2248 rantanplan@188.245.193.243:/opt/backup/gitea-dump-<datum>.zip .`
+`scp -P 2248 rantanplan@188.245.193.243:/opt/backup/gitea-dump-<datum>.tar.gz .`
 
 ## Bezüge