MinIO 仓库已归档：2026 自托管 S3 对象存储替代品怎么选？（Garage/SeaweedFS/RustFS 横评）

一、发生了什么：MinIO 社区版的落幕#

如果你在 2025 年之前搜”自托管 S3”，第一答案几乎都是 MinIO——一个 Go 写的单二进制， speaks Amazon S3 API，Kubernetes 生态里事实上的标准对象存储，GitHub 61k Stars。

但过去一年，这个项目以教科书级的节奏失去了社区：

时间	事件
2025-05	破坏性发布：社区版 Web 控制台的管理功能被大幅移除（用户/策略管理、LDAP、外部 IdP 登录），只能用 `mc` 命令行
2025-10	停止发布社区版 Docker 镜像和预编译二进制，打补丁只能自己从源码编译
2025-12	官方宣布社区版进入”维护模式”，新订阅层 AIStor Free / Enterprise Lite 推出
2026-02-12	README 标记”THIS REPOSITORY IS NO LONGER MAINTAINED”
2026-04-25	minio/minio 仓库正式归档：只读，无 issue、无 PR、无新 commit

现在你再访问 GitHub 上的 MinIO 仓库，它是一件文物，不是一个项目。存储引擎本身仍是 AGPLv3 开源、现有部署暂时也能跑，但：

没有新功能
没有安全补丁（这一点最致命）
没有官方镜像/二进制，供应链断了

官方指定的出路是他们的商业产品 AIStor（订阅制、按容量计费、License 过期会锁部分功能）。对大企业来说这可能是合理的选择，但对自托管玩家和中小团队来说，这基本等于”开源版已死”。

一个现实的警告：CVE 不会因为你停更就停止出现#

2026-04，社区披露 CVE-2026-33322（OIDC JWT 算法混淆，CVSS 9.8）：在某些 IdP 配置下，攻击者知道 ClientSecret 就能伪造任意身份（包括 consoleAdmin）。受影响窗口从 2022-11 一直持续到 2026-03 —— 也就是说，在归档前运行了三年的版本都有这个洞。还有 CVE-2026-33419（LDAP STS 枚举+无速率限制暴力破解）等一批同时披露。

归档之后，这些洞官方不会再管。用 MinIO 做备份端点、Nextcloud 存储后端、CI artifact 仓库的同学，值得认真考虑迁移了。

二、接棒的替代品：四个值得认真看的方案#

2024-2025 年里 MinIO 之外其实一直有备胎，但 2026 年格局定型了。我按”你的实际场景”把四个主流方案排开，先上总览：

对比项	Garage	SeaweedFS	RustFS	Ceph (RGW)
语言	Rust	Go	Rust	C++/Go
许可证	AGPL-3.0	Apache-2.0	Apache-2.0	LGPL 2.1
架构	去中心化对等节点，无主	Master+Volume+Filer 分层	单二进制，类 MinIO	RADOS 统一存储
冗余	副本复制（×2/×3）	复制或纠删码	纠删码	纠删码/副本
地理分布	原生 built-in	手动	否	复杂
内存需求	~1GB	1–2GB/角色	~2GB	高
Web 控制台	简易	有（Admin UI）	功能完整	ceph-mgr dashboard
S3 Object Lock	❌	部分	✅	✅
静态网站托管	✅	有限	✅	✅
适用规模	小集群、多站点	海量小文件、大规模	单机/中小集群、AI 数据湖	超大规模生产集群
一句话定位	像素级适合”三台不同机房的_ARM 小机器组集群”	生产级多面手，小文件之王	”想继续用 MinIO 那种简单” 的直接替代	要 object+block+file 三合一才考虑

方案 A：Garage —— 多站点/家用机架 disadvantage 之王#

Garage 是法国非营利技术团体 Deuxfleurs 开发的 Rust 对象存储，设计目标很明确：在不可靠网络、跨多个物理地点、异构廉价硬件上，跑一个可靠的 S3 兼容存储。官方卖点是”你可以在数据中心外跑它”。

