app-backup/REMOTE_READBACK.md

Rücklesefehler am 15.09.2026

Befund und Grenzen

Lauf: appbackup_2026-09-15_00-30-51_ed205bcf auf Gemini. Die Laufnamen verwenden UTC: 00:30:51 entspricht 02:30:51 MESZ. Das Ende 06:53:01 MESZ und die gemeldeten 15730 Sekunden (4 h 22 min 10 s) passen zusammen.

Der übermittelte Bericht zeigt erfolgreiche lokale Archiverstellung und das Erreichen der Remote-Rückleseprüfung nach dem Kopierauftrag. Das beweist noch keine erfolgreiche Offsite-Sicherung. Beim Öffnen von nextcloud-data.tar.zst meldet rclone not an encrypted file - bad magic string. Der Crypt-Leser hat keinen gültigen Dateikopf mit der Signatur RCLONE\0\0 erhalten. Das ist keine Diagnose eines beschädigten lokalen zstd-Archivs und auch kein eindeutiger Nachweis falscher Schlüssel. Quelle: Crypt-Dateiformat und Headerprüfung.

Die Zahlen lassen sich aus dem Bericht nachvollziehen:

• Die 13 Archive ohne nextcloud-data.tar.zst ergeben 1.670.479.162 Bytes, also 1,555755 GiB. rclone erfasst beim Inhaltsvergleich beide Leseströme: rund 3,111510 GiB, gerundet die angezeigten 3,112 GiB; das kleine Manifest verändert diese Rundung nicht.
• 14 passende Dateien passen zu diesen 13 Archiven plus manifest.json. COMPLETE und UPLOADED sind bewusst vom Vergleich ausgeschlossen.
• 0 Unterschiede und 2 Fehler widersprechen sich nicht: Ein Lesefehler ist kein erfolgreich festgestellter Inhaltsunterschied. Die Fehlerzählung belegt nicht zwei beschädigte Dateien.
• Die Statistik passt damit dazu, dass alle übrigen Dateien fertig waren und das große Nextcloud-Datenarchiv beim Öffnen hängen blieb. „100 %“ ist hier kein Fortschritt über alle 6,6 GiB Archive. Quelle: rclone 1.74.3 Vergleich, Statistik und Fehlerzählung.

Der konkrete Auslöser bleibt offen: ein falsches/beschädigtes gespeichertes Objekt oder eine vorübergehend falsche Antwort im Downloadpfad sind mögliche Erklärungen. Der Bericht enthält keine HTTP-Antwort oder frühen Retry-Meldungen, 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.

Ergänzung aus den frühen Logzeilen

Bereits vor dem neuen Snapshot trat ein langer Stillstand beim Rücklesen eines anderen Satzes auf: appbackup_2026-09-11_00-38-40_f45e5e2f.

Zeit (MESZ)	Beobachtung
02:31:04	Remote-Zugriff vor der Platzbereinigung; für das Snapshot-Budget fehlen rund 6,77 GB.
02:33:40–02:51:40	Vergleich bleibt bei 3,509 GiB und vermeintlichen 100 % stehen; die angezeigte Rate fällt auf 0 B/s.
02:52:40	Vergleich läuft weiter; Gesamtmenge steigt, Anzeige fällt auf 72 %.
02:53:43	13,431 GiB, 16 passende Dateien, keine Unterschiede; Prüfung erfolgreich.
anschließend	Erst jetzt wird die lokale Kopie vom 11.09. entfernt. Vorprüfungen bestehen; danach werden Wartungsmodus und Dienststopps für den neuen Snapshot aktiviert.

Das bestätigt die Bedeutung der irreführenden Prozentanzeige unabhängig vom späteren Fehler: Der ältere Satz war bei den ersten 100 % noch nicht fertig geprüft. Sein erfolgreicher Abschluss belegt außerdem, dass der lange Stillstand dort vorübergehend war. Der Auszug enthält für diesen alten Satz keinen Crypt-Headerfehler; dieselbe technische Ursache für beide Vorgänge ist daher nicht bewiesen. Ein zeitweiliges Problem im Remote-Lesezugriff ist nun eine stärker gestützte Erklärung. Ein dauerhaft beschädigtes Objekt des neuen Satzes bleibt trotzdem möglich.

