Restore 时修改索引名称

做的事：本机真实给rn_test建一份快照，故意不删掉原索引，用rename_pattern和rename_replacement尝试把恢复目标改名成restored_test

代码真实写入数据到rn_test并建快照rn_snap(原索引保持存在) POST /_snapshot/my_fs_repo/rn_snap/_restore?wait_for_completion=true { "indices": "rn_test", "rename_pattern": "rn_(.+)", "rename_replacement": "restored_$1" }

验证：真实两边都活着——原来的rn_test完全没被动过，restored_test凭空多出来了一份一模一样的数据，连_id都没变

restore响应: {"total":1,"failed":0,"successful":1}

GET /rn_test/_count → count:1   ← 真实原索引完全没被动过
GET /restored_test/_search → _index:"restored_test", _id:"2lm--aABhkoFfq48ze94",
  {"n":1,"text":"rename test data"}   ← 真实凭空多出一份同样的数据

这个真实结果说明rename_pattern/rename_replacement这对参数真实解决的正是本系列上一篇反复遇到的那个"索引同名冲突"问题：只要恢复的目标名字真实跟现有索引不一样，restore就真实不需要原索引让路，两者可以真实并存。这对于想在不影响线上现有索引的前提下，从某个历史快照里真实拉一份数据出来做核对、调试或者数据恢复验证的场景特别有用。

真实再执行一次同样的改名恢复，看这次会不会成功——因为restored_test这个目标名字现在已经真实存在了

代码POST /_snapshot/my_fs_repo/rn_snap/_restore?wait_for_completion=true { "indices": "rn_test", "rename_pattern": "rn_(.+)", "rename_replacement": "restored_$1" }

验证：真实直接被拒绝，报错原文点名的是restored_test这个改名之后的目标名字，不是快照里记录的原始索引名rn_test

→ 500 snapshot_restore_exception:
  "cannot restore index [restored_test] because an open index with same
   name already exists in the cluster. ..."

收尾：真实清理快照和两个索引

代码DELETE /_snapshot/my_fs_repo/rn_snap DELETE /rn_test,restored_test

分步演示：从原索引保持存在时改名恢复的真实并存，到目标新名字也被占用时同样会被真实拒绝

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。