2.0 KiB
Rollback
Current status
There is no production release, backup, or installed rollback helper. The repository contains a root-owned rollback helper and a separate installer, but neither has been run on the VPS.
After a verified cold backup is created before a release, an owner must check that the data format is compatible with the prior backend/OpenSearch images. Then run the limited helper with that archive:
sudo -n /usr/local/sbin/akyldash-rollback \
/var/backups/akyldash/<pre-release-backup>.tar.gz --data-compatible
The helper verifies archive integrity, Compose image references, deployment
file hashes, and the availability of both prior local images. It makes and
verifies a second cold backup, restores only the prior backend/OpenSearch image
tags, waits for Compose healthchecks, and checks HTTPS locally. Digest-pinned
references are validated against their recorded local image IDs, but rollback
fails before stopping services or making a backup when either image reference
uses @sha256:. The helper cannot safely switch immutable digest references
with the current release-recording flow. Do not retag a digest manually; digest
rollback needs a separately reviewed atomic release-reference mechanism.
It refuses to restore if the current Compose/Caddyfile differs from the saved release. This does not restore data or automatically undo a release with an unknown schema change. The application has no formal migration framework; compatibility must be checked for every change. If it is uncertain, stop and ask the owner.
The initial owner-run deployment must record its running backend image ID in
/opt/akyldash/deployed-image.txt with mode 0600; the rollback helper updates
that record after a successful rollback, and infra/bootstrap/verify.sh checks
it against the running container.
Any data restore requires the owner, a verified pre-change backup, and a maintenance window. Preserve the failed release and both backups until recovery is confirmed.