rustfs/rustfs 32.9k★:MinIO 主仓归档之后,这个 Rust 写的 Apache-2.0 对象存储发了 1.0.0

2026 年 9 月 18 日打开 GitHub 趋势页,rustfs/rustfs 在日榜上单日 +559★。它的时间线很密:9 月 16 日发布 1.0.0 GA(正式版,非预览),9 月 17 日凌晨发 1.0.1-preview.1、当天下午发 preview.3,今天(9 月 18 日)中午又发 1.0.1-preview.5——正式版发布 48 小时之内,发了三个预览版。

只看版本号会觉得这是个着急的团队。但把它的对手那一头也摆出来,节奏就说得通了:minio/minio 的 GitHub 仓库现在是 archived 状态,最后一次推送停在 2026-04-24,仓库首页 README 的第一行是"THIS REPOSITORY IS NO LONGER MAINTAINED",替代方案指向 AIStor Free(免费许可的独立版)和 AIStor Enterprise(带商业支持)。一个 61,362★、被无数 Docker Compose 文件写死过的项目,把开源这条路让出来了。

这一篇只写 RustFS 一个项目。不写"今天对象存储圈发生了什么",只回答一件事:这东西值不值得你换掉手上的 MinIO,怎么上手,哪些地方会咬人。

一句话定位:它是什么,今天为什么在趋势页上

• 是什么:一个用 Rust 写的分布式对象存储系统,S3 API 兼容,Apache-2.0。官方 README 自己给的坐标是"MinIO 的简洁 + Rust 的内存安全与性能",仓库的 topics 里直接挂 minio、object-storage、s3、ai-storage。
• 体量(2026-09-18 晚,取自 GitHub REST API):32,970★、1,478 fork、6,764 次提交、174 位贡献者、26 个未关闭 issue;2023-11-23 建仓,今天 20:45 还在推代码。
• 为什么是现在:它的 1.0.0 正式版与 MinIO 开源主仓的退场撞在同一个星期。一边是"老的开源选项关闸",一边是"新的开源选项宣布核心引擎可用于生产",中间那批"要私有化 + 要 S3 兼容 + 不想被许可绑死"的人需要一个落点。
• 许可这一条对做副业的人是真金白银:RustFS 是 Apache-2.0,MinIO 主仓是 AGPL-3.0。AGPL 的传染范围和"你改了要回馈社区"的义务,在自己搭个存图片、存备份的服务时没什么体感,但一旦拿它做对外收费的服务,就变成要先算清的法律问题。

先把事实边界划清:哪些是我查到的、哪些是别人说的

写新项目最容易失手的地方是把社区转述当事实用。这里分开写:

已核实的实锤

• minio/minio 仓库 archived: true,最后推送 2026-04-24,README 写明不再维护并导向 AIStor 两条产品线。
• RustFS 1.0.0 是一个非预览的正式 release,发布时间 2026-09-16;1.0.1-preview.1/3/5 分别落在 9 月 17 日、17 日、18 日。
• RustFS 采用 Apache-2.0;默认构建不包含 rio-v2 feature——这一条直接决定了 MinIO 加密数据能不能读,后文单列。

流传较广但我没能独立核实的

• 有社区文章称 9 月 11 日 Docker Hub 上 minio/minio、minio/mc 两个镜像仓库 404、镜像拉不下来(出处是一篇第三方分析文章)。我试着用本机直连 Docker Hub 接口复核,连接超时,没拿到结果。所以这一条按"社区报道、待核实"看待,能确定的只有 GitHub 仓库的归档状态。
• 官方渠道流传的"270 万+ 安装实例"“Docker Hub 拉取超 1000 万"这类数字,我按团队自述处理,没写进结论。

核心功能:官方能力表里,哪些已 GA、哪些还是预览

README 给了一张带状态标记的能力表(✅ 已发布并有 CI 门禁,🧪 预览),这是判断"能不能上生产"的第一手材料:

三个必须提前知道的细节,官方在自己的说明里写得很直白:

1. RustFS KMS 的 Local 与 Static 后端只能用于开发测试,生产要用 Vault(KV2 / Transit)或 AWS KMS。
2. Swift 与 SFTP 是编译期可选特性,默认二进制里没有;想用要自己按 --features swift / --features sftp 构建。
3. ACL 授权这一块官方明确不做。兼容矩阵文档里那句原文是 ACL authorization is intentionally unsupported——如果你的应用依赖对象级 ACL 而不是桶策略,现在就该把它列进评估清单。

怎么用起来:两条最短路径

路线 A:Linux 二进制 + systemd(官方一键脚本)

1

curl -O https://rustfs.com/install_rustfs.sh && bash install_rustfs.sh

脚本会把二进制装到 /usr/local/bin/rustfs,注册 rustfs systemd 服务并启动,默认数据目录 /data/rustfs0,监听 9000(S3 API) 和 9001(控制台)。装完它自己会打印一行安全警告,提示你去改凭据——这一步不是可选项:

1
2
3

# /etc/default/rustfs
RUSTFS_ACCESS_KEY=<你的 access key>
RUSTFS_SECRET_KEY=<你的 secret key>

1
2
3

sudo systemctl restart rustfs
sudo systemctl status rustfs --no-pager     # 应为 active (running)
curl -fsS http://127.0.0.1:9000/health/ready

两个容易踩的坑,都在官方文档里写着:

• 不设这两个变量,服务会回落到内置默认值 rustfsadmin / rustfsadmin。官方原话是"临时本地测试可以,任何别人能访问到的场景都不行”。如果你打算把控制台开到公网,这一步漏掉等于把门开着。
• access key 要用大写字母加数字。不要直接把 openssl rand -base64 24 的输出贴进 RUSTFS_ACCESS_KEY:Base64 里可能出现 /,而 / 会与 AWS Signature V4 的凭据作用域冲突。

路线 B:容器(适合已经有一堆 Compose 文件的人)

1
2
3
4
5

mkdir -p data logs
chown -R 10001:10001 data logs     # 关键:容器以非 root 用户 rustfs(10001:10001)运行
docker run -d -p 9000:9000 -p 9001:9001 \
  -v $(pwd)/data:/data -v $(pwd)/logs:/logs \
  rustfs/rustfs:latest

带 -v 挂载宿主目录时,被挂载的每个路径都必须对 10001:10001 可写,否则启动会因为权限被拒;TLS 证书目录(RUSTFS_TLS_PATH)同理。用 Podman 的话官方给了 :Z,U 的挂载写法,能省掉手工 chown。

客户端:继续用你顺手的 S3 工具就行

RustFS 自带一个 S3 客户端 rc(官方也提供 rclone、restic、s3cmd、AWS CLI、Terraform 的示例文档):

1
2
3
4
5

rc alias set rustfs http://<服务器IP>:9000 <access-key> <secret-key>
rc bucket create rustfs/my-bucket
rc object copy /path/to/hello.txt rustfs/my-bucket/hello.txt
rc object list rustfs/my-bucket
rc admin info cluster rustfs         # 看后端布局、EC 校验位、磁盘可用性、池成员

用它给服务器做异地备份:两个 path-style 的坑

这是我认为对个人服务器玩家最实用的一条路——把你那台机器的数据用 restic 或 rclone 推到 RustFS 上。官方文档给了完整示例,但有两行配置不写对就是连不上:

1
2
3
4
5
6
7

# ~/.config/rclone/rclone.conf
[rustfs]
type = s3
provider = Other
endpoint = http://127.0.0.1:9000
region = us-east-1
force_path_style = true

1
2
3
4

export RESTIC_REPOSITORY=s3:http://127.0.0.1:9000/my-bucket/restic
restic -o s3.bucket-lookup=path init
restic -o s3.bucket-lookup=path backup ~/Documents/restic-demo
restic -o s3.bucket-lookup=path check

部署模式怎么选:SNSD / SNMD / MNMD