为什么它是”后 MinIO 时代”的头号候选：

真正去中心化，无主节点：每个节点都是对等的 peer，用类 Raft/CRDT 协调，没有 leader 瓶颈，节点挂一半照样读写。
Zone 感知复制：定义 zone（机房/楼/房间），副本自动跨 zone 分布——这是 MinIO 和 SeaweedFS 都做不好或做不了的事。
资源占用极低：单个静态二进制 ~19MB Docker 镜像，1GB 内存 + 16GB 磁盘 + ARMv7 都能跑。宿舍里三台旧笔记本组分布式存储完全可行。
桶直接当静态网站：一个 bucket 配个域名就能当 Web 服务器用，MinIO 和 Ceph 都没这个。个人博客、静态站、图床直接省一层。

代价：

使用副本复制（非纠删码），×3 副本意味着 3 倍磁盘占用——个人/小团队无所谓，TB 级以上要认真算。
没有 S3 Object Lock（合规保留），对要求严苛的备份场景是短板。
生态和文档比 SeaweedFS 小，踩坑靠勤翻官方手册。

适合你，如果：你有多台机器（不同地点更好）、追求自托管哲学的”去中心化”、数据量在 GB~TB 级。这是最贴近”长期/更适合个人自托管”的选择。

方案 B：SeaweedFS —— 生产级多面手，小文件之王#

SeaweedFS 是 Go 写的分布式存储系统，2012 年至今 13+ 年，Apache 2.0 授权（注意：没有 AGPL 传染性，这点对商用/内嵌场景比 MinIO 的 AGPLv3 更友好）。Google 云在 Kubeflow Pipelines 弃用 MinIO 后把它设为了默认对象存储——这个选型本身就是背书。

架构是三层：

master：管理 volume 拓扑、分配文件 ID
volume servers：实际存数据，小文件会被打包进大卷文件（借鉴 Facebook Haystack 论文），无论多少文件，磁盘寻道 O(1)——十亿级小文件场景吊打 MinIO
filer + S3 gateway：在卷上加了 POSIX 式目录语义，S3 API 就架在这层

V2.x 加入了冰山（Iceberg REST Catalog）支持和 S3 Tables，现在一个 weed 二进制能同时当对象存储、文件系统和 lakehouse 用。一键命令 weed mini -dir=./data 就跑起来，单机/小集群足够。

代价：

架构分层多，比 MinIO 多几个要操心的组件（master 挂了要处理）。
地理分布要手动搞，没有 Garage 那种 zone 原生概念。
S3 API 走 gateway 翻译层，覆盖度不如 MinIO 原生；少数高级特性（Object Lock 等）是部分支持。

适合你，如果：数据量大、文件数多（大量小文件）、或要内嵌商用（Apache 2.0 无传染顾虑）。这是”大规模替换 MinIO”的最稳选择。

方案 C：RustFS —— “想要 MinIO 的简单”的直接替代#

RustFS 是 2025 年出现的 Rust 写的新秀，定位非常直白：“开源版 MinIO 的直接替代，兼容 S3 API + 保留完整 Web 控制台”。Apache 2.0 授权，官方数据 4KB 小对象读写速度 ≈ MinIO 的 2.3 倍（Rust 没有 GC 停顿，小文件场景内存更稳）。

2026 年的几个事实：

GitHub 31k+ Stars 增长非常快（半年从几千涨到 31k）
保留了完整的管理控制台——这是被 MinIO 社区版删掉的那块，迁移到 RustFS 反而找回体验
但要诚实看：分布式集群模式还在”Under Testing”，成熟度与 MinIO 巅峰期或 SeaweedFS 相比仍有差距。第三方评测也指出部分指标（如 HNSW 向量库写路径）是”write-heavy 场景占优”，读路径没那么夸张。

