RustFS 1.0.0 深度解析：GA 之后，它值得替代 MinIO 吗？

大家好，我是程序员天天困。

RustFS 终于迎来了 1.0.0 正式版。对关注 MinIO 替代方案的人来说，这是个值得认真评估的节点。对象存储承载着业务数据，能不能替换现有系统，还得看接口兼容性、故障恢复能力和迁移成本。

下面先看它为什么值得关注，再看功能、性能和迁移限制，最后动手部署。

一、GA 发布了，意味着什么

RustFS 的 1.0.0 GA 公告 发布于 2026 年 9 月 16 日，GitHub 也有对应的 1.0.0 Release。GA 是 General Availability，通常表示产品正式面向用户发布。

按官方公告，项目从 2024 年 2 月开始开发，2025 年 7 月开源，2026 年 4 月进入 Beta、8 月进入 RC，最终在 9 月发布 GA。从第一行代码算起约两年零七个月，从开源算起约十四个月，两者的起点不同。

公告还列出了 32,000+ GitHub stars、1,000 万+ Docker Hub 镜像拉取和 270 万+ 部署实例。这些是公告发布时的官方统计，其中部署实例数未交代统计方法，不能直接等同于活跃用户数或生产客户数。

官方对 GA 的定位是：核心对象存储引擎已经稳定，可用于生产负载。 对使用者来说，这是一个重要信号，具体业务上线前仍需验证兼容性、性能和故障恢复。

二、为什么它会成为 MinIO 的替代候选

1. 许可证与维护状态，影响长期采用成本

2021 年 4 月，MinIO 服务端项目从 Apache-2.0 转向 AGPLv3。2025 年 5 月 24 日的发布说明又宣布调整内置 Console，转向 object-browser。截至本文核查日，MinIO 社区版仓库 显示已于 2026 年 4 月 25 日归档，README 明确标注不再维护。社区版用户因此需要重新考虑从哪里获取补丁、如何升级，以及由谁负责长期维护。

这里要分清产品：归档的是社区版仓库，MinIO AIStor 的许可、功能和支持应另行评估。AIStor 产品线也提供采用免费许可的单机版本，因此社区版归档不意味着 MinIO 全线停止维护。

许可证也容易被讲偏。AGPLv3 不等于“用了 MinIO，整个业务系统都必须开源”。 第 13 条主要要求：修改程序后，如果用户通过网络与该修改版本交互，应向这些用户提供获取相应源代码的途径。其他代码是否受影响，要结合修改、组合和分发方式判断，不能只凭调用了 S3 API 下结论。

RustFS 使用宽松的 Apache-2.0 许可，通常更便于商业集成和再分发，也不要求因此公开独立的自有业务代码。但再分发仍需保留许可证及相关声明、标明修改，并遵守适用的 NOTICE 要求。

用两条路线比喻许可证带来的采用成本差异，具体义务仍以许可证条款为准。

2. Rust 提供实现优势，性能仍要看负载

对象存储需要持续处理并发请求、磁盘 I/O 和大量缓冲区。安全 Rust 的所有权和借用检查可以防止多类内存错误；RustFS 也不依赖 Go 那样的追踪式垃圾回收（GC），因此没有这类 GC 带来的停顿。

不过，没有 GC 不等于没有延迟尖峰，也不能直接推出 P99 更低。 磁盘排队、网络抖动、锁竞争和线程调度都可能拖慢请求；Go 的 GC 也主要与程序并发运行。unsafe、外部库接口和依赖仍需要审计，语言优势不能代替系统设计与测试。

选型时应同时看吞吐量、错误率和尾延迟。P99 表示约 99% 的请求延迟不超过该值，有助于观察慢请求，但比较双方时必须使用相同负载与配置。

曲线用于概念说明，并非 RustFS 与 MinIO 的实测结果；无 GC 也可能出现延迟尖峰。

3. 架构是否合适，要结合存储需求判断

RustFS 与 MinIO 都主要面向 S3 对象存储，采用对等节点设计，不需要额外部署专用的中心元数据服务器。Ceph 则同时覆盖块、文件和对象存储，功能面更广，部署和运维涉及的组件也更多。

