Backup and restore
/ Backup, / RestoreBackup and restore #
Pizza does not have a first-class backup/restore HTTP API yet — this page describes what exists today and the supported manual procedure.
What exists today #
- Raft metadata snapshots. The catalog’s Raft log is periodically
snapshotted (
node.snapshot_per_events), so cluster metadata (namespaces, collections, schemas, shard routing) has its own durability story independent of the data plane. - The trash. Deleting a namespace or a collection (or replacing
shards) only touches metadata: the data directories are moved into
<data_path>/trash/and physically deleted by a background sweeper only aftertrash.retention_secs(default 1 day) elapses. A deleted namespace is captured as ONE item with a restore snapshot per collection, so the whole namespace — all collections, original shard placements included — can be brought back via the Trash APIs. Every restore is preceded by a read-only shard-completeness verification, and a restore whose data is provably incomplete is refused rather than silently coming back empty. This gives a grace window against accidental deletes, not a backup.
Manual backup #
A shard’s durable state is its built FIRE segments plus its WAL tail — both live under the node’s data directory. To take a consistent copy of a single-node deployment:
...