Elasticsearch 8 to 9 Snapshot Restore Fails? The 7.x-Origin Index Trap and the Fix That Worked

Elasticsearch 8 to 9 Snapshot Restore Fails? The 7.x-Origin Index Trap and the Fix That Worked

Problem Description

cannot restore index [my-index] because it cannot be upgraded

Root Cause Analysis

Elasticsearch 9.x can read indices created in 8.x and, by design, also indices created in 7.x that have been prepared correctly.
If a snapshot contains indices created in an older, incompatible major version, for example 6.x when upgrading to 8.x or 9.x, those indices cannot be opened on the newer cluster at all and must be reindexed on a compatible cluster or left on an older deployment.

PUT /my-index/_block/write

Had a 7.x-created index running on 8.7.1.
Manually set index.blocks.write: true via index settings.
Took a snapshot and tried to restore it on 9.0.1, which failed with a compatibility error.
Then removed the manual index.blocks settings, applied PUT /my-index/_block/write on 8.7.1, created a new snapshot, and was able to restore that snapshot successfully into 9.0.1.

A note on the “index already exists” error

cannot restore index [my-index] because an open index with same name already exists in the cluster. Either close or delete the existing index or restore the index under a different name by providing a rename pattern and replacement name

Solution

Being on a supported 8.x version when taking the snapshot, ideally the latest minor of the previous major before going to 9.x.
Using the dedicated add index block API to set index.blocks.write correctly before snapshotting when you need to mark 7.x-origin indices as read-only.

Step 1: Upgrade the source cluster to a suitable 8.x

Step 2: Clean up old index block settings (if necessary)

Step 3: Add a write block using the dedicated API

PUT /my-index/_block/write

{
  "acknowledged": true,
  "shards_acknowledged": true,
  "indices": [
    {
      "name": "my-index",
      "blocked": true
    }
  ]
}

Sets index.blocks.write for the index.
Ensures all shards have finished in-flight writes and are correctly accounting for the block.
Produces the state that 9.x has been shown to handle more reliably when accepting older (for example 7.x-created) indices from a snapshot in this particular reported case.

Step 4: Create a new snapshot on 8.x

PUT /_snapshot/my_repository/my_migration_snapshot
{
  "indices": "my-index",
  "ignore_unavailable": false,
  "include_global_state": false
}

Step 5: Restore the snapshot into 9.0.1

POST /_snapshot/my_repository/my_migration_snapshot/_restore
{
  "indices": "my-index",
  "ignore_unavailable": true,
  "include_global_state": false
}

Alternative Approach: Reindexing

Configure the 9.x cluster to treat the 8.x cluster as a remote cluster.
Use POST /_reindex with a remote source to pull data from the old cluster into new indices created natively on 9.x.
Optionally, adjust mappings, analyzers, or templates as you go, and then switch clients over to the new indices when ready.

You need full control over the new index layout.
Some indices in your old snapshots are fundamentally incompatible, for example created in 6.x or earlier and not readable by 9.x.
You prefer an incremental migration with the ability to validate and backfill data gradually.

Takeaways