Ceph 的对象存储由 RGW 在 RADOS 之上提供，MDS 则用于 CephFS 文件系统，不能把 MDS 当成其对象存储的中心元数据服务。Ceph 通过 CRUSH 计算数据位置，也避免了对中心对象位置查询表的依赖。

因此，只需要 S3 服务、重视宽松许可的团队，可以重点评估 RustFS；同时需要块、文件和对象存储的团队，则更有理由考虑 Ceph。无论选择哪种系统，都要检查节点、访问入口和共享基础设施是否存在单点故障。

三、1.0.0 有哪些功能，边界在哪里

理解了许可证和架构差异，再来看实际功能。GA 公告列出的主要能力如下，具体使用时仍需核对启用条件和兼容范围：

比功能名称更重要的是支持范围。S3 兼容不代表覆盖 AWS S3 的全部行为。 1.0.0 的兼容性说明列出了具体限制：例如不支持 ACL 授权，桶访问日志和表单上传校验和处理等方面仍有测试未通过。已有应用如果依赖这些行为，应先查对应版本的兼容性矩阵。

S3 Tables 是一个值得关注的扩展：RustFS 将 Apache Iceberg REST Catalog 集成到存储服务中，管理表的命名空间、元数据和快照提交，数据文件仍通过 S3 接口读写。采用这套 Catalog 时，可以少维护一个独立服务，查询和计算仍由 Spark 等引擎完成。不过，支持 Iceberg REST 协议并不意味着覆盖了 AWS S3 Tables 的全部 API 和托管能力。

多协议支持也需要分开看：WebDAV、FTP/FTPS 在标准构建中提供，但默认不启动相应服务；Swift 是可选编译功能；MCP（模型上下文协议）则通过独立适配组件，让 AI 应用访问 S3 存储，需要另外部署。当前 MCP 文档还提示旧构建入口可能失效，使用前应确认对应组件的位置和安装方法。

站点复制与桶复制也不同：前者涉及 RustFS 站点之间的身份、桶及元数据等状态协调，后者可将对象复制到符合要求的 S3 目标。两个系统都支持 S3，并不意味着它们能直接建立站点复制关系。实际选型时，先列出业务必需的功能，再验证接口、权限和异常处理，比单纯比较功能数量更有意义。

四、性能报告怎么看：写入亮眼，读取有差异

本文引用的 官方性能报告 发布于 2026 年 7 月 17 日，比较的是 RustFS 1.0.0-beta.10 与 MinIO AIStor 商业版 RELEASE.2026-06-06T02-44-06Z。它不是 GA 版对 MinIO 社区版的测试。

报告使用 Azure 上的 4 节点集群，每节点 4 块 300GB 磁盘、8 核 CPU、16GB 内存，系统为 Ubuntu 24.04。测试工具为 warp，覆盖 11 种对象尺寸，64 并发，每轮运行 5 分钟。

按报告结果，RustFS 的 PUT（写入）在全部 11 种对象尺寸上领先，比值为 1.05～2.85；GET（读取）则有快有慢。下面选取几个代表性尺寸：

比值大于 1 表示该项测试中 RustFS 领先，小于 1 表示 AIStor 领先。 2.85 倍表示约高出 185%，不是“提升 285%”。原表未明确标注绝对数值的计量单位，因此这里仅引用比值。

GET 的完整结果中，RustFS 在 1KiB～16KiB 各档小幅领先，在 32KiB、100KiB 和 1MiB 三档落后，在 4MiB 及以上测试档位再次领先。其中 1MiB 读取的 AIStor 原始数值约为 RustFS 的 4.4 倍，不能只看写入优势而略过这个差距。

这份报告说明，当时的 RustFS 写入表现值得关注，读取表现则明显受对象尺寸影响。由于测试由项目方提供，且使用的是 Beta 版本，这些结果更适合作为 GA 复测的参考，而非所有业务都会更快的依据。

备份、归档场景应同时测写入与恢复读取；图片服务和训练数据场景应重视 GET、混合负载及尾延迟。AI 训练并不天然“写多读少”，数据准备和训练读取要分开看。对象分布、缓存、并发、纠删码参数和网络条件，都应尽量贴近实际业务。

