Skip to content

Backup repairs observed deployed — 2026-10-24

The repairs from PR #469 and PR #470 are now observed deployed on infra-services. The existing scheduled Ansible apply completed successfully; no manual apply, reload or restart was needed. Recovery acceptance remains open.

What the read-only checks established

Observations at 2026-10-25 01:31–01:33 UTC (October 24 local PDT) found:

  • All 20 expected host-assigned backup jobs have one combined-path invocation on disk and in loaded systemd state, with the new path-set marker and expected paths.
  • The staging helper, weekly wrapper, checksum verifier and three writer/drill pairs match the merged source revision by SHA-256: nine files checked.
  • The host checkout reports merged revision 819c9dfbe2f27096c4bf4778cccbb8a3b0f0117d; required Python capabilities and PyYAML are available.
  • The scheduled apply finished at 01:32:23 UTC, with 415 tasks OK, 40 changed, zero failed/unreachable, and 94 skipped.

These are deployment observations, not evidence of a new complete snapshot, offsite copy, usable application backup or successful restore. Old backup-success timestamps predate the unit changes and do not satisfy the new acceptance gates.

Why the units initially looked stale

The earlier observation happened during an unfinished apply. Both disk and loaded units were old, so a daemon reload alone was not the missing step. Read-only task observations showed progression through earlier plays and the backup role's common dependency before the new units appeared. The complete run took approximately 22 minutes; no failure or stuck lock was established.

The existing configured SSH alias worked through the owner's agent. No SSH trust configuration was changed. An isolated local Ansible-version compatibility check also ruled out a suspected assertion-escaping defect; no speculative production code change was made.

Phase status

Concern Status Required before closure
REC-001 / INC-002 / OPS-043 Deployed New complete local/offsite recovery sets, isolated application integrity and rollback evidence
INC-003 Deployed Trusted relocated artifacts and isolated application recovery, not just checksum agreement
Other 251 concerns Backlog Separate scoped repairs and their own acceptance evidence
flowchart TD
    Merge[Reviewed repairs merged] --> Scheduled[Existing scheduled apply]
    Scheduled --> Observe[Read-only deployment observations]
    Observe --> Deployed[Record two concerns deployed]
    Deployed --> Snapshots[Verify new local and offsite snapshots]
    Snapshots --> Restore[Approved isolated application restore and rollback]
    Restore --> Accept[Owner acceptance before closure]

The private registry and dated evidence are available through the repository README. Prior failed attempts, source-test records and historical observations are retained, not rewritten. Work used an isolated worktree to leave the owner's uncommitted application changes untouched.

Next gate

No broad convergence correction is needed on this evidence. Wait for scheduled backups or approve a specifically scoped backup/isolated-restore exercise, with its storage, retention and cleanup effects disclosed first. No backup, restore, secret decryption, offsite access or cleanup was triggered by this observation; the run's 40 changes belong to the pre-existing scheduled automation.

Related: checksum repair, first recovery repair, and restore prerequisites.