Recover disk space safely and complete metadata-only backup updates

README.md

@@ -1,35 +1,39 @@
 # app-backup – geprüfte Sicherungen für den JR IT Server
 
-Sichert WordPress, Nextcloud, native Gitea-Installationen mit MariaDB, Maildaten und zusätzliche Verzeichnisse. Jede Komponente erhält ein eigenes Archiv. Uploads gehen ausschließlich über ein **rclone-Crypt-Remote**; anschließend wird der gesamte Inhalt durch dieses Remote zurückgelesen und verglichen.
+**21.09.2026 – Speicherblockade:** Bei Platznot bleiben mit `SPACE_KEEP_LOCAL=1`
+mindestens eine bestätigte lokale Sicherung und alle unbestätigten Sätze erhalten.
+Ältere Kopien werden erst nach lokalen Inhalts- und erneuten Offsite-Prüfungen
+entfernt, bis der geplante Platzbedarf gedeckt ist. Die normale Retention bleibt
+bei drei Kopien. [Ablauf und Grenzen](SPEICHER.md),
+[Deployment](UPDATE_ANLEITUNG.md). Die Installation auf Gemini steht aus.
+
+Sichert WordPress, Nextcloud, native Gitea-Installationen mit MariaDB, Maildaten und zusätzliche Verzeichnisse. Jede Komponente erhält ein eigenes Archiv. Uploads gehen ausschließlich über ein **rclone-Crypt-Remote**; anschließend werden Existenz und Größe der Remote-Dateien geprüft. Vollständige Downloads mit Prüfsummen-, Entpack- und DB-Importprüfung erfolgen beim monatlichen Restore-Test.
 
 Die vollständige Analyse, Architektur, Konfiguration, Betriebsanleitung und verbleibenden Grenzen stehen in [Dokumentation.md](Dokumentation.md).
 