适合你，如果：你是个人/小团队场景（单机或简单分布式）、想要”点开控制台就能管理”、接受新项目相对年幼的风险。这是”体验最接近原生 MinIO + 平滑迁移”的选择。

方案 D：Ceph（RGW）—— 重量级玩家专属#

如果你已经是中型团队，要的不只是对象存储，而是 object + block (RBD) + file (CephFS) 三合一，或者是 Kubernetes 里准备用 Rook 跑生产集群——Ceph 的 RADOS Gateway 依然是最重型也最完整的选项。代价是要一个有业余时间会看 placement group/config dump 的运维。个人 VPS 一台机器上跑 Ceph 是严重杀鸡用牛刀，不建议。

三、迁移建议：该怎么选？#

根据数据量和规模，我的选型决策树：

1
你是个人/小团队，机器 ≤ 5 台？
2
├─ 跨多个地点/不在乎带宽抖动 → Garage
3
├─ 单机 + 想要 Web 控制台 + 想平滑迁移 → RustFS
4
└─ 文件数多/数据量大 → SeaweedFS (weed mini 单机起步)
5
你是企业/中大型生产？
6
├─ Apache 2.0 + 海量小文件 → SeaweedFS
7
├─ 要 object+block+file 全家桶 → Ceph (Rook)
8
└─ 已有 MinIO 但要 SQL/AI 生态，愿意付费 → 官方 AIStor

已有 MinIO 部署的，先做三件事（无论是否立刻迁移）：

暴露面收敛：不要把 S3 端点直接暴露公网，反代 + 访问控制收紧（上面的 CVE 场景都是 IdP/LDAP 配置相关）。
开启审计日志：最后至少留个证据链。
数据迁移演练：MinIO 对 S3 API 的实现是标准兼容的，mc mirror 或 rclone 可以直接搬到 Garage/SeaweedFS/RustFS 的端点，不会锁数据。

已用 MinIO 做照片/文件备份的（如 Immich、Nextcloud 后端），迁移成本几乎为零——SS3 API 是标准接口，换个 endpoint + credentials 就行，数据不用碰。Nextcloud 也支持把主存储指向 S3 端点。

四、结合现实：怎么从零开始跑一个？#

以 Garage 为例（多站点自托管最省心），三步：

1
# 1. 下载二进制（~19MB，无依赖）
2
wget https://garagehq.deuxfleurs.fr/_releases/v2.1.0/x86_64-unknown-linux-musl/garage
3
chmod +x garage
4

5
# 2. 写最小配置 garage.toml
6
# replication_factor = 1（单机）或 3（三节点）
7
# metadata_dir / data_dir 指到数据盘
8

9
# 3. 启动 + 创建桶
10
./garage server -c garage.toml
11
./garage layout assign -z dc1 -c 1 -t node1 <node_id>
12
./garage bucket create my-bucket
13
./garage key create my-key
14
./garage bucket allow --read --write my-bucket --key my-key

之后 aws --endpoint-url http://localhost:3900 s3 cp file s3://my-bucket/ 或者任何 S3 SDK 照常工作。三台节点（哪怕分布在三个机房）重复这个过程，garage layout assign -z dc2/dc3 设不同 zone，副本自动跨机房分布。整个过程内存占用 < 200MB，1 核 1G VPS 绰绰有余。

单机快速试玩的话，RustFS 的体验最像老 MinIO：

1
mkdir -p data logs && chown -R 10001:10001 data logs
2
docker run -d -p 9000:9000 -p 9001:9001 \
3
  -v $(pwd)/data:/data -v $(pwd)/logs:/logs rustfs/rustfs
4
# Web 控制台在 9001 端口

想实际部署，一台 VPS 就够了。挑机器可以参考这篇 VPS 新手入门教程。选型/跑 Garage 或 RustFS 这类轻量存储，DediOne 的洛杉矶 CN2 GIA / 堪萨斯城 / 香港 VPS 从 $12.99/年 起，支持支付宝/PayPal，1 核 1G 档跑对象存储绰绰有余。

