Back up and restore a standalone database

A backup must preserve the complete database directory and the configuration needed to reopen it. Use a stopped-server filesystem copy for a straightforward standalone backup. This procedure requires filesystem access on the server host.

Prepare a backup

  1. Record the running ShrikeDB version, configuration file, environment overrides, and storage.data_dir.

  2. Stop application writes, then stop the server and wait for its process to exit.

  3. Copy the entire database directory to a separate backup location while the server is stopped. Preserve file contents, permissions, and ownership using your filesystem backup tool.

  4. Save the configuration and any separately stored profile packs, mapping inputs, or external Parquet manifests needed by the application. Store credentials through your normal secret-management process.

  5. Restart the server and verify readiness and a saved application query.

Include all files within the data directory. In particular, the durable Cypher declaration catalog and SpaceKey index data belong with the rest of the database. Copying only selected graph or vector files can leave modalities at different states.

Restore into a separate directory

  1. Use a compatible ShrikeDB binary and an empty restore destination.

  2. Restore the full directory and set its ownership for the server account.

  3. Point a copy of the configuration at the restored directory. Use different ports if the original server is running.

  4. Start the restored server and wait for readiness.

  5. Compare saved payloads, graph queries, named-vector searches, and any SpaceKey batch receipts with their expected values.

Keep the original backup unchanged until verification finishes. An acknowledged schema declaration persists across restart, but rolling back to a binary that predates the durable catalog requires the precautions in Cypher Writes And Schema.

External sources and clusters

Parquet files and other externally referenced sources need their own retention or backup policy. Restoring a catalog does not restore an external file that has been deleted or changed.

Cluster recovery also depends on membership and replication state. This standalone procedure is not a cluster failover procedure; see HA deployment status before planning clustered recovery.