官方把拓扑分成三档,容错能力写得很清楚,别拿一键脚本装完的那套当生产:

一键脚本装出来的默认形态是 SNSD。这一点很重要:它的名字里那个"单盘"意味着没有任何冗余,官方也明确说这条路"不能原地扩容、也不能作为 Pool 加入",要换多盘拓扑只能新建部署、通过 S3 把数据搬过去。

资源要求:官方文档给了两套口径,差得很远

这里必须点出来,因为选型就看这几个数。同一套官方文档,两个页面的说法不一样:

我的读法:测试环境按 1-2 GB 内存就够跑起来,生产按"64 GB 起步、官方另一处写 128 GB"取保守值,别拿 A 表里那行 1 GB 去做生产预算。两处口径不一致这件事本身也说明:它的生产规模仍然以"多节点集群"为默认假设,单机玩家要用的是它的小体量那一面。

生产硬件矩阵(官方按压力测试给的基线):

另外它给了一条内存分配策略:元数据缓存占 60%、读写缓冲 30%、系统预留 10%。这条数字值得记下来——对象存储吃内存主要是吃元数据,不是吃吞吐。

从 MinIO 搬过来到底行不行:官方有一份专门的兼容文档

我翻到的最有价值的一份文件是仓库里的 docs/architecture/minio-file-format-compat.md。它把"能不能直接接管 MinIO 的盘"拆成了具体条目,而且明确写了这是单向迁移(MinIO → RustFS):

这张表最需要读懂的是中间两行:默认构建下,MinIO 加密过的对象会"列得出来、HEAD 显示正常大小,但读不出内容"。这比直接报错更危险——批量迁移时你不会立刻发现,等某个应用真去读那个对象时才炸。所以如果你的 MinIO 里开着 SSE,先分清是"内置静态 KMS"还是"外部 KES",前者需要专门构建 rio-v2 并配主密钥,后者官方明确不在计划内,只能先在 MinIO 侧解密再走 S3 层搬。

观点与事实分开说一句:有一篇传播很广的分析文章作者自己声明是另一个 MinIO 兼容项目(Silo)的维护者,他的判断"RustFS 面向的是愿意往前走一步的新用户,而不是要求「什么都别动」的老用户"是有信息量的,但那属于竞品视角,不建议直接当结论抄。

现在还存在的问题(全是公开可查的)

这一节是我判断"现在上不上"的主要依据,条目都带 issue 编号,或直接附上对应文档:

1. 发版节奏极快,GA 不等于冻结:1.0.0(9/16 18:03)→ preview.1(9/17 05:23)→ preview.3(9/17 13:00)→ preview.5(9/18 11:11,均为北京时间)。官方对 GA 的表述是"核心对象存储引擎已稳定",不是"整棵树停止变更"。
2. 今天刚开的两个升级事故(2026-09-18):
   • #8011:用 RPM / DEB 包升级时,升级过程会停掉 rustfs 服务并且不再启动它——包管理器用户会静默地掉服务。
   • #8003:从 1.0.0-beta.11-preview.1 升到 1.0.1-preview.5,已有桶会报 500(bucket incarnation sidecar exists with ...)。 这两条合起来给出的操作纪律很简单:升级前备份配置和旧二进制,一次只升一个节点,升完立刻探活再往下走。
