Suppose a release changes the API and renames a database column. The new API fails, so you return to yesterday’s image. Yesterday’s API may still fail: it expects the old column, and that column is gone.
Applications have several kinds of state. There is the image and service configuration, the database contents, files in persistent storage, and effects outside the installation such as an email or a payment request. Returning one kind of state to an earlier point does not return the others.
What a Hakopod rollback restores
Selecting an earlier successful release creates a new auditable application revision using its immutable configuration and artifacts. It preserves the record of what happened between the two versions.
That request still needs current permissions, network grants and available capacity. A persistent service can have downtime while it is recreated. A successful old release is a useful recovery candidate, not a promise that today’s infrastructure or dependencies will accept it.
Rollback does not restore database contents, reverse a migration or unsend a message. After applying it, inspect current readiness, pod events and application behavior. Deployment history records an operation’s result at a point in time; it does not continuously certify the application’s health.
Make schema changes reversible at the application layer
When possible, separate a schema change from the release that depends on it. Add the new column or table first. Deploy code that can tolerate the transition. Backfill data with a procedure you can observe and stop. Remove the old representation only after older application versions no longer need it.
Keeping the old schema available lets you roll back the image while older code still needs it. It also makes failure easier to diagnose: a schema expansion, backfill and application behavior change have different failure modes.
Test that sequence against a realistic database copy. A migration that works with ten rows may behave differently with a large table and active writers. Hakopod cannot infer whether application code is compatible with the database you currently have.
Recover data into a separate database
Hakopod’s backup feature creates encrypted logical PostgreSQL or MySQL backups in configured S3-compatible storage. A restore review names the artifact, target service and fresh database to create. Restoring does not silently overwrite the active database or change the application’s connection settings.
That separation gives you a place to inspect recovered data before deciding what should use it. Confirm the expected records, database version and application compatibility. Decide whether to switch the application to the recovered database, repair selected data, or keep investigating.
There are limits to a logical backup. PostgreSQL global roles, WAL and point-in-time recovery are outside this feature’s scope. MySQL users, grants and binlogs are also excluded. Non-transactional MySQL data needs an appropriate maintenance procedure, and a failed restore can leave a partial fresh database for inspection.
Keep recovery material outside the system it restores
The age recovery key is shown once when a destination is created. Keep it separately from the installation. For management-database recovery, preserve the authentication encryption key and installer configuration too.
A management backup contains Hakopod’s records; it does not contain every application database, Kubernetes Secret, persistent volume or external object. Back up those resources separately where your recovery plan requires them.
For each application, write down the artifact to redeploy, the database backup to use, the keys needed to read it and the person who can approve switching traffic. Then rehearse with a fresh target. Record the steps you tested and the decisions that still require an operator.
Read deployments and rollback for configuration recovery and backups for the exact data scope and restore workflow.