railiance-platform/history/2026-09-05-wp0029-real-offsite-recovery.md

WP-0029 real offsite recovery — 2026-09-05

User authorized executing WP-0029. A real September 4 encrypted Forgejo backup was uploaded through Backup's create-only share (201), independently downloaded as owner (200), compared byte-for-byte and decrypted. ZIP validation then rejected it: it has a ZIP header but lacks a complete archive directory. It cannot support application recovery. Evidence is docs/evidence/RPF-WP-0029-rejected-backup-2026-09-05.json. No conclusion about every other historical backup is inferred from this sample.

The previous capture code accepted nonempty archive files after its polling limit, did not require the dump's successful exit, and did not validate the full transfer or ZIP integrity. Replaced it with an exact-process completion marker, per-chunk length checks, producer/receiver SHA-256 equality and ZIP CRC validation before encryption. A new live dump completed at 5,351,717,533 bytes, passed producer/transfer hash and ZIP CRC validation, and contains 142 repository HEAD entries. It is encrypted in private staging; drill-created local plaintext and producer temporary files were removed. Its size materially constrains the dedicated account's 10 GiB retention capacity.

Prepared isolated local recovery with pinned Forgejo 11.0.3/PostgreSQL 16 images, internal-only Docker network, no host ports, disposable database credentials, independent application configuration, and required fetched-artifact hash receipt. The old infra drill's missing-file production-dump fallback and copied production credentials are not used. Database import, application startup, repository clone and package-blob integrity remain live acceptance gates until their receipt passes.

Old-share invalidation requires Bernd's owner confirmation or protected owner custody coordinates; requested without asking for a password in chat. Neither the existing age-key exposure record nor retained backups may be silently cleared.

Implementation validation: 200 repository tests passed. Live completion and cleanup receipts will be appended when available; this entry is not closure.

Resume boundary and runtime delivery

A fresh OpenBao login for the predecessor check failed before command handoff; revocation could not be confirmed. No probe/provider mutation ran in that attempt. It is terminal and cannot be reused. The validated backup still needs a fresh attended upload/download/decrypt session followed by isolated restore.

Encrypted staging: /tmp/rpf-wp0029-restore/forgejo-dump-20260905-verified.zip.age. Use verify_nextcloud_offsite_restore.py with this source, a new private directory and receipt; then restore_forgejo_offsite_locally.py --archive <directory>/fetched.zip --transfer-receipt <receipt> --receipt <new-restore-receipt>. Both scripts are committed. The latter requires the hash-bound downloaded artifact. Retain the encrypted staging until acceptance; remove fetched plaintext after the drill. The rejected candidate's newly created offsite object is forgejo/wp0029-recovery-forgejo-dump-20260904T001507Z.zip.age; remove only this failed test copy through owner authority, preserving original historical backups.

The worker source check found the old capture script still mounted and the new helper absent. Delivered immutable ConfigMap backup-verified-0220ca56520c, with an entry-point wrapper and the complete reviewed backup helper/library bundle. The worker rolled successfully and all four delivered source hashes match. No host checkout was edited. This compatibility delivery is source-owned in scripts/deploy_verified_backup_bundle.py; broader package ownership remains T06. Evidence: docs/evidence/RPF-WP-0029-worker-bundle-2026-09-05.json.

T02 remains waiting for attended access, actual offsite application restore and old-share owner invalidation. No full recovery, old-token rejection or age-key exposure closure is claimed. Fresh archive and rejection receipts are persisted.