前天 MinIO 宣告进入维护模式，老冯写了一篇《MinIO 已死》聊了聊这个话题。 很多朋友也问我，MinIO 既然摆烂躺平了，有谁能接 MinIO 的班？
大方向的话，台面上的替代品无非就那几个：Ceph、RustFS、SeaweedFS、Garage…… 老冯把这些方案都打好了 Linux 上的 RPM/DEB 包，挨个试了一遍。
总结一句话：没有完美替代。
老冯给这些方案都打好了 Linux 上的 RPM/DEB 包，都试验了一把。总体的结论是，没有一个能完美替代 MinIO 的方案。
各有各的问题 —— Ceph 功能全但太复杂；SeaweedFS 针对小文件优化但需要独立元数据库；Garage 小巧玲珑但功能简陋；RustFS 兼容 MinIO 但竟然还是 Alpha。
MinIO 替代品速览#
MinIO 是 AWS S3 的开源替代，所以从单纯的 对象 CRUD 功能 上来讲，任何兼容 S3 API 的对象存储系统都可以作为 MinIO 的替代品。 但如果考虑到非功能类特性 —— 可靠性，可运维性，复杂度，工具链，生态成熟度，运维 SOP 这些，想要 “平替” 掉 MinIO 确实不容易。
这里我们不聊商业存储，云厂商的对象存储服务，只聊开源项目的话，大体上会有这些选择：
Ceph 可能是企业用户的最佳选择，但学习曲线陡峭，适合有专人运维的团队，不像 MinIO 一个二进制走天下。 很多用户并不需要分布式块存储和分布式文件系统的功能，而且运行还需要额外的 Podmon，不如 MinIO 爽利。
SeaweedFS 质量不错，针对海量小文件场景做优化，O(1) 磁盘寻址，小文件场景性能碾压。 但它需要一个独立的元数据库来存储文件元信息，这就带来了外部依赖。如果你需要一个"通用对象存储"，它不是最佳答案。
Garage 是欧洲 Deuxfleurs 团队的作品，拿过欧盟 NGI 资助，适合自托管爱好者和边缘计算场景。 非常轻量（10MB），但 S3 兼容性太弱，没有版本控制，跨区域复制，IAM 这些，不适合企业场景。
RustFS 是唯一一个瞄准"MinIO 替代"生态位的项目，但成熟度不足 —— 竟然还是 Alpha。
RustFS 是否可以替代 MinIO#
在所有号称"MinIO 开源替代"的项目中，老冯本来最看好 RustFS，所以特地花了些时间测试。 我在 Pigsty 中尝试将 MinIO 换成 RustFS，大部分逻辑可以复用，但还是有些区别：
- RustFS 对证书名称有特殊要求
- RustFS 的健康检查接口与 MinIO 有所不同
- RustFS 不支持 mc admin 管理命令，无法配置详细的 IAM 策略。这一点对企业用户而言比较重要。
总的来说，跑起来了，但老冯思考再三，还是把这个分支给放弃掉了。因为把 Alpha 版的软件用在生产环境实在是太不像话了。 我是比较期待 RustFS GA 版本出来之后，再来做一次评测。
RustFS 是否会重蹈 MinIO 覆辙#
当然，RustFS 这个项目虽然看上去很有潜力，但也存在一些问题。例如，RustFS 是否会重蹈 MinIO 覆辙？ 特别是，RustFS 在很多雷点上，跟 MinIO 十分相似。
老冯请 AI SOTA 三件套（GPT5-pro, Claude4-Opus, Gemini3-pro）对 RustFS 的风险进行了全面的分析评测。
其中 Gemini 对 RustFS 项目提出来了几项相当严重的指控，老冯又请 Claude 核实了一遍。
RustFS 这些风险信号与当年的 MinIO 几乎一模一样：Apache 2.0 + 版权转让型 CLA + 单一商业公司控制。 考虑到这些因素，老冯对 RustFS 的评级从 “乐观期待”，下调为 “谨慎观望”。
所以，应该怎么做？#
老冯的 PostgreSQL 发行版 Pigsty 里面集成了 MinIO 作为对象存储的解决方案。 这完全是一个可选的模块，主要作用是 —— 存储 PostgreSQL 备份，以及在其他业务软件需要对象存储的时候提供一个 —— 比如自建 Supabase 。
考察了现有的生态替代品之后，老冯确实是不想再折腾换 MinIO 的事情了，也许会提供一个用 pgbackrest 自己的备份服务器替代掉 MinIO 的选项。
老冯觉得目前最优的方案，还是继续使用 MinIO 的最新版本，锁定版本，做好网络隔离。 等待半年左右，看看社区生态的发展再做打算。如果那时候 MinIO 有人接手，或者 RustFS GA 可用了，再做调整也不迟。
当然，RustFS 也可以抓住这个机会，抢占 MinIO 的生态位，并真的实现一个更好，更安全，协议更友善的 MinIO 版本。 机会不等人，老冯觉得这个窗口也就几个月时间，错过了就是错过了。
继续使用 MinIO 的注意事项#
如果要继续使用 MinIO，有这么几个注意事项。第一是应该用什么版本。 虽然说，MinIO 20250422 版本是最后一个功能完整（带有控制台 GUI）的版本，但老冯还是建议使用最新的版本。
因为从 20250422 到现在（2025-12-08）这段期间，MinIO 有一个比较严重的 CVE 安全漏洞。
CVE-2025-62506: Privilege escalation via session policy bypass (HIGH)
这个漏洞允许低权限用户创建一个新的账户实现权限提升。不过如果是在内网环境中，并且做好网络隔离的话，这个漏洞的风险也是相对可控的。 这个漏洞已经在 MinIO 20251015 版本中修复了，但是 MinIO 很鸡贼的从这个版本开始移除了二进制，只提供源代码。
不过老冯觉得还好，因为 MinIO 是一个 Go 语言项目，编译就一条命令，跨平台编译 goreleaser 一把梭也很简单。 流程我已经跑通了，其实很简单，这个事老冯可以整，等测一阵没问题了就发到 Pigsty 仓库里去，把 MinIO 重新从一个 “源码发行版” 恢复成一个二进制发行版。
但安全漏洞和BUG还是得有人来修的。老冯觉得，社区里如果有人愿意接手 MinIO 的话，现在还真是一个非常好的机会。 从 20250422 版本作为基础，CherryPick 重要的 Bug 和安全修复的话，然后开始维护一个 MinIO 社区版本。
说到底，MinIO 经过这么长时间的社区打磨，已经是一个相当成熟稳定的对象存储系统了 —— 基本上算是一个 “已完成的软件”。 需要的不是更新跟进S3各种花里胡哨的新功能（S3 Vector/S3 Table），而是扎扎实实的修 Bug 和安全漏洞。
这种维护状态的软件，搞一个 LTS，社区自发维护起来并不难。如果 MinIO 团队不愿意继续维护，老冯觉得社区里会自发涌现出接棒的人选 —— 毕竟现在有很多商业存储硬件公司都在用 MinIO。 比起自己从零瞎搞一个对象存储，接手一个成熟的项目，反而是更省事的选择。