-Der [Vorfall vom 15.09.2026 und die korrigierte Rückleseprüfung](REMOTE_READBACK.md)
-sind dokumentiert: begrenzte vollständige Prüfanläufe, eigene Zeitlimits,
-sichtbare Dateiergebnisse und eindeutiger Hinweis auf erhaltene lokale Archive.
-Die anschließende Restore-Abnahme verwendet jetzt ebenfalls begrenzte Downloads
-mit Wiederholungen und sicheren Fehlerdetails; siehe
-[Restore-Test: Downloadfehler](RESTORE_TEST.md#downloadfehler-bei-der-abnahme-am-15092026).
+Seit 16.09.2026 laden Backup, Platzbereinigung und Update-Abnahme keine Archive
+zur Prüfung zurück. Nur kleine Metadaten und der Abschlussmarker werden gelesen.
+Dateien mit falschem Inhalt, aber passender Größe werden erst beim Restore erkannt.
+[Hintergrund und Prüfumfang](REMOTE_READBACK.md).
 
 Neu: [Monatlicher Offsite-Restore-Test](RESTORE_TEST.md) mit vollständiger Prüfung
 aller Komponenten, isoliertem MariaDB-Import und Bereinigung auch bei Fehlern.
 Für knappen Speicher wird jeweils nur eine Komponente verarbeitet. Das Update
 mit `--enable-restore-test` erkennt die Produktions-MariaDB, bereitet das passende
 lokale Docker-Image vor und prüft Initialisierung, Import und Bereinigung. Nach
-Backup und vollständigem Offsite-Restore-Test aktiviert es den Monatstimer.
+Backup mit Remote-Dateiprüfung aktiviert es den Monatstimer.
+`--enable-ai-rem` nimmt auf Gemini `/srv/ai-rem` und `/etc/ai-rem` samt
+Dienststopps wieder auf; siehe [Update-Anleitung](UPDATE_ANLEITUNG.md).
 [Speicherbereinigung und Fehlerbehebung](SPEICHER.md) beschreibt die automatische
 Entfernung erkannter Arbeitsreste und die geschützte lokale Notfallaufbewahrung.
 Ohne Aktivierungsoption bleibt ein bisher deaktivierter Restore-Test deaktiviert.
 
 ## Produktionsstand und verbleibende Abnahme
 
-**Stand 15.09.2026:** Das geprüfte Code-Paket `3730ab4676a5` mit der Korrektur
-für den durch einen Healthcheck verdrängten Apache-Stop ist bereitgestellt;
-der Commit ist auf `origin/master` veröffentlicht. Übertragung und Installation
-auf Gemini sowie ein erfolgreiches Ergebnis der neuen Abnahme sind noch nicht
-bestätigt. Im zuletzt dokumentierten Fehlversuch wurden die Dienste wieder
-gestartet; Backup- und Restore-Test-Timer blieben gestoppt. Die konkreten Befehle
-stehen unter [Deployment des bereitgestellten Pakets](UPDATE_ANLEITUNG.md#deployment-des-bereitgestellten-pakets-3730ab4676a5).
+**Stand 16.09.2026:** Nach erneutem Rücklesefehler bei `nextcloud-data.tar.zst`
+wird der tägliche Inhaltsvergleich durch eine Remote-Datei-/Größenprüfung ersetzt.
+Die Installation dieses neuen Stands auf Gemini steht aus; konkrete Befehle und
+Erfolgskriterien stehen in der [Update-Anleitung](UPDATE_ANLEITUNG.md).
 
 Auf Gemini bestand am 10.09.2026 ein vollständiger Paketlauf mit geschützter
 Dateikopie, DB-Dumps, OneDrive-Upload, vollständigem Rücklesen und separater
@@ -41,7 +45,7 @@ für einen belastbaren Produktionsbetrieb; ihre Abnahme ist noch nicht bestätig
 
 Ein OneDrive-HTTP-409 wurde im zweiten Upload-Versuch überwunden. Der Code erlaubt
 standardmäßig bis zu sechs Kopierversuche und veröffentlicht den Remote-Abschlussmarker
-erst nach erfolgreichem Inhaltsvergleich. Wiederkehrende Konflikte oder endgültige
+erst nach erfolgreicher Remote-Datei-/Größenprüfung. Wiederkehrende Konflikte oder endgültige
 Fehler müssen untersucht werden; ein aktiver Timer allein belegt kein aktuelles Backup.
 Details: [Fehlerbehandlung und Betriebsgrenzen](Dokumentation.md#upload-fehlerbehandlung-und-betriebsgrenzen).
 
@@ -61,7 +65,7 @@ Seit 12.09.2026 lässt sich der Hostname in Mail-Betreff und Bericht mit
 ## Automatisches Update-Paket (empfohlen)
 
 Das neue Paket übernimmt Konfigurationsabgleich, Rechteprüfung, Installation,
-vollständigen Backup-Probelauf und Remote-Restore-Prüfung. Du benötigst auf dem
+vollständigen Backup-Probelauf und Remote-Datei-/Größenprüfung. Du benötigst auf dem
 Server keinen Git-Checkout. Übertrage die gelieferte `.run`-Datei und ihre Prüfsumme
 per SCP und starte im Zielverzeichnis:
 
@@ -101,11 +105,11 @@ Details und geprüfte Grenzen stehen in der Update-Anleitung.
 ## Wesentliche Änderungen
 
 - Funktionierender Restore mit Prüflauf, Entpackmodus, Komponentenauswahl und ausdrücklichem `--apply --yes`.
-- Fehler bei Dump, rsync, Kompression und Rückleseprüfung brechen den Lauf ab.
+- Fehler bei Dump, rsync, Kompression und Remote-Dateiprüfung brechen den Lauf ab.
 - Wartungsmodus und Dienststopps umfassen Datenbankdump **und** Dateikopie. Danach endet die Ausfallzeit; Kompression und Upload laufen aus dem Staging.
 - Vorübergehende systemd-Startsperren verhindern die erneute Aktivierung konfigurierter Writer während der Kopie. Zustands- und Zeitstempelprüfungen brechen bei erkannten Neustarts vor Veröffentlichung ab. Eigene Sperren werden beim Wiederanlauf entfernt; bestehende Maskierungen bleiben erhalten.
 - Laufende Stop-Aufträge sind zusätzlich gegen Verdrängung durch fremde Reload-/Start-Aufträge geschützt. Damit kann ein Healthcheck den geplanten Dienststopp nicht abbrechen; echte Stopfehler brechen das Backup weiterhin ab.
-- Upload und Rückleseprüfung melden ihre Phase und standardmäßig jede Minute rclone-Statistiken im Journal (`RCLONE_STATS_INTERVAL`). Ein laufender Auftrag ist erst nach erfolgreicher Remote-Prüfung abgenommen.
+- Upload und Remote-Dateiprüfung melden ihre Phase und standardmäßig jede Minute rclone-Statistiken im Journal (`RCLONE_STATS_INTERVAL`). Ein laufender Auftrag ist erst nach erfolgreicher Remote-Prüfung abgenommen.
 - Vollständige Sicherungssätze mit SHA-256-Manifest, Archivprüfung und zuletzt hochgeladenem `COMPLETE`-Marker.
 - Retention löscht nur vollständige neue Sicherungssätze und behält mindestens `RETENTION_KEEP_LAST` Läufe. Historische v1-Sicherungen bleiben erhalten; bei Platzdruck gilt zusätzlich die abgesicherte lokale Bereinigung aus [SPEICHER.md](SPEICHER.md).
 - Private Arbeitsverzeichnisse, gemeinsame Sperre für Backup/Restore/Update und Wiederanlaufhinweise nach Abbrüchen.
@@ -174,6 +178,7 @@ In der Konfiguration insbesondere ergänzen/prüfen:
 RCLONE_CONFIG="/root/.config/rclone/rclone.conf"
 RCLONE_REMOTE_BASE="OneDriveCrypt:gemini"  # vorhandenes Crypt-Ziel beibehalten!
 RETENTION_KEEP_LAST=3
+SPACE_KEEP_LOCAL=1                     # nur bei Platznot, nach erneuter Prüfung
 ENABLE_REMOTE_RETENTION="false"          # während der Migration zunächst aus
 MAIL_BACKUP_MODE="stop"
 # Zentrale Mailablage muss existieren; bei ausschließlich in Homes liegenden
@@ -295,10 +300,17 @@ Der Bericht bleibt zusätzlich unter `/var/log/app-backup/report_LAUF.eml` mit
 Modus `600` erhalten. Versandfehler werden protokolliert und verändern das
 Backup-Ergebnis nicht. `--check` und Restore-Prüfungen senden keine Backup-Mail.
 Die Mail bestätigt den Backup-Lauf; beim Update ist weiterhin dessen abschließende
-`result.txt` nach der zusätzlichen Remote-Restore-Prüfung maßgeblich.
+`result.txt` nach Backup und Remote-Dateiprüfung maßgeblich. Der monatliche
+Restore-Test führt seinen eigenen Erfolgsnachweis.
 
 ## Tests
 
+Verifikation am 21.09.2026: **132 unterschiedliche Tests bestanden**, einschließlich
+Speicherblockade, Schutz der letzten lokalen Sicherung, Metadaten-Retries,
+Paketinstallation/Rollback und echtem Benutzer-systemd. Fünf optionale zusätzliche
+Docker-DB-Tests wurden nicht erneut ausgeführt. ShellCheck und Shell-Syntax sind
+erfolgreich; [Details und Grenzen](UPDATE_ANLEITUNG.md#lokale-prüfung-am-21092026).
+
 Der Restore-Test ist separat unter [RESTORE_TEST.md](RESTORE_TEST.md) dokumentiert,
 einschließlich Aktivierung, Platzbedarf, Statusdateien, Fehlern und Bereinigung.