Skip to main content

Back up and restore DIAL

Protect DIAL's permanent data so you can recover from accidental deletion, corruption, or a region failure. This guide identifies exactly what to back up, how to use object-store features to do it, and how to restore. It assumes a Helm deployment using cloud object storage for the blob store, with access to your cloud console and kubectl.

Core stores durable resources outside its service instances, but cached writes can await synchronization. Protect permanent stores and configuration, and account for pending writes in the recovery plan. See State and data lifecycle.

Prerequisites​

  • DIAL blob storage on cloud object storage (Amazon S3, Azure Blob Storage, or Google Cloud Storage)
  • Permission to enable versioning and replication on that bucket
  • Access to your secret manager and, if you run Keycloak and/or DIAL Admin with a database backend, to their Postgres databases

What to back up​

TargetWhyWhat happens if lost
Blob storage bucketPermanent data: conversations, files, published resources, app statePermanent data loss
Core encryption secret and keyPreserves bucket addressing for existing resourcesExisting resource addresses may become inaccessible
config.json and settings.jsonModels, roles, keys, and Core settingsManual reconstruction of configuration
DIAL Admin database (only if DIAL Admin is used)The editable source of truth for Core's configuration — Admin generates config.json from it on a scheduleManual reconstruction of all Admin-managed configuration
Postgres database (only if Keycloak is used)Realm, users, and client configurationIdentity provider rebuild
ValkeyCached resources, pending writes, and coordination stateUnsynchronized changes and transient state can be lost; define a recovery policy
warning

Preserve the Core bucket-addressing secret/key and any separate content-encryption or credential-encryption keys. Keep them in a secret manager and verify recovery can access the expected resources. See Manage secrets.

Step 1: Protect the blob storage bucket​

Use the object store's native durability features rather than copying data out:

  • Enable object versioning so overwrites and deletes are recoverable.
  • Enable cross-region replication so a regional failure does not lose data.
  • Set lifecycle rules to expire old versions on a schedule that matches your retention policy.

These are configured in your cloud console, not in DIAL. The per-cloud guides describe the recommended setup — for example, AWS disaster recovery.

Step 2: Back up configuration and the encryption key​

Keep non-secret configuration in protected version control and sensitive configuration and keys in a secret manager — never only in the live cluster. If you supply configuration through the Secrets Store CSI driver, the source of truth already lives in your secret manager; confirm it is itself backed up.

If you manage configuration through DIAL Admin instead of hand-editing config.json, back up Admin's own database (Step 3) — it is the editable source of truth, and the generated config.json is a derived artifact.

Step 3: Back up Postgres (Keycloak and/or DIAL Admin)​

DIAL Core itself needs no relational database, but two optional components do:

  • If you deploy the bundled Keycloak, its Postgres holds your realm, users, and client configuration.
  • If you run DIAL Admin with a Postgres backend (it also supports H2 for smaller deployments — back up its data file the same way you would any persistent volume), its database holds every configuration change made through the Admin UI or API.

Dump each on a schedule:

kubectl exec -n dial <POSTGRES_POD> -- \
  pg_dumpall --clean --if-exists --quote-all-identifiers --no-password \
  > <COMPONENT>-$(date '+%Y-%m-%d').pgdump

Step 4: Restore​

To restore into a new or repaired environment:

  1. Provision blob storage from the versioned or replicated copy, or restore the bucket from the target version.
  2. Restore the encryption secret and key into the cluster or secret manager before starting DIAL Core.
  3. Apply config.json and settings.json.
  4. If you use Keycloak and/or DIAL Admin with a Postgres backend, restore each database from its dump before starting the corresponding service.
  5. Deploy DIAL with helm upgrade/helm install. The stateless services start clean and read permanent data from blob storage; Valkey repopulates on demand.
warning

Helm does not delete PersistentVolumeClaims created by StatefulSets when you uninstall a release. Before reusing a namespace, check for and clean up orphaned PVCs so a restore does not bind to stale data.

Result​

DIAL's permanent data is recoverable: the blob store is versioned and replicated, the encryption key and configuration are backed up off-cluster, and (if applicable) Keycloak's and DIAL Admin's databases have scheduled dumps. The restore recovers persisted resources; unsynchronized cache contents require the separately defined recovery policy.

Coming soon

DIAL ships no first-party backup tool and no scripted, end-to-end restore drill with measured recovery point and recovery time objectives. This guide relies on object-store features and manual database dumps. A tested restore runbook with RPO and RTO targets will be added here.

Further reading​