2.0 KiB
Rollback
The current rollback implementation is code only. PR #59 has not been merged, installed, or run against the VPS. No current production release state or external backup has been verified; production rollback is therefore not available yet.
After owner installation and separate-target restore validation, rollback is an owner-controlled Windows-to-VPS session. The Windows client reads the exact previous backup identity pinned in root-owned release state, validates the saved archive and sidecar, then sends it over SSH. The VPS accepts the bytes only when size and SHA-256 match that root-pinned identity. It verifies the current deployment against release state, stops Compose, and streams a fresh cold backup to Windows before changing either image reference.
The rollback helper verifies deployment-file hashes, previous image refs and
image IDs, and that the fresh backup matches the current image IDs. It does not
restore application data, OpenSearch contents, or secrets. It uses the shared
deployment lock, atomically switches both image references, starts Compose
with --no-build, verifies running image IDs and the local /review health
route, then records the new release state. Failures attempt to restore the
pre-rollback references and services; unresolved recovery is recorded in a
root-owned journal and blocks subsequent release/rollback operations.
The former akyldash-rollback <VPS path> interface now fails closed and performs
no Docker operation. Local /var/backups/akyldash archives cannot authorize a
rollback. Legacy release states without a verified external previous_backup
identity also cannot authorize this rollback path.
The application has no formal migration framework. Check schema and index compatibility before rollback. If compatibility is uncertain, stop; do not attempt a data restore as part of an image rollback. A data restore requires a separate owner-approved recovery plan and maintenance window. See backup and restore and deployment.