RustFS 1.0 GA：别活成 MinIO 的样子
内容提要
RustFS 发布 1.0 GA，采用 Apache 2.0 许可，功能较全，S3 Tables 完全开源，并兼容 MinIO 磁盘格式。实测未加密数据可全停替换并回滚，但加密数据、滚动替换和启动配置仍受限。作者提醒其监控缺少 Prometheus 端点，PB 级生产验证不足，商业化后须明确开源边界，勿重蹈 MinIO 覆辙。
延伸解读
迁移兼容的边界：未加密、全停、调配置
文章实测表明，RustFS 对 MinIO 磁盘格式的兼容仅适用于未加密数据，且必须全停替换，不能滚动升级。加密数据因 KMS 和 SSE-C 格式不兼容而无法迁移，启动配置中的 --certs-dir 参数也会导致解析失败。因此，官方“直接替换二进制”的说法需附加三个前提，否则可能引发生产事故。
节点故障行为差异：读仲裁更严格
在四节点各一盘部署中，挂掉两个节点时，MinIO 降级为只读，而 RustFS 直接不可用。这是因为 RustFS 的读操作不仅要求数据足够，还要求法定人数足够。这一差异在平时难以察觉，但在故障时可能影响备份恢复，迁移前需评估其对可用性的实际影响。
监控短板：缺少 Prometheus 端点
RustFS 的指标通过 OTel 推送，没有 Prometheus 兼容的 /metrics 端点。虽然可通过 Prometheus 的 OTLP 接收功能变通，但推送模型难以支持多副本独立抓取，给运维带来改造负担。对于已使用 Prometheus 或 VictoriaMetrics 的团队，这是一个需要提前考虑的集成成本。
商业化风险：开源边界需明确
文章提醒，RustFS 目前 Apache 2.0 许可，但 GA 后将区分开源版和商业版。MinIO 的教训显示，许可证变更和功能回收可能逐步发生。建议 RustFS 公开承诺开源边界、许可证政策及供应链保障，让用户能判断长期可用性，避免重蹈 MinIO 覆辙。
Q&A
RustFS 1.0 GA 是什么？它和 MinIO 有什么关系？
RustFS 1.0 GA 是 RustFS 发布的正式版对象存储系统，采用 Apache 2.0 许可，功能较全，S3 Tables 完全开源，并兼容 MinIO 磁盘格式。它被视为 MinIO 的潜在替代品，因为 MinIO 近期删除了 Docker Hub 仓库并停止维护开源版。
从 MinIO 迁移到 RustFS 需要满足哪些条件？
根据测试，迁移需满足三个前提：未加密数据、全停替换（不能滚动替换）、调整启动配置（如移除 --certs-dir 参数）。未加密数据可以全停替换，写入新数据后还能回滚回 MinIO。
RustFS 在监控方面有什么不足？
RustFS 的指标走 OTel 推送，没有 Prometheus 兼容的 /metrics 端点。虽然可以通过 Prometheus 的 --web.enable-otlp-receiver 接收，但推送模型难以实现多副本独立抓取，对使用 Prometheus 或 VictoriaMetrics 的团队是实际卡点。
RustFS 在 PB 级生产环境中的验证情况如何？
目前公开材料中缺乏 PB 级生产验证证据。官方案例容量主要在几十到上百 TB，虽然早期用户反馈积极，但几十 TB 跑得好不能直接外推到几个 PB，PB 级这一关还需要更多证据。
RustFS 商业化后可能面临什么风险？
风险在于开源版和商业版的功能边界可能逐渐收紧，重蹈 MinIO 覆辙。作者建议 RustFS 公开明确开源边界，包括哪些能力留在开源版、许可证是否会改、二进制和镜像的发布策略等，以建立用户信任。
RustFS 相比 MinIO 有哪些值得肯定的优点？
RustFS 采用 Apache 2.0 许可，对 AGPL 有顾虑的团队更友好；S3 Tables 完全开源；功能清单齐全，基本追平 MinIO 开源版；并且对 MinIO 磁盘格式的兼容性经过测试，未加密数据可全停替换并回滚。
