Verify a trash item #

Run a read-only shard-completeness check on a trash item, across every node that still holds its data. Nothing is moved or written — this is the preflight for a restore.

Examples #

POST /_cluster/trash/1788916375_namespace-website/verify

With ?deep=true, every present segment file additionally has its footer parsed — truncated or corrupted files are reported by name. Deep mode can take noticeably longer on large items.

{
  "item": "1788916375_namespace-website",
  "deep": false,
  "kind": "namespace",
  "namespace": "website",
  "restorable": true,
  "degraded": false,
  "shard_groups": [
    {
      "collection": "website:logs",
      "shard": "a1b2…",
      "expected_copies": 2,
      "complete_copies": 2,
      "copies": [
        { "node": "…", "node_name": "pizza-1", "primary": true, "complete": true },
        { "node": "…", "node_name": "pizza-2", "primary": false, "complete": true }
      ]
    }
  ],
  "issues": [],
  "unreachable_nodes": []
}

Request #

POST /_cluster/trash/<item>/verify[?deep=true]

Path parameters #

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

Response #

• restorable — true when every shard group with recorded data has at least one complete copy on some node. A shard group counts a copy as complete when its allocation directory AND its segment manifest with all declared local files are present (and, in deep mode, every file’s footer parses).
• degraded — true when the item is restorable but some recorded copies are missing; the restore comes back with fewer replicas, which the allocator backfills.
• issues — human-readable problem lines (missing directories, missing/corrupt segment files, unreachable nodes), each prefixed with the node it applies to.