Database snapshots and recovery
Match an archive to its consistency boundary, restore separately and review application cutover.
Self-hosted alpha.47 includes PostgreSQL, Redis and MongoDB. MySQL, ClickHouse, Oracle Database, Vitess, Neon and Supabase remain unavailable while native qualification is incomplete. Check the managed database guide for availability; these guides describe source behavior, not a production deployment.
Recovery starts with the capture semantics#
An encrypted archive can be intact and still represent a different consistency boundary from the one an application expects.
| Engine | What capture represents | What it does not establish |
|---|---|---|
| PostgreSQL | A logical custom-format dump of the application database. | Continuous WAL recovery or installation-wide point-in-time recovery. |
| Redis | Captured values and expiries, consistent per shard. | One atomic snapshot across the whole cluster. |
| MySQL | Logical capture while a global read lock holds writes and DDL. | An uninterrupted online backup or continuous binlog recovery. |
| MongoDB | One snapshot read timestamp across supported application collections, with metadata checks. | Continuous oplog recovery. |
| ClickHouse | A native archive for each shard, captured sequentially. | A transactionally consistent snapshot across shards. |
| Oracle Free | APP schema Data Pump capture at a flashback SCN, with a DDL guard. | RMAN, archived-redo recovery or Data Guard. |
| Vitess, under construction | Framed per-shard logical dumps with version, shard map and VSchema. | Global cross-shard snapshot consistency or accepted runtime recovery. |
The managed backup pipeline encrypts archives, records their digest and verifies stored bytes. Restore authenticates the archive before database writes. It requires a separate compatible empty target, closes application ingress, revokes existing target sessions and records recovery progress durably. Failed recovery leaves that target isolated for inspection or deletion; it must not be treated as an empty target for another attempt.
A PostgreSQL example:
hakopod database restore-plan TARGET_ID --artifact-id ARTIFACT_ID
hakopod database restore TARGET_ID --artifact-id ARTIFACT_ID --review-id REVIEW_ID --name recovered-orders
hakopod database inspect TARGET_ID --job-id JOB_ID --revision REVISION --name recovered-orders --inspected
hakopod database connection-plan TARGET_ID --application-id APP_ID --service api --variable DATABASE_URL --endpoint read_write
hakopod database connect TARGET_ID --review-id CONNECTION_REVIEW_ID --name orders-app
Use real IDs and the exact target/application names from your review. Before acknowledging inspection, check representative rows, binary values, indexes, constraints, views and an application read/write path. Inspection and connection replacement are separate actions. Stop or otherwise account for source writes after capture before switching applications; the archive does not include later writes. Keep the source until the cutover is accepted.
See recovery authorization, recovery store, backup runtime and each engine guide for its exact compatible versions and archive limits.
Plan the write boundary#
A restore rehearsal should use disposable data and a separate target. Choose checks meaningful to the application: a row count alone will not catch a missing index, altered validator, broken view or lost binary value. Record the capture time and which writes occurred afterward.
For a planned migration, arrange an application write pause or another explicit reconciliation procedure before the final capture and cutover. Hakopod does not infer how to merge writes made independently to the source and recovered target. Database connection replacement queues a deployment; watch that deployment and verify the application's active connection before retiring the source.
Match evidence to the failure#
- A valid checksum establishes byte integrity. It does not establish usable schema or application behavior.
- A successful native restore into an empty target establishes that tested archive/engine path. It does not establish every version upgrade or unsupported extension.
- A restart test checks process recovery. It does not prove survival after losing a VM or its disk.
- A two-node fixture on one VM exercises scheduling and node-level paths. It cannot establish physical zone independence.
Keep source, target and archive identities in the recovery record. If recovery fails after writes begin, preserve the target's failed status and isolation. Create a fresh empty target for another attempt unless the engine's documented workflow explicitly supports safe continuation.