无法从S3存储桶恢复Elasticsearch索引快照求助

结合你描述的环境（Elasticsearch 6.2.4 + Search Guard 6.2.4-12 + S3仓库插件）和遇到的问题，咱们一步步拆解可能的原因和解决办法：

1. 先确认快照本身是否包含目标索引 #

你返回的恢复结果显示indices:[]，大概率是快照里根本没包含要恢复的索引。先执行以下命令查看快照的详细信息：

curl -uUSERNAME:PASSWORD -X GET "localhost:9200/_snapshot/你的S3仓库名/filebeat-2018-04-10-snapshot"

如果返回的indices字段是空数组，说明快照创建时就没捕获到目标索引，问题出在快照生成环节：

• 检查创建快照的命令是否明确指定了要快照的索引。比如正确的快照命令应该包含indices参数：

  curl -uUSERNAME:PASSWORD -X PUT "localhost:9200/_snapshot/你的S3仓库名/filebeat-2018-04-10-snapshot" -H 'Content-Type: application/json' -d'{
    "indices": "filebeat-2018.04.10",
    "ignore_unavailable": true,
    "include_global_state": false
  }'
  

  如果你没加indices参数，默认会快照所有打开状态的索引，如果当时目标索引已经被关闭或者不存在，就会生成空快照。
• 确认快照创建时，目标索引filebeat-2018.04.10是存在且处于打开状态的。

2. 检查恢复命令的参数是否正确 #

如果快照里确实包含目标索引，但恢复后没生成索引，要检查恢复命令的配置：

• 确保恢复命令明确指定了要恢复的索引，避免因为默认规则遗漏：

  curl -uUSERNAME:PASSWORD -X POST "localhost:9200/_snapshot/你的S3仓库名/filebeat-2018-04-10-snapshot/_restore" -H 'Content-Type: application/json' -d'{
    "indices": "filebeat-2018.04.10",
    "ignore_unavailable": true,
    "include_global_state": false
  }'
  

• 如果你用了rename_pattern或rename_replacement来重命名索引，要确认正则匹配是否正确，避免生成了你没注意到的索引名。

3. 排查Search Guard的权限细节 #

虽然你设置了searchguard.enable_snapshot_restore_privilege: true，但仍要确保执行恢复的用户拥有足够权限：

• 检查用户是否拥有indices:admin/snapshot/restore权限，以及创建目标索引的权限。执行以下命令查看用户权限：

  curl -uUSERNAME:PASSWORD -X GET "localhost:9200/_security/user/USERNAME/_privileges"
  

  如果权限不足，需要在Search Guard的角色配置中添加对应权限。

4. 验证S3仓库的可用性 #

确保集群能正常访问S3仓库读取快照文件：

curl -uUSERNAME:PASSWORD -X GET "localhost:9200/_snapshot/你的S3仓库名/_verify"

如果返回失败，说明仓库配置有问题（比如AWS密钥错误、存储桶权限不足），需要重新检查S3仓库的配置参数。

5. 查看Elasticsearch日志获取细节 #

以上排查都没问题的话，直接看ES的日志文件（通常在config/logs目录下），恢复操作的详细错误信息都会在这里记录，比如快照文件损坏、索引设置不兼容（比如当前集群节点数不足以分配副本）等。

内容的提问来源于stack exchange，提问作者YATIN GUPTA