Elasticsearch / Advanced: resilient and recoverable retrieval / Lesson 16

Snapshots, repositories and restore proof

Protect historical search state through supported snapshots and verify recovery beyond a successful job status.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain snapshot scope, repository integrity and version compatibility.
Define an isolated restore rehearsal with application checks.

Replication does not preserve every past state

Replica shards improve availability but also reflect accidental deletions and incorrect updates. Supported snapshots preserve recoverable index state in an off-cluster repository. A filesystem copy of Elasticsearch data directories is not a supported substitute for the snapshot mechanism, even if files appear complete. Define recovery point and recovery time objectives for the catalog and visit events separately. A derived catalog may be rebuildable from an authoritative source, while unique event history needs its own protected retention. Record which path is primary for each data class and how its completeness will be demonstrated.

Choose data and cluster-state scope explicitly

The illustrative snapshot body selects a synthetic index pattern and excludes global state. This is deliberately a partial scope: templates, pipelines, policies and security feature state may require separate inclusion decisions or configuration recovery. In 8.x, feature states are the supported path for backing up and restoring system indices and system data streams. A data-only snapshot should not be advertised as complete deployment recovery. Snapshotting an index also involves its aliases under documented behavior, so restore planning must review whether aliases are brought into the target environment. No repository or snapshot is created here.

json Illustrative technical example; logical results are reasoned, not engine-tested.

{"indices":"museum-artifacts-*","include_global_state":false,"metadata":{"purpose":"synthetic catalog recovery review"}}

Illustrative snapshot request body for an already approved repository. It does not protect omitted cluster configuration or prove any actual snapshot exists.

A snapshot has a time interval and shared segments

Snapshots copy immutable segments and can deduplicate shared data. Each logical snapshot can depend on repository files also referenced by other snapshots, so do not manipulate repository objects manually or delete apparently old segment files. Use supported repository operations under an approved retention policy. A snapshot is not one exact global instant across every shard; each shard’s view falls within the snapshot start and end interval. If business reconciliation requires a stronger coordinated source point, define that protocol separately. Successful backup metadata does not eliminate the need to verify readable storage and restore compatibility.

Recovery cannot assume a downgrade path

Snapshot version, destination cluster version and index creation version all influence compatibility. A snapshot cannot generally be restored into an earlier Elasticsearch version, and old index formats can need a documented intermediate strategy. A cluster upgraded in place cannot be rolled back merely by starting older binaries against its changed data directory. Keep a tested pre-change snapshot and a compatible independent recovery target. Cloud Hosted and Serverless expose different backup and restore responsibilities, so verify the service-specific workflow rather than treating a self-managed repository example as portable administration.

Prove the application can use the restored data

The local checklist describes evidence categories for a recovery rehearsal, not a completed recovery. An isolated test should verify selected index identities, mappings, aliases, representative document keys, counts and judged searches. Confirm that runtime credentials and required pipeline or template configuration are available through approved recovery paths. Measure recovery duration and explain omitted external dependencies. Never restore over an existing production index as a casual tutorial exercise. This course performs no storage access, repository verification, snapshot creation or restore; all request fragments remain non-runnable and expected checks are editorial requirements.

json Illustrative technical example; logical results are reasoned, not engine-tested.

{"scope":"synthetic isolated recovery checklist","verify":["index identities","mappings and aliases","representative document keys","source count reconciliation","runtime search permissions","judged query results"],"timing":"measure during an authorized rehearsal"}

A local planning manifest, not Elasticsearch API input or proof that recovery was executed.

Common errors and fixes

snapshot_missing_exception

Why it happens: The named snapshot is absent from the selected repository context.
How to fix it: Verify the approved repository, snapshot identity and retention evidence.
Prevent it next time: Keep a recoverable inventory with scope and creation version.

Repository files are deleted outside Elasticsearch

Why it happens: Shared snapshot segments were mistaken for independent disposable files.
How to fix it: Stop unsupported manipulation and follow the owner’s repository recovery procedure.
Prevent it next time: Use supported snapshot retention rather than object-level cleanup.

A data snapshot cannot rebuild application configuration

Why it happens: The selected scope omitted required state and external configuration.
How to fix it: Inventory and protect the missing dependencies explicitly.
Prevent it next time: Test full service recovery separately from snapshot job success.

Check your understanding

1. Why is deleting an old-looking segment object from a repository unsafe?

Show worked solution

Multiple logical snapshots can reference shared immutable segments. Manual deletion can corrupt recoverability beyond the one snapshot the operator intended to remove. Use supported snapshot deletion and retention, and validate the resulting recoverable inventory through the approved workflow.

2. Does a successful snapshot with include_global_state:false prove full deployment recovery?