Restore Full/Partial Indices, Rename-on-Restore, Global State/Security Considerations, and Conflict Handling

Learning outcomes

AtlasMart has a good snapshot, but disaster recovery still fails if restore is executed carelessly. Restoring over a live index can collide with existing names; restoring cluster state can change templates, pipelines or security behavior; restoring a product index without the template needed by its data stream can fail; and a snapshot accepted by the storage layer can still be incompatible with the target product/version. This lesson treats restore as a controlled migration into an isolated namespace first.

1. Full, selective and rename-on-restore are different recovery choices

Rename-on-restore is the safest teaching path because it avoids deleting the live AtlasMart index merely to prove that a backup works. It also creates a clean comparison surface for counts, mappings and query fixtures.

2. Create a second snapshot with a known recovery boundary

After snapshot 001, update one product and add one new document, then take snapshot 002. Record the operation timestamps. This makes RPO evidence concrete: restoring 001 must not magically contain post-001 changes; restoring 002 should.

PUT atlasmart-dr-products-v1/_doc/P-1001?refresh=wait_for
{
  "sku":"AM-AU-100",
  "name":"Wireless Noise Cancelling Headphones",
  "category":"audio",
  "price":189.99,
  "updated_at":"2026-09-11T09:00:00Z"
}

PUT atlasmart-dr-products-v1/_doc/P-1006?refresh=wait_for
{
  "sku":"AM-KB-610",
  "name":"Mechanical Keyboard",
  "category":"office",
  "price":109.00,
  "updated_at":"2026-09-11T09:01:00Z"
}

# Elasticsearch example; on OpenSearch use atlasmart-os-fs
PUT _snapshot/atlasmart-es-fs/atlasmart-dr-2026.09.11-002?wait_for_completion=true
{
  "indices":"atlasmart-dr-products-v1",
  "include_global_state":false
}

3. Deliberately trigger a name conflict

POST _snapshot/atlasmart-es-fs/atlasmart-dr-2026.09.11-002/_restore
{
  "indices":"atlasmart-dr-products-v1",
  "include_global_state":false
}

Expected result: restore is rejected because an open index with the same name already exists. The error is useful evidence: the product is refusing an ambiguous overwrite. Do not “fix” this by deleting the source index before validation.

POST _snapshot/atlasmart-es-fs/atlasmart-dr-2026.09.11-002/_restore?wait_for_completion=true
{
  "indices":"atlasmart-dr-products-v1",
  "include_global_state":false,
  "include_aliases":false,
  "rename_pattern":"atlasmart-dr-products-v1",
  "rename_replacement":"atlasmart-dr-products-restored-002"
}

Elasticsearch and OpenSearch both support rename-on-restore patterns, but response details and security checks can differ. The restored index is intentionally disconnected from production aliases until validation passes.

4. Validate data, mapping and behavior before cutover

GET atlasmart-dr-products-v1/_count
GET atlasmart-dr-products-restored-002/_count

GET atlasmart-dr-products-v1/_mapping
GET atlasmart-dr-products-restored-002/_mapping

GET atlasmart-dr-products-restored-002/_doc/P-1001
GET atlasmart-dr-products-restored-002/_doc/P-1006

GET atlasmart-dr-products-restored-002/_search
{
  "size": 0,
  "aggs": {
    "by_category": {"terms": {"field":"category","size":10}},
    "price_sum": {"sum": {"field":"price"}}
  }
}

For larger datasets, counts alone are weak evidence. Add deterministic sampled IDs, category/value aggregates, application queries, mapping/settings diffs and—if the source system has a canonical event log—reconciliation against that source. A “same document count” can hide different documents.

5. Global state and security are privileged recovery domains

Elasticsearch snapshots can include cluster state such as persistent settings, templates, ingest pipelines, ILM policies and feature states. Current Elasticsearch uses feature states to back up system indices for features such as Security and Kibana. Restoring those artifacts can change authentication/authorization and application behavior, so review them independently.

GET _features

# Application-data-only snapshot/restore path remains:
{
  "include_global_state": false
}

OpenSearch Security adds different restrictions. With the Security plugin, ordinary snapshot restore should exclude global state and the security system index; restoring security configuration has additional admin-certificate requirements and deserves its own security runbook. Do not model this as “same as Elastic security feature state with different names.”

6. Templates, data streams and aliases are dependencies

A restored ordinary index carries its own mapping/settings, but application routing may depend on aliases, and a restored data stream requires compatible data-stream metadata/template state. Elasticsearch documents that a matching data-stream-enabled index template must exist when restoring a data stream unless appropriate cluster state is restored. OpenSearch 3.8 additionally has an experimental option to attach a restored backing index to an existing data stream; treat that as version-specific and not a portable general rule.

7. Version compatibility is product-specific

Elasticsearch documents snapshot-version and index-creation-version compatibility, including special archive/searchable-snapshot paths for some older indices. OpenSearch documents its own forward-compatibility guidance and migration constraints. A snapshot accepted by one product is not an interchange format for the other. If AtlasMart moves Elasticsearch → OpenSearch or OpenSearch → Elasticsearch, treat it as a migration project: supported APIs, reindex/export, schema/analyzer review, security redesign and workload validation.

source_product: Elasticsearch | OpenSearch
source_version: x.y.z
snapshot_repository_type: fs | s3 | ...
snapshot_name: ...
index_creation_versions: ...
target_product: Elasticsearch | OpenSearch
target_version: x.y.z
plugins/features_required: ...
compatibility_reference: official docs checked YYYY-MM-DD
restore_test_result: PASS | FAIL

8. Cleanup and rollback

DELETE atlasmart-dr-products-restored-002

# Never delete snapshot repository files manually.
# Use snapshot APIs when a recovery point is intentionally retired.
DELETE _snapshot/atlasmart-es-fs/atlasmart-dr-2026.09.11-001

Snapshot deletion is safe only through the product API because repositories share segment blobs. In production, destructive snapshot deletion must also respect legal holds, immutable storage policy, retention ownership and cross-region copy state.

References

• Elastic snapshot and restore — Snapshot contents, incremental segment reuse, compatibility, and deployment-specific behavior.
• Elastic create/monitor snapshots and SLM — SLM schedules, retention, snapshot status, feature-state backup, and operational monitoring.
• Elastic restore a snapshot — Restore prerequisites, rename-on-restore, capacity, compatibility, and cross-cluster cautions.
• Elastic searchable snapshots — Enterprise-licensed searchable-snapshot behavior and repository dependency.
• OpenSearch snapshot and restore — Incremental snapshots, repository types, restore compatibility, and security constraints.
• OpenSearch Snapshot Management — Scheduled snapshot creation/deletion, failure metadata, plugin and security requirements.
• OpenSearch Snapshot Management API — SM policy schema, explain state, start/stop, schedules, retention and OCC updates.
• OpenSearch remote-backed storage — Remote segment/translog storage and remote-store recovery concepts.
• OpenSearch release artifacts — Pinned OpenSearch release baseline.
• Elasticsearch downloads — Pinned Elasticsearch release baseline.