五、和一个旧话题的呼应：开源 dies，自托管 lives#

写到这里你会想起来，这个站里已经出现过同样的故事——IPFS 核心团队停摆 (2026-09)、MinIO 仓库归档 (2026-04)、再加上更早的各种”开源转商业”。这是个反复出现的模式：

把”社区版”当作商业版的获客入口，赢了商业客户，凉了社区信任。

我的看法不变（那篇文章也写过）：你数据所在的基础设施，是否”活跃”不该依赖一家公司的盈利意愿。 或者说得更直白——判断一个开源项目是否值得长期投入，看治理结构是不是”一言堂”（一家公司控制 + AGPL 转商业动机，双高危信号），比看 Star 数重要。

从治理角度，值得长期：

SeaweedFS：Apache 2.0，社区多贡献者，商业公司凑不齐权力
Garage：非营利团体 Deuxfleurs 维护，本身就是”为不在数据中心跑”而设计，跟你数据主权的需求在同一哲学频率上
RustFS：目前是公司主导，Apache 2.0 缓解了传染顾虑，但要持续观察它的开源承诺

FAQ#

Q：MinIO 现有部署还能继续用吗？ 能用，但别用。它是 AGPLv3 开源，代码还在，只是没有维护。如果你内网跑、没接 OIDC/LDAP（上面的 CVE 场景）、数据有异地备份，短期内不会有事。但”没有安全补丁的存储软件”就像没换过机油跑高速——迟早的事。

Q：MinIO 的开源 fork，比如 pgsty/minio，靠谱吗？ pgsty/minio 是现实里活跃度最高的 fork：Pigsty 作者为修复自己生产环境的 CVE 而维护，2026-04 一次修复了包括 CVE-2026-33322 在内的 4 个洞，有 RPM/DEB 包和恢复的控制台。“无新功能、只修安全” 的定位让它不会野心膨胀，反而比官方更可信。如果你只是想”继续用 MinIO 但有人管洞”，切到 pgsty/minio 的 Docker 镜像（pgsty/minio）是成本最低的选择。但 fork 的治理和持续性本质上是”一个人 + AI 助手”的赌注，不在长期选型里当第一答案。

Q：AGPL 到底有什么问题？ AGPLv3 本身是开源的，但它的”网络分发条款”让很多公司和 embedder 起疑——你把改过的代码跑在带网络的服务上，就要提供源码。MinIO 用 AGPL 和社区控制的组合跑出了个”鲍尔式作茧”：想替代者多。Apache 2.0 的 SeaweedFS / RustFS 就没有这个顾虑。 个人自用无感，商用团队选型时别忽略。

Q：Immich / Nextcloud 用的存储后端要迁吗？ 这两个都支持任何 S3 兼容端点，把 endpoint/credentials 换成 Garage / SeaweedFS / RustFS 的就行，业务无感。Immich 默认存储是本地磁盘路径，用 MinIO 的就应该考虑换成上述任一（或干脆转 Syncthing + 本地盘的组合）。

小结#

MinIO 社区版 2026-04-25 的归档，是一个时代的落幕，也是自托管存储格局的重排。个人/小团队优先看 Garage（多站点/去中心化）和 RustFS（单机/控制台/平滑迁移）；大数据量/商用看 SeaweedFS（Apache 2.0 / 小文件之王）；重型生产看 Ceph (Rook)；还在用 MinIO 的，要么切 pgsty/minio 分支拿安全补丁，要么用标准 S3 兼容性做无痛迁移。

数据主权这回事上，从来就没有”最安全的地方”，只有”最不依赖任何一方的地方”。自己跑一个，才谈得上”长期”。

部署相关的更多实战可以参考：VPS 新手入门、rclone 云存储同步、Syncthing 文件同步、IPFS 团队停摆分析。

音乐