OpenSearch 的索引快照别只留本地：用 repository-s3 存进 RustFS

OpenSearch 跑起来，索引分片默认写在节点自己的本地盘上。单机测试很顺，可一旦索引量上来、节点不止一个，本地盘的故障就成了绕不开的坎：一块盘坏了，上面的分片副本丢了，重建全靠其他副本兜着，集群压力瞬间翻倍。更隐蔽的是快照，很多人把快照也留在本地盘的默认仓库里，等于把备份和原始数据放在了同一块会坏的盘上。OpenSearch 自带 repository-s3 插件，能把索引快照直接写进任意 S3 兼容的对象存储。用 RustFS 当那个 S3 后端，快照统一收进一个桶，节点挂了也能从桶里把索引拉回来。

快照在桶里长什么样

OpenSearch（开源项目）是从 Elasticsearch 分叉出来的开源搜索与分析套件。它的 repository-s3 插件把快照写成分片归档和元数据 blob，存进桶里。仓库注册是集群级配置，每个节点都要装这个插件、且持有相同的客户端配置，所以这不是单机的事，是整集群都得对齐的一份设置。RustFS 在这一步就是那个 S3 端点，分片归档和元数据都进同一个桶。

官方集成指南用 opensearchproject/opensearch:3.8.0、配合镜像自带的 repository-s3 插件，对 rustfs/rustfs-x86-musl:v2.3.1 验证通过。下面按单节点最小拓扑走一遍，重点放在 S3 客户端配置和仓库注册，不重复从零装 OpenSearch。

桶里那份快照不是一整块，而是分片归档加元数据 blob 的组合：每个分片的数据写成一组归档对象，再加上 index-0、index.latest、meta-*.dat、snap-*.dat 这几类元数据文件描述快照的构成和版本。恢复时 OpenSearch 先读元数据定位分片归档，再把它们拉回本地重建成索引，所以元数据文件丢了，光有分片归档也拼不出完整快照。这也是为什么仓库注册是集群级配置、每个节点都得装插件且持有相同客户端设置：任何一台要参与打快照或还原的节点，都得能独立连上同一个 RustFS 桶读同一套元数据。

先起节点，再装插件

以关掉安全插件、小堆内存的方式起一个单节点，等它起来：

bash 复制代码

docker run -d --name opensearch --network oo-rustfs_default -p 9200:9200 \
  -e discovery.type=single-node \
  -e OPENSEARCH_JAVA_OPTS="-Xms512m -Xmx512m" \
  -e DISABLE_SECURITY_PLUGIN=true \
  opensearchproject/opensearch:3.8.0

curl http://localhost:9200 返回集群信息（通常要等一两分钟）就说明节点就绪。镜像没有预装 S3 仓库插件，装完要重启节点让插件生效：

bash 复制代码

docker exec opensearch bin/opensearch-plugin install --batch repository-s3
docker restart opensearch

凭证进 keystore，配置进 yml

S3 的凭证属于安全设置，必须放进 OpenSearch 的 keystore，不能写在仓库请求里，也不能写进 opensearch.yml：

bash 复制代码

docker exec opensearch sh -c \
  "printf '<your-access-key>' | bin/opensearch-keystore create 2>/dev/null; \
   printf '<your-access-key>' | bin/opensearch-keystore add -f -x s3.client.default.access_key; \
   printf '<your-secret-key>' | bin/opensearch-keystore add -f -x s3.client.default.secret_key"

非敏感的客户端设置才写进 config/opensearch.yml：

yaml 复制代码

network.host: 0.0.0.0
plugins.security.disabled: true
s3.client.default.endpoint: http://<your-rustfs-endpoint>:9000
s3.client.default.protocol: http
s3.client.default.path_style_access: "true"

s3.client.default.path_style_access: "true" 这一行决定走路径风格（path-style）请求，对 RustFS 是必须的，因为 RustFS 不走虚拟主机风格的桶寻址。改完重启节点让 keystore 和新配置都生效，趁节点启动时把桶建好：

bash 复制代码

docker restart opensearch
rc mb rustfs/opensearch-snapshots

注册仓库，打一份快照

先建个测试索引、塞一条文档，再注册仓库：

bash 复制代码

curl -sX PUT http://localhost:9200/rustfs-demo -H "Content-Type: application/json" \
  -d '{"settings":{"number_of_shards":1}}'

curl -sX PUT http://localhost:9200/rustfs-demo/_doc/1 -H "Content-Type: application/json" \
  -d '{"product":"rustfs","via":"opensearch-snapshot"}'

curl -sX PUT "http://localhost:9200/_snapshot/rustfs-repo" -H "Content-Type: application/json" \
  -d '{"type":"s3","settings":{"bucket":"opensearch-snapshots","region":"us-east-1","server_side_encryption_type":"bucket_default"}}'

