A backup matters when you can restore the right data into a usable system.
Persistence solves one problem
A persistent volume keeps data outside a container’s temporary writable layer. It can survive replacement of that container. It does not automatically protect against accidental deletion, corruption, lost infrastructure, or a malicious write.
Object storage is another storage model: data is stored as named objects through an API. It is commonly used for uploads and backup artifacts. It is not a drop-in replacement for a database filesystem.
Decide what you can lose
Your recovery point objective describes how much recent data loss you can tolerate. Your recovery time objective describes how long recovery may take. These are targets you choose and verify, not guarantees created by setting a backup schedule.
A daily backup can leave a large gap if a failure happens just before the next run. A backup that takes hours to restore may not meet a short recovery target. Include the time needed to find credentials, prepare infrastructure, restore data, reconnect the application, and verify behavior.
Keep the keys with the plan
Encrypted backups protect artifacts, but the recovery key becomes essential. Store it securely outside the system it is meant to recover. Keep access scoped to the destination and understand retention and deletion permissions.
A backup of a platform’s configuration is not necessarily a backup of application data. Inventory databases, volumes, object storage, encryption keys, external services, and configuration separately.
In Hakopod
Supported PostgreSQL and MySQL backup workflows send encrypted artifacts to S3-compatible object storage. Operators configure destinations and schedules, retain recovery keys, and review restore operations. Current backup and restore APIs require an unrestricted installation administrator.
Restoring to a fresh database is separate from changing application connection settings. Configuration rollback is separate again. Do not infer data recovery from a successful deployment rollback.
Rehearse before an incident
Restore into a separate environment. Check that the artifact decrypts, the database accepts it, the application connects, and important records are present. Record the artifact time and how long the exercise took. Remove the rehearsal environment deliberately when you are done, keeping the original backup and recovery records intact.
A volume survived a container restart. Does that demonstrate recovery from server loss?
Reveal the answer
No. It demonstrates persistence across that restart. Server-loss recovery needs independent backup artifacts, available keys, a destination to restore into, and a successful rehearsal.