五、纠删码与迁移：数据可靠性要讲清楚

1. “12+4”有明确前提

看完读写性能，还要考虑磁盘故障后能否恢复数据，这就涉及纠删码。RustFS 将对象拆成数据分片，并计算校验分片，再把这些分片分散存放到同一纠删码集合的磁盘上。按官方 纠删码配置文档，默认校验分片数取决于每个集合的磁盘数：例如 4～5 盘集合默认有 2 个校验分片，8～16 盘集合默认有 4 个。

以 16 盘组成一个集合、采用 EC:4 为例，对应的就是“12 个数据分片 + 4 个校验分片”。在其余分片完整的前提下，可恢复最多 4 个缺失分片，理论数据容量占比为 12/16，即 75%。实际容量还要扣除文件系统和元数据开销，并预留修复空间。

如果这 16 块盘均匀分布在 4 台服务器上，一台离线就会失去 4 个分片。换一种分布，节点容错能力也会变化；能否继续读写，还取决于对应的 quorum，也就是读写所需的最少在线分片数。

单节点单磁盘没有 RustFS 层面的磁盘冗余；单节点多磁盘仍面临整机故障风险。需要节点级容错时，应规划多节点部署，并演练故障和恢复。纠删码不能替代独立备份。

2. 原地迁移有方案，加密对象尤其要注意

RustFS 在 2026 年 3 月发布过二进制替换迁移方案，示例使用的是 1.0.0-alpha.89，并列出站点复制、事件通知、在线配置和 LDAP/OIDC 等不能自动迁移的项目。这只能说明当时已有迁移路线，不能直接当作 1.0.0 的完整支持承诺。

更关键的是，1.0.0 默认发布构建不能直接读取 MinIO 的服务端加密对象，包括 SSE-S3、SSE-KMS 和 SSE-C。 对象能够列出、显示大小，不代表内容能够解密读取。特定迁移构建有额外支持，但也受源端密钥方案限制，详见 1.0.0 数据格式兼容说明。

因此，原地迁移前要核对源版本、目标版本、加密方式、历史版本和权限配置。完成备份后，先在副本上演练，再停止旧服务并切换。

另一条路线是通过源端 S3 接口读取数据，复制到新集群；加密对象由源端解密、目标端按需重新加密。普通复制未必保留全部历史版本、锁定信息和管理配置，切换前还需停止或控制源端写入，完成最后的增量同步与核验。

接口兼容、磁盘格式兼容和管理配置兼容是三件事。回退方案同样需要验证，不能默认 RustFS 写入的数据还能由 MinIO 直接读取。

六、动手验证：1Panel 与 Docker 两种方式

明确了功能和迁移边界，就可以搭建测试实例了。下面以 Ubuntu 云服务器为例，介绍两种安装方式，任选一种即可。先验证建桶、上传、下载和客户端连接，生产集群的容错与恢复还需另行验收。

方式一：通过 1Panel 应用商店安装

已有 1Panel 的读者可以直接进入应用商店。尚未安装时，可按 1Panel v2 安装文档 下载并执行脚本：

curl -fSL https://resource.fit2cloud.com/1panel/package/v2/quick_start.sh -o quick_start.sh
sudo bash quick_start.sh

使用阿里云 ECS 时，也可以查看系统运维管理 OOS 的公共扩展程序。下图展示了 1Panel 安装入口，安装前确认扩展程序版本和适用系统即可。

在应用商店搜索 RustFS，按当前模板设置管理员凭证、端口和数据目录。官方商店条目支持 amd64、arm64；latest 镜像会随时间变化，安装前应确认实际版本。

默认情况下，9000 是 S3 API，9001 是控制台。通过可信网络访问 http://服务器IP:9001，使用设置的凭证登录；如果修改了映射端口，就使用修改后的地址。

如果容器反复重启，日志出现 Permission denied，应检查挂载目录权限。1.0.0 官方镜像以 UID/GID 10001:10001 运行，但其他镜像或面板模板可能覆盖用户设置。应先确认实际运行用户，再调整专用数据目录的属主，不要直接照搬旧教程里的 1000。