server_side_encryption_type: bucket_default 这一项很关键：不设置时，插件会去请求 SSE-S3 加密，而自托管、又没配服务端加密主密钥的 RustFS 会直接拒绝它。打快照并等它完成：

bash 复制代码

curl -sX PUT "http://localhost:9200/_snapshot/rustfs-repo/snapshot-1?wait_for_completion=true" \
  -H "Content-Type: application/json" -d '{"indices":"rustfs-demo"}'

返回里 state 是 SUCCESS 就说明快照落桶成功了。列一下桶内对象，能看到 index-0、index.latest、indices/.../0/...、meta-...dat、snap-...dat 这些文件，正是分片归档和快照元数据。

删了索引，从桶里还原

验证链路最直接的方式是删掉索引再从快照拉回来：

bash 复制代码

curl -sX DELETE http://localhost:9200/rustfs-demo
curl -sX POST "http://localhost:9200/_snapshot/rustfs-repo/snapshot-1/_restore?wait_for_completion=true"
curl -s http://localhost:9200/rustfs-demo/_doc/1

最后一条返回 found: true、且 _source 里还是 {"product":"rustfs","via":"opensearch-snapshot"}，说明索引从 RustFS 桶里完整还原了。快照在、桶在，索引丢了也能拉得回来，这才是备份该有的样子。

几个会卡住的配置点

Setting [access_key] is insecure, but property [allow_insecure_settings] is not set ：仓库请求里写内联凭证会被拒绝。按上面的步骤把凭证存进 keystore，在 OpenSearch 里 access_key 和 secret_key 是安全设置。
SSE-S3 requires RUSTFS_SSE_S3_MASTER_KEY ... (Status Code: 400) ：插件默认用 SSE-S3 加密上传。注册仓库时带 "server_side_encryption_type": "bucket_default"，不发送加密头就能绕过。
启动报 unknown setting [s3.client.default.access_key]：这些设置依赖 repository-s3 插件。节点带配置启动失败，多半是容器里没装插件，重复装插件那一步（docker exec 装的插件在容器重建后会丢）。
仓库验证报 path is not accessible ：节点连不上桶。检查容器能否连通 s3.client.default.endpoint、path_style_access 是不是 "true"、keystore 凭证是否已加载（凭证在启动时读取，添加后要重启）。

这条链路适合什么场景

把快照收进 RustFS 之后，快照和索引分片就彻底分开了，不再共用同一块会坏的本地盘。对象存储的成本模型也比给每个节点各挂大容量盘更平滑，快照的保留周期还能借 RustFS 的 ILM 直接管。代价是快照和恢复都要走一次对象存储读写，比本地盘仓库慢一截，所以定时快照、跨节点容灾这类对时延不敏感的场景最划算；对恢复 RTO 要求极严的核心索引，本地盘加对象存储双仓库更稳。

落到多节点集群里，这套做法的优势更明显：原来每个节点各自把快照留在本地盘，恢复时要确认是哪台机器存的、磁盘还在不在；现在所有节点的快照都进同一个桶，集群级仓库注册一次，任意节点都能从桶里还原任意索引。自动化也可以接上，OpenSearch 的 Snapshot Management 策略能按周期自动打快照、按保留数滚动清理，桶的保留规则则由 RustFS 的 ILM 兜底，两层一起管，运维不用再手工盯。给 OpenSearch 用的凭证建议走专用 IAM 子账号，只对这个快照桶有读写权，不要把管理员密钥写进 keystore，凭证泄漏的波及面要压到最小。

RustFS 当前稳定版是 1.0.4（2026-10-25），覆盖 OpenSearch 需要的这些 S3 操作。官方 GA 基准里 4KiB 小对象 PUT 大约能到 MinIO 的 2.3 倍，快照多为中大对象，吞吐稳定即可，这一层 RustFS 不拖后腿。文档声明这套部署用于本地集成测试、不适用于生产环境，生产里要补上专用凭证、TLS、鉴权和资源规划，把快照桶的访问收敛到 OpenSearch 自己的服务账号上。

快照统一收进 RustFS 桶之后，索引丢了能从桶里拉回来，节点扩缩、置换、跨机房迁移都不再被本地盘绑死，存储底座和 OpenSearch 的运维心智也跟着统一了。对已经在用 RustFS 承接着日志、向量、数据库备份这类负载的团队，顺手把搜索快照也接进来，不必为 OpenSearch 单独养一套备份存储。官方把 OpenSearch 接进 RustFS 的完整步骤在 OpenSearch 集成指南里，包含仓库注册、还原与故障排查的示例。