Die Speicherbereinigung hat in diesem Lauf ihre Schutzbedingung eingehalten: vollständige Offsite-Prüfung vor lokaler Löschung. Während dieser frühen 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:

sudo grep -nE 'Remote|ERROR|WARNING|Failed|matching files|differences|Service started|Maintenance mode disabled|Complete local' \
  /var/log/app-backup/backup_appbackup_2026-09-15_00-30-51_ed205bcf.log

Was im Code korrigiert wurde

rclone check aktiviert in 1.74.3 keine Wiederholung des gesamten Befehls. RCLONE_RETRIES=6 bedeutete daher bisher nicht sechs vollständige Rückleseversuche. Die gemeinsame Leerlauffrist von einer Stunde und 20 Low-Level-Versuche konnten lange Wartezeiten begünstigen; aus dem Auszug lässt sich die genaue Folge der Wartezeiten nicht rekonstruieren. Quellen: check-Aufruf, Retry-Steuerung, I/O-Leerlauffrist.

Der neue Wrapper gilt für den vollständigen Backup-Rücklesevergleich und die Offsite-Prüfung vor einer lokalen Platzbereinigung:

Einstellung	Default	Bedeutung
RCLONE_CHECK_ATTEMPTS	3	Gesamtzahl vollständiger Versuche, zulässig 1–10
RCLONE_CHECK_RETRY_DELAY	30	Sekunden Pause, zulässig 0–3600
RCLONE_CHECK_TIMEOUT	300	Sekunden I/O-Leerlauf, zulässig 1–3600
RCLONE_CHECK_DEADLINE	3600	Sekunden Prozesslaufzeit je Versuch, zulässig 1–86400
RCLONE_CHECK_LOW_LEVEL_RETRIES	3	Interne Leseversuche, zulässig 1–20

Die neuen Einstellungen sind Ganzzahlen. Sie gelten auch, wenn sie in einer alten Konfiguration fehlen. Die Prozessfrist verwendet GNU timeout und bezieht Backend-Wartezeiten mit ein. Nach Fristablauf sendet es TERM, nach weiteren zehn Sekunden nötigenfalls KILL an die Prozessgruppe. Exit 124 wird als Fristüberschreitung protokolliert; ein durch Signal beendeter Versuch (einschließlich KILL nach Ablauf der Abbruchfrist) wird nicht erneut gestartet. Bei drei normalen Fristüberschreitungen beträgt die maximale Prüfzeit ungefähr 3 Stunden plus zwei Pausen und Abbruchfristen. Die systemd-Gesamtfrist bleibt zusätzlich wirksam. Für größere Sätze oder begrenzte Bandbreite die Frist passend zum vollständigen Vergleich erhöhen; ein langsamer, aber intakter Transfer kann sonst korrekt als nicht abgeschlossen abgebrochen werden.

Jeder neue Prozess liest sämtliche ausgewählten Dateien erneut. Ein Fehler wird erst durch einen späteren vollständigen erfolgreichen Vergleich überwunden. Mehrzeilige Statistiken zeigen aktive Prüfungen; pro Datei erscheint ein Ergebnis (= identisch, ! Lesefehler, * unterschiedlich, +/- fehlend). Quelle: rclone-Prüfberichte.

Bei bleibendem Fehler gibt es keinen neuen Remote-Abschlussmarker, kein lokales UPLOADED und keine nachgelagerte Altersretention. Die lokalen vollständigen Archive bleiben erhalten. Die bisherige Meldung Retained work: none bezog sich allein auf temporäres Staging; jetzt nennt das Fehlerlog zusätzlich den erhaltenen lokalen Sicherungssatz. Die Speicherbereinigung entfernt keine lokale Kopie, deren Offsite-Prüfung scheitert.

Uploads, einzelne Restore-Downloads und deren Einstellungen bleiben beim bisherigen Verfahren. Das Update repariert weder ein beschädigtes OneDrive-Objekt noch veröffentlicht es alte fehlgeschlagene Läufe automatisch. Insbesondere werden keine Crypt-Schlüssel geändert und keine Inhaltsprüfungen abgeschwächt.

Den betroffenen Satz prüfen

Auf Gemini zunächst den vorhandenen lokalen Satz ohne zusätzliche Archivkopie prüfen; dabei werden keine Anwendungsdaten verändert:

