• Start

Backups & recovery

Create and restore SurrealQL backups with the CLI, plan backup strategies, and prepare for disaster recovery.

Reliable backups are central to operating self-hosted SurrealDB. The CLI provides logical backups as SurrealQL using surreal export, which dumps namespaces, databases, schemas, and data in a form you can version, diff, and store outside the database.

Schedule exports when traffic is lower if large datasets make exports lengthy, and ensure the export process has sufficient disk space and time to finish without overlapping the next run.

To restore, use surreal import against a running instance, pointing at the correct endpoint, credentials, and target namespace or database.

After import, run sanity checks: record counts, critical queries, and application smoke tests before switching production traffic. If you import into a shared cluster, coordinate with application owners so schema or data changes do not race with live writers.

Backup strategies usually combine scheduled exports with storage-engine or volume snapshots where available. Exports are portable and engine-agnostic; snapshots capture disk state quickly but depend on filesystem layout and binary compatibility. Use both when compliance, RPO, or RTO targets demand redundancy across failure modes.

Point-in-time recovery is not implicit in a single export: each file reflects one moment. Narrow your recovery window by exporting more often, maintaining replicas, or using journaled storage upstream of SurrealDB. Document which artefact (export time, snapshot ID, replica lag) corresponds to a given recovery objective.

For disaster recovery, keep copies off-site and logically separated from production credentials, encrypt dumps at rest, and test full restores onto clean hardware or namespaces regularly. Maintain runbooks with exact commands, verification queries, and escalation paths so restores succeed when primary systems are unavailable.

Validate backup integrity periodically: restore to a non-production instance and run application-level checks. Corruption or partial writes are easier to catch in rehearsal than during an incident.

Align retention with policy: keep enough history for audits and incident investigation, but prune or tier old exports so storage costs stay predictable. Where legal holds apply, flag those backups and exclude them from automated deletion.

Was this page helpful?