Restore a trash item #

Restore a trashed collection — or a whole deleted namespace — back into the cluster, cluster-coordinated: every holder node moves its copy of the data back, the metadata is re-registered through Raft with the ORIGINAL collection/rolling/shard UUIDs, and the recorded shard placements are replayed so every engine re-opens its original working directory with all documents.

Examples #

Restore a deleted namespace under a new name (every collection comes back inside it):

POST /_cluster/trash/1788916375_namespace-website/restore
{
  "new_name": "website_recovered"
}

Restore a deleted collection into an existing namespace:

POST /_cluster/trash/1788916220_collection-website-logs/restore
{
  "namespace": "website",
  "new_name": "logs_recovered"
}

Request #

POST /_cluster/trash/<item>/restore

Path parameters #

• <item>
  (Required, string) The trash item name, as listed by List the cluster trash.

Body #

• new_name
  (Required for collection items, optional for namespace items, string) A-Za-z0-9_-. A namespace item without new_name restores under its original name.
• namespace
  (Optional, collection items only, string) Target namespace; defaults to the collection’s original namespace. Note that restoring into a different namespace re-registers metadata only — the data directories stay keyed by the original namespace, so shards come back empty.
• force
  (Optional, boolean, default false) Bypass the verification gate.

Verification gate #

Before any data moves, the restore runs the light verification across the cluster. If some shard group has recorded data but no complete copy anywhere, the restore is refused with 409 Conflict and the full verification report attached — restoring anyway would silently bring those shards back empty. Pass "force": true to proceed regardless; the affected shards then come back empty and are backfilled by the allocator.

Name conflicts answer 409; a malformed snapshot answers 422.