Snapshot Restore

做的事：本机真实往一个索引写2条数据并建一份快照，再在索引还存在的情况下直接尝试restore，看会发生什么

代码真实写入2条文档到restore_test，建快照 restore_snap POST /_snapshot/my_fs_repo/restore_snap/_restore?wait_for_completion=true {"indices":"restore_test"}

验证：真实被直接拒绝，报错原文明确提示要么删掉现有索引、要么用改名方式恢复——restore真实不会悄悄覆盖一个还活着的索引

→ 500 snapshot_restore_exception:
  "cannot restore index [restore_test] 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"

这个真实报错说明restore这个动作真实自带一道保护：只要集群里已经存在一个同名的、处于打开状态的索引，restore就会真实直接拒绝执行，不会不由分说地把现有数据覆盖掉——报错原文真实已经给出了两条明确的出路，关闭或删除现有索引，或者改名恢复（本系列后面会专门验证改名恢复这条路）。

真实把索引彻底删掉，模拟一次真正的数据丢失，确认查不到任何数据之后再真实执行restore

代码DELETE /restore_test GET /restore_test/_count # 真实确认数据已经不存在 POST /_snapshot/my_fs_repo/restore_snap/_restore?wait_for_completion=true {"indices":"restore_test"}

验证：删除后真实查不到任何数据，确认是真实的数据丢失；restore真实成功，恢复完查到的文档数精确对上2条，连_id都跟删除前完全一致

删除后查询: → 404 index_not_found_exception   ← 真实确认数据已经不在了

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

恢复完查询:
→ count: 2   ← 真实精确对上
→ 文档1: _id="z1m6-aABhkoFfq48Su98", {"n":1,"text":"original data"}
→ 文档2: _id="0Fm6-aABhkoFfq48Su-g", {"n":2,"text":"more original data"}
（跟删除之前真实完全一致，_id也没有变成新生成的）

收尾：真实清理快照和测试索引，确认集群恢复到正常状态

代码DELETE /_snapshot/my_fs_repo/restore_snap DELETE /restore_test

分步演示：从索引存在时restore被真实拒绝，到真正数据丢失后恢复出连_id都精确一致的原始数据

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