Confirm upload and service recovery sequence from incident log

REMOTE_READBACK.md

@@ -38,7 +38,8 @@ mit denen sich das unterscheiden ließe. Ein früherer HTTP-409 vom 10.09. ist
 kein Beleg für dieselbe Ursache. SSH bestätigte am 15.09. rclone 1.74.3 auf
 Rocky 10.2. Die geschützten Originallogs und Archive waren ohne interaktive
 sudo-Anmeldung nicht direkt lesbar. Der Betreiber hat anschließend die ersten
-180 Logzeilen bereitgestellt; eine erneute OneDrive-Prüfung wurde nicht ausgeführt.
+180 Logzeilen und einen gefilterten Auszug über den gesamten Lauf bereitgestellt;
+eine erneute OneDrive-Prüfung wurde nicht ausgeführt.
 
 ### Ergänzung aus den frühen Logzeilen
 
@@ -68,9 +69,35 @@ Wartephase hatte das Backup die Anwendungen noch nicht angehalten. Die neuen
 Zeitlimits und Wiederholungen gelten bereits für beide betroffenen Prüfstellen;
 dieser zusätzliche Befund erfordert keine weitere Codeänderung.
 
-Der nachgereichte Auszug endet während der Dateikopie. Für Upload-Versuche,
-Dienstwiederanlauf und den Start der späteren Rückleseprüfung fehlen noch die
-mittleren Logzeilen. Ein kompakter Auszug ohne periodische Byte-Statistiken:
+### Bestätigte Abfolge bis zum Abbruch
+
+Der anschließend bereitgestellte gefilterte Gesamtauszug schließt die Lücke
+zwischen Dateikopie und Fehler. Die Zeilennummern beziehen sich auf das Originallog:
+
+| Logzeilen | Bestätigter Schritt |
+| --- | --- |
+| 248–260 | Wartungsmodus deaktiviert; dovecot, postfix, gitea, php-fpm, httpd und crond.service wieder gestartet. |
+| 275 | Vollständiger lokaler Satz unter `/var/backups/app-backup/archives/appbackup_2026-09-15_00-30-51_ed205bcf` erstellt. |
+| 276 | Upload von Archiven und Manifest begonnen; Abschlussmarker zurückgehalten. |
+| 288 | Upload-Befehl erfolgreich beendet; vollständiges Rücklesen gestartet. |
+| 507–512 | Um 06:53:00 MESZ Crypt-Headerfehler für `nextcloud-data.tar.zst`; 14 passende Dateien und Fehlerexit. |
+
+Die lange Remote-Prüfung fand somit nach dem protokollierten Dienstwiederanlauf
+statt. Die gesamte Laufzeit von 4 h 22 min ist keine Anwendungsausfallzeit.
+Die genaue Dauer der Dienstpause lässt sich aus diesen ungestempelten
+Phasenmeldungen nicht ermitteln; der jetzige Dienstzustand wurde nicht abgefragt.
+
+Im gefilterten Auszug erscheint kein vorausgehender Uploadfehler und insbesondere
+kein HTTP-409. Der erfolgreiche Kopierauftrag allein belegt weiterhin nicht die
+Lesbarkeit des gespeicherten Inhalts. Fehlende Low-Level-/HTTP-Details erlauben
+keine Entscheidung zwischen falscher Downloadantwort und fehlerhaftem Objekt.
+Eine erneute Inhaltsprüfung des betroffenen Satzes ist der nächste Schritt zur
+Eingrenzung; weitere Ausschnitte desselben NOTICE-Logs versprechen dafür wenig.
+Der bestehende Codefix bleibt unverändert gültig und das lokale vollständige
+Backup wird durch seinen Fehlerpfad erhalten. Sein aktueller Zustand kann mit
+der unten beschriebenen lokalen Prüfung bestätigt werden.
+
+Der für den Gesamtauszug verwendete Diagnosebefehl:
 
 ```bash
 sudo grep -nE 'Remote|ERROR|WARNING|Failed|matching files|differences|Service started|Maintenance mode disabled|Complete local' \