sudo /usr/local/sbin/app-restore.sh \
  --local-run /var/backups/app-backup/archives/appbackup_2026-09-15_00-30-51_ed205bcf \
  --verify-only

Eine erneute rein lesende Offsite-Prüfung ist auch ohne Remote-COMPLETE möglich. Der folgende einmalige Diagnosevergleich lädt die Inhalte als Stream, schreibt keine Archive auf Platte und veröffentlicht keinen Marker. Er nutzt die gemeinsame Standardsperre; bei angepasstem LOCKFILE und RCLONE_CONFIG die tatsächlichen Pfade einsetzen. Exit 0 bestätigt nur diesen Vergleich, Exit 124 einen Timeout. Während laufender Backup-/Restore-/Update-Jobs wird die Sperre nicht übernommen:

sudo flock -n /run/app-backup.lock timeout --kill-after=10s 3600s \
  rclone --ask-password=false --config /root/.config/rclone/rclone.conf \
  check /var/backups/app-backup/archives/appbackup_2026-09-15_00-30-51_ed205bcf \
  OneDriveCrypt:gemini/appbackup_2026-09-15_00-30-51_ed205bcf \
  --download --exclude /COMPLETE --exclude /UPLOADED \
  --timeout 300s --contimeout 30s --low-level-retries 3 \
  --stats 1m --stats-log-level NOTICE --combined -

Schlägt derselbe Header erneut fehl, den lokalen Satz erhalten und die vollständigen Logs, betroffene Datei und rclone-Version für die weitere Provideranalyse verwenden. Ein einzelner weiterer Fehlschlag beweist noch nicht, dass das gespeicherte Objekt dauerhaft beschädigt ist. Keine Zugangsdaten, config show-Ausgaben oder HTTP-Dumps mit Tokens weitergeben.

Deployment und Abnahme

Das aus dem Commit gebaute .run-Paket mit .sha256 übertragen und im Wartungsfenster starten; konkrete Schritte stehen in UPDATE_ANLEITUNG.md. Der Installer erhält Konfiguration und Zugangsdaten, erstellt Rollback-Dateien und führt ein neues Backup mit anschließender separater Restore-Prüfung aus. Dadurch entsteht ein neuer Sicherungssatz; der oben untersuchte bleibt als fehlgeschlagener Lauf erkennbar.

Für die Abnahme müssen result.txt SUCCESS, der neue Backupstatus Exit 0 und das Log Remote backup fully read back and verified zeigen. Im Rückleselog müssen alle Dateien erfolgreich geprüft worden sein. Der Backup-Timer wird erst nach erfolgreicher Update-Abnahme aktiviert. Der konkrete Rollback-Pfad steht im Update-Ergebnisordner (rollback-update.sh); bei einem Rollback kehren auch die bisherigen Grenzen der Rückleseprüfung zurück.

Regressionstests verwenden echte lokale Crypt-Transfers, tar/zstd und isolierte MariaDB. Sie prüfen vorübergehende Fehler, echte beschädigte Crypt-Dateiköpfe, bleibende Fehler, Fristablauf mit Wiederholung, Signalabbruch, erhaltene lokale Sätze und das Zurückhalten von Abschlussmarkern. systemd und Providerfehler werden simuliert; ein erfolgreicher lokaler Test belegt keine OneDrive-Abnahme.

Validierung am 15.09.2026:

• tests/run.sh im netzlosen Testcontainer: Bash-Syntax und ShellCheck erfolgreich; 106 Tests entdeckt, 101 bestanden, fünf optionale Docker-in-Docker-Tests ausgelassen. Crypt-Transfers mit rclone 1.60.1-DEV, echte lokale MariaDB ohne TCP.
• Acht gezielte Integrationstests zusätzlich mit der lesend von Gemini kopierten rclone-1.74.3-Binärdatei: alle bestanden. Darunter vorübergehender Lesefehler, beschädigter Crypt-Header, Fristablauf mit erneutem Erfolg, dauerhafter Stillstand, Signalabbruch, gleich große Inhaltsbeschädigung, geschützte Platzbereinigung sowie Paketinstallation und kombiniertes Rollback.
• Das Produktionssystem wurde nicht verändert; die OneDrive-Abnahme steht aus.