7.7.1旧版Kibana配置自动快照备份至GCP存储的最佳方案咨询

Kibana本身是Elasticsearch的前端可视化组件，核心数据存储在底层ES集群中，备份链路分为两部分：一是覆盖ES全量索引、集群状态的快照备份，二是Kibana节点本地配置文件的独立备份，全程不需要额外部署复杂工具，适配当前无自动化备份的现状。

第一步：完成GCP存储的快照仓库注册 #

Kibana的快照能力完全依赖底层ES的快照模块，7.7.x版本需要先完成基础配置才能对接GCP存储：

• 在所有ES节点（含主节点、数据节点）安装对应版本的GCS仓库插件，执行命令：elasticsearch-plugin install repository-gcs，安装完成后重启全量ES节点让插件生效。
• 在GCP侧提前创建用于存放备份的存储桶，给ES节点配置具备该存储桶读写权限的服务账号：如果是GCP虚拟机部署的ES，直接给实例绑定带存储权限的服务账号即可；如果是自建ES节点，将服务账号的JSON凭证文件放到每个ES节点的config/gcs/目录下，并在elasticsearch.yml中添加配置指定凭证路径：gcs.client.default.credentials_file: /opt/elasticsearch/config/gcs/service-account.json，改完配置重启节点。
• 注册可被ES识别的快照仓库，可以直接在Kibana左侧菜单的「Management > Snapshot and Restore > Repositories」中选择GCS类型，按引导填写存储桶名称、快照存储路径完成配置；也可以通过Dev Tools执行接口完成注册：

PUT /_snapshot/es_gcs_backup
{
  "type": "gcs",
  "settings": {
    "bucket": "你的GCP存储桶名称",
    "base_path": "es-snapshots",
    "compress": true
  }
}

第二步：配置无额外依赖的自动化快照能力 #

优先选择ES原生的*快照生命周期管理（SLM）*实现自动化，这个功能在7.4版本就已经GA，完全兼容7.7.1的版本，不需要额外部署调度工具，和Kibana的监控面板打通，状态可视化好。

• 在Dev Tools中配置自动快照策略，实现每6小时打一次快照、自动保留最近30天备份的逻辑：

PUT /_slm/policy/auto_gcs_snapshot
{
  "schedule": "0 0 */6 * * ?",
  "name": "es-snap-{{now {YYYY.MM.dd-HH.mm}}}",
  "repository": "es_gcs_backup",
  "config": {
    "indices": "*",
    "include_global_state": true
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 10
  }
}

• 手动触发一次策略验证连通性，执行命令：POST /_slm/policy/auto_gcs_snapshot/_execute，确认快照文件成功写入GCP存储桶后，策略就会按设定的周期自动运行，自动完成旧快照的清理，不需要人工干预。
• 如果无法使用SLM功能（比如集群定制化限制），可以写简单的shell脚本通过curl调用ES快照接口，把脚本配置到节点的cron计划任务中按周期执行，这种方式需要自己实现快照执行状态判断、旧快照清理逻辑，维护成本更高，不做优先推荐。

第三步：补充Kibana本地配置的备份 #

ES的全量快照只会存ES集群里的.kibana索引（也就是Kibana里的仪表盘、索引模式、告警规则等对象），不会备份Kibana节点本地磁盘上的配置文件，需要把这部分内容同步到同一个GCP存储桶：

• 把Kibana安装目录下的config文件夹（包含kibana.yml配置、自定义插件配置、加密密钥文件）按和快照相同的周期同步到GCP存储的独立路径下。
• 如果需要粒度更细的对象备份，可以通过Kibana的「Management > Saved Objects」页面导出全量保存对象为NDJSON文件，同样存到GCP存储中，方便后续单独恢复部分业务配置。

7.7.1版本实操注意事项 #

• 配置SLM策略时不要使用7.7版本不支持的高版本参数（比如快照加密、增量快照相关配置），避免策略加载失败，所有参数严格对照7.7版本的功能范围填写。
• 给ES节点的GCP服务账号只开放目标存储桶的读写权限，不要授予项目级别的全量存储权限，避免权限风险。
• 第一次全量快照会上传全量索引文件，占用集群出口带宽，建议在业务低峰期执行第一次快照，避免影响正常业务访问。
• 每季度至少做一次快照恢复演练，验证存到GCP的快照文件可以正常恢复，避免出现备份损坏但未察觉的问题。

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