https://pizza.rs/tags/backup/Recent content in Backup on INFINI PizzaHugoenhttps://pizza.rs/docs/administration/backup/Mon, 01 Jan 0001 00:00:00 +0000https://pizza.rs/docs/administration/backup/<h1 id="backup-and-restore"> Backup and restore <a class="anchor" href="#backup-and-restore">#</a> </h1> <p>Pizza does not have a first-class backup/restore HTTP API yet — this page describes what exists today and the supported manual procedure.</p> <h2 id="what-exists-today"> What exists today <a class="anchor" href="#what-exists-today">#</a> </h2> <ul> <li><strong>Raft metadata snapshots.</strong> The catalog&rsquo;s Raft log is periodically snapshotted (<code>node.snapshot_per_events</code>), so cluster metadata (namespaces, collections, schemas, shard routing) has its own durability story independent of the data plane.</li> <li><strong>The trash.</strong> Deleting a namespace or a collection (or replacing shards) only touches metadata: the data directories are moved into <code>&lt;data_path&gt;/trash/</code> and physically deleted by a background sweeper only after <code>trash.retention_secs</code> (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 <a href="https://pizza.rs/docs/references/trash/">Trash APIs</a>. 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.</li> </ul> <h2 id="manual-backup"> Manual backup <a class="anchor" href="#manual-backup">#</a> </h2> <p>A shard&rsquo;s durable state is its built FIRE segments plus its WAL tail — both live under the node&rsquo;s data directory. To take a consistent copy of a single-node deployment:</p>