Elasticsearch 9.2.1 snapshot visible in repository but restore fails with snapshot_missing_exception

I have an Elasticsearch 9.2.1 cluster configured with Snapshot Lifecycle Management (SLM) that takes nightly snapshots to an S3 repository. The snapshots are successfully created, and I can see all snapshot metadata in the S3 bucket.

I created a new Elasticsearch 9.2.1 cluster and registered a repository pointing to the same S3 bucket. The repository registration succeeds, and I can see the snapshots:

GET _snapshot/nightly-snapshots-003/_all

I can also retrieve information about an individual snapshot:

GET _snapshot/nightly-snapshots-003/snapshot-2026-06-11-00-00-00-utc

However, when I try to restore the snapshot:

POST /_snapshot/nightly-snapshots-003/snapshot-2026-06-11-00-00-00-utc/_restore?pretty

I get :

"error": {"root_cause": [{"type": "snapshot_missing_exception","reason": "[nightly-snapshots-003:snapshot-2026-06-11-00-00-00-utc] is missing"}],"type": "snapshot_missing_exception","reason": "[nightly-snapshots-003:snapshot-2026-06-11-00-00-00-utc] is missing","caused_by": {"type": "no_such_file_exception","reason": "Blob object [] not found: The specified key does not exist. (Service: S3, Status Code: 404)"}},"status": 404}

see the same behavior with multiple snapshots.

The confusing part is that:

  • The snapshot appears in the repository.
  • GET _snapshot/<repo>/<snapshot> works.
  • Only the restore operation fails because Elasticsearch tries to read metadata files that it says do not exist in S3.

Has anyone seen a situation where snapshot metadata is visible but restore fails due to missing blob files? Are there additional repository verification or consistency checks I should run?

Welcome!

This looks like a bug indeed. I guess that just after the POST request, if you try again the GET _snapshot/nightly-snapshots-003/snapshot-2026-06-11-00-00-00-utc, it works, right?

Is that happening only with this snapshot? Or if you try an older snapshot it fails the same way?

Do you see any details in logs, like a stacktrace?