面板底层也是容器部署，排查时仍要回到镜像版本、运行用户和挂载配置，不能简单记成“1Panel 用 1000，Docker 用 10001”。

方式二：使用 Docker 部署

以下命令依据 RustFS Docker 文档 整理，镜像固定为 1.0.0。准备好 Docker Engine（文档要求至少 20.10），确认 9000、9001 端口未被占用。

先拉取镜像并创建持久化数据卷：

docker pull rustfs/rustfs:1.0.0
docker volume create rustfs-data

将两个凭证占位符替换为自己的值后再执行：

docker run -d \
  --name rustfs \
  --restart unless-stopped \
  -p 127.0.0.1:9000:9000 \
  -p 127.0.0.1:9001:9001 \
  -v rustfs-data:/data \
  -e RUSTFS_ACCESS_KEY='<your-access-key>' \
  -e RUSTFS_SECRET_KEY='<your-secret-key>' \
  -e RUSTFS_ADDRESS=':9000' \
  -e RUSTFS_CONSOLE_ADDRESS=':9001' \
  -e RUSTFS_CONSOLE_ENABLE=true \
  rustfs/rustfs:1.0.0 \
  /data

镜像名后的 /data 是数据目录参数。这里将端口绑定到服务器本机，云服务器用户可在自己的电脑上建立 SSH 转发；先替换用户名、服务器地址，并确认本地端口可用：

ssh -N -o ExitOnForwardFailure=yes \
  -L 9000:127.0.0.1:9000 \
  -L 9001:127.0.0.1:9001 \
  <ssh-user>@<server-ip>

保持连接，在电脑浏览器打开 http://127.0.0.1:9001；本地客户端通过 http://127.0.0.1:9000 连接 S3 API。需要长期远程访问时，再配置 HTTPS 和访问范围。

如果改用主机目录挂载，可以先创建供本实例使用的目录：

sudo install -d -o 10001 -g 10001 -m 0750 /srv/rustfs-data

然后把 -v rustfs-data:/data 换成 -v /srv/rustfs-data:/data。已有目录还需检查内部文件权限。

在服务器上检查运行状态与健康接口：

docker ps --filter name=rustfs
curl --fail http://127.0.0.1:9000/health

最后创建一个桶，上传文件后再下载，比较前后内容是否一致，并在重启容器后确认数据仍可读取。这个示例只有一个数据卷，属于单节点单磁盘形态，不提供 RustFS 层面的磁盘冗余。

凭证配置别忽略

rustfsadmin / rustfsadmin 是公开的默认凭证，必须主动替换。1.0.0 的容器入口对缺失或默认凭证会告警，但仍可能继续启动，不能依赖它自动阻止不安全配置。

Access Key 建议使用大写字母和数字，不要直接使用可能含 / 的 Base64 字符串，否则会干扰 AWS SigV4 凭证作用域解析。Secret Key 应使用独立的强随机值；应用日常访问应使用限定权限的账号，而非管理员凭证。

多节点还涉及 RUSTFS_RPC_SECRET。未显式设置时，它由管理员凭证对派生，默认 Secret Key rustfsadmin 不能用于这条派生路径。各节点应使用一致的管理员凭证；若单独配置 RPC 密钥，应使用与管理员 Secret Key 不同的强随机值，并在所有节点保持一致。

七、我的判断：值得评估，是否替换要看验证结果

RustFS 1.0.0 已经值得进入 MinIO 替代方案的候选名单。宽松许可便于商业集成，S3 接口有助于接入现有应用，集成式 Iceberg Catalog 则为数据分析场景提供了新的选择。

真正决定能否替换的，还是三件事：现有应用能否正常工作，故障后能否按预期恢复，迁移与维护成本能否接受。对已经使用 MinIO 的团队，尤其要先清点加密对象、版本控制、权限和复制规则；对新项目，则可以从非关键数据开始验证。

GA 是一个正式的生产版本起点。把兼容性、业务负载和恢复流程测清楚，再决定替换范围，比单看语言、版本号或一张跑分表更可靠。

我是程序员天天困，持续分享编程干货。觉得有用的话，欢迎点赞、收藏和关注。你现在用的是什么对象存储？如果考虑换成 RustFS，最想先验证哪项能力？