3. 升级流程要按文档走(官方二进制升级文档的原文步骤):先 cp /etc/default/rustfs /etc/default/rustfs.bak、cp /usr/local/bin/rustfs /usr/local/bin/rustfs.previous 留回滚,再换二进制、启服务、curl -fsS http://<节点>:9000/health/ready 确认 ready。容器用户用具体版本 tag升级,别用 latest;并且不要用 docker compose down -v 这类命令——那会连持久化卷一起删掉。
4. SNSD 不可原地扩容,要换拓扑只能新建部署 + 通过 S3 迁移数据。
5. 默认凭据与暴露面:不设 RUSTFS_ACCESS_KEY / RUSTFS_SECRET_KEY 就回落到 rustfsadmin / rustfsadmin;控制台默认在 9001。要放到公网必须自己配 TLS。
6. 兼容边界里几条会影响脚本行为:除了前面说的 ACL 不支持,兼容矩阵还写明 CopyObject 带 MetadataDirective=REPLACE 时会清掉请求里没显式给出的元数据(包括 Content-Type);MinIO 风格的 metadata=true 列表扩展返回的字段名不带 x-amz-meta- 前缀。搬数据写脚本的人要专门测这两条。
7. 健康检查有抖动案例:issue #7950 记录 /health/ready 会在健康节点上闪 503(pool_metadata_check_timeout),原因是内部 100ms 的互斥检查超时。做自动化探活/重启策略时,别把单次失败当成节点挂了。
8. 项目年龄与治理:2023-11 建仓、2026-09 才 GA,提交与发布集中在少数核心维护者手上。它的长期走向取决于 RustFS, Inc. 这家公司——这比"star 数够不够"更值得放进你的风险评估表。

和同类比:它处在哪一档

一句话概括它在表格里的位置:对"想自己搭一个 S3、又不想被许可和归档状态卡住"的人,RustFS 是目前 GitHub 上 star 最高、文档最完整的那个新选项;对"已经有 Ceph 集群"或"只想每月花几块钱"的人,它并不构成替换理由。

我的判断:谁现在就可以上、谁再等等、谁别碰

现在就可以上

• 手上有第二台机器、想给主服务器做异地备份的人:走"Linux 一键脚本 + restic/rclone"这条路,一个下午能通。记得改默认凭据、加 path-style 配置。
• 2026 年之后新建的对象存储需求:新集群、新项目本来就没什么历史包袱,直接从 Apache-2.0 起步,比将来再从 AGPL 迁出来便宜。
• 对 Web 控制台有硬需求的自建玩家:控制台是它明面上的强项之一,基础管理不用再靠 mc 命令敲。

再等等

• MinIO 里存了加密数据(SSE-S3/SSE-KMS/SSE-C)的人:默认构建读不出来,要专门构建 rio-v2 并配主密钥;用外部 KES 加密的那部分官方不做。先把数据在 MinIO 侧解密、或走 S3 层搬,别指望换块盘直接起。
• 用 RPM / DEB 包做自动化升级的人:今天的 #8011 说包升级会把服务停掉不再起来,等这个修完再上自动化。
• 生产单机玩家:SNSD 零冗余、SNMD 整机故障即丢数据——如果你的数据重要,单机跑它只能当缓存层,不能当唯一副本。

别碰

• 不打算改默认凭据就把 9001 开到公网的人:这和把 Milvus、Grafana 那类服务的默认口令端口暴露出去是同一类事故。
• 要求"装上就一直稳、别天天更新"的人:GA 之后 48 小时三个 preview,这个项目的迭代强度不适合零维护心态。
• 拿它当唯一备份的人:它自己的文档就把纠删码和备份分得很清——纠删码救磁盘,救不了误删和整机故障。

顺带一提:对象存储落地到自己的小机器上,1.6 GiB 内存服务器能跑什么有同款机器的实测余量。

本文由拾光札记编辑部整理,勘误请联系我们。

本文事实取自 GitHub REST API(仓库元数据 / Releases / Issues,取数时间 2026-09-18 21:20-21:40)、仓库 README 与 docs/architecture/ 下的兼容性文档、以及 docs.rustfs.com 的官方文档(安装、硬件选型、生产检查清单、升级、rclone 与 restic 集成页)。star / fork / issue 数实时变动,以仓库页为准;凡属团队自述或第三方转述的数字,文中已逐条注明来源性质。

站内可对照阅读:

• 1.6 GiB 内存服务器能跑什么:真实内存清单
• 1.6GB 服务器跑 Hugo + Caddy + DSH 实测清单
• 服务器成本计算器:1.6 GiB 跑一个静态博客每年要花多少
• JustVugg/colibri:把磁盘当显存用的本地推理引擎