MinIO 进入维护模式RustFS 的机会窗口已经打开【免费下载链接】rustfsRustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfs自建 S3 的世界里刚刚失去它最顺理成章的答案。从 2025 年 6 月官方一次更新删掉约 11 万行代码、顺手抹掉 Web 管理界面到 2025 年 12 月初 MinIO 在 GitHub 仓库 README 里写下「维护模式代码库处于仅维护状态不接受任何新功能、改进或拉取请求」再到 2026 年 2 月官方仓库被归档以及 2026 年 9 月连累计超过 10 亿次拉取的minio/minioDocker 镜像也被整体删除、Docker Hub 上只剩 404——这条时间线里最后保留的完整可部署版本停留在RELEASE.2025-04-22T22-12-26Z此后的安全修复只能「视情况评估」。对一个承载生产数据的存储系统来说「一年多没有正常维护 旧镜像不敢再用」几乎是教科书式的迁移触发条件。而窗口期的另一侧RustFS——一个用 Rust 编写的 S3 兼容分布式对象存储——正处在近 2 万 Star 的上升期仓库里最显眼的模块恰好是为「从 MinIO 迁走」这件事准备的。本文基于 RustFS 当前代码仓库的真实结构、契约文档与测试清单把三件事讲清楚MinIO 维护模式的真实状态、替代者阵营里 RustFS 凭什么排在第一、以及迁移窗口期的现实阻力到底在哪。一、MinIO 维护模式到底砍到了什么程度先厘清事实边界避免把「社区讨论」当成「官方行为」。综合 2025 年 12 月至 2026 年 9 月的多家媒体与社区跟踪报道MinIO 开源侧的收缩是渐进式、四连击的时间事件2025-06一次官方更新删除约 11 万行代码社区版 Web 管理控制台被移除2025-12仓库 README 声明进入 Maintenance Mode不接受新功能、改进与 PRIssue 不再主动审查社区支持转为 Slack 上的 best-effort2026-02官方仓库归档archived不再维护2026-09官方 Docker Hub 镜像minio/minio被整体删除最后版本停留在RELEASE.2025-04-22T22-12-26Z把这几件事串起来看信号比任何单一条都强功能演进停止、代码库冻结、分发渠道拆除。对存量用户而言风险不再只是「没有新功能」而是安全修复渠道从「承诺」退化成「个案评估」——在 AI 加速漏洞挖掘的当下一个冻结超过一年的对象存储镜像本身就是一条合规负债。更深层的背景是 2018 年的许可证风波。MinIO 当年从 Apache 2.0 切换到 AGPLv3把「自建 S3 首选」的一大批用户推到了需要法务评审的位置AGPL 的网络交互条款对 SaaS 形态的二次分发有传染风险这正是企业采购和云厂商选型时最敏感的「许可证陷阱」问题。此后社区一直需要一个「Apache 2.0 S3 兼容 分布式纠删码」的完整替代而 RustFS 的 README 第一屏就把这一点写成了产品定位Unlike other storage systems, RustFS is released under the permissible Apache 2.0 license, avoiding the restrictions of AGPL.仓库根目录的 LICENSE 全文即 Apache License 2.0没有任何附加条款。对一个把「无许可证风险」当卖点的存储系统这一页文件本身就是最硬的证据。二、替代者盘点RustFS 为什么排第一维护模式宣布后社区迅速整理出替代品名单CephRADOS GatewayLGPL成熟但重、SeaweedFSApache 2.0擅长海量小文件、GarageRust、轻量但 AGPL、OpenStack Swift s3api适合既有 OpenStack 环境、VersityGW文件系统网关以及一批新项目如 MaxIOFS、liteio 等。RustFS 在 2026 年 9 月更新的社区盘点中被单独标注为「目前最值得关注的 MinIO 直接替代品之一」而此前「弃用 MinIO拥抱 RustFS」一类的迁移向文章在中文技术社区已连续数月出现——热度本身不是论据但值得追问它为什么是 RustFS。结合仓库源码RustFS 与这个名单上所有对手的差异点有三个且都能落到代码1. 定位是「MinIO 的直接继任者」而不是「又一个 S3」。README.md 的自我描述是「combines the simplicity of MinIO with the memory safety and raw performance of Rust」并且功能矩阵与 MinIO 逐项对齐版本控制、Object LockWORM、SSE 三类加密、生命周期管理ILM与远端 S3 分层、桶复制、站点复制Site Replication、桶配额、事件通知、审计日志、Web 控制台、Helm Chart此外还多出 OpenStack Swift 协议、Keystone 认证、SFTP/FTPS/WebDAV、Iceberg REST CatalogS3 Tables Preview等 MinIO 没有的协议面。2. 工程形态是面向高并发热路径的系统不是拼装出来的兼容层。仓库是一个 60 crate 的 Cargo workspaceARCHITECTURE.md 给出的请求链路是严格单向分层的HTTP request → server (TLS, auth, routing, compression) → app/object_usecase (validation, policy, lifecycle) → storage/ecfs (erasure coding, encryption, checksums) → ecstore (disk pool selection, data distribution) → rio (reader pipeline: encrypt → compress → hash → write) → io-core (buffer pool, storage profiling, admission control) → local disk / remote disk via RPC纠删码引擎在 crates/ecstore/279 个源文件读者 I/O 管线在 crates/rio/加密→压缩→哈希→写盘的单遍 reader 链缓冲池与准入控制在 crates/io-core/。仓库甚至用 scripts/check_layer_dependencies.sh、scripts/check_architecture_migration_rules.sh 这类 CI 守卫脚本把「层与层之间不许反向依赖」固化成提交门禁。这种工程纪律在同类开源对象存储里很少见也是它敢于在 changelog 里逐条写下 KMS 失败分类、锁 RPC 超时风暴防护这类细节的原因。3. 最关键的一点它把 MinIO 的磁盘格式当作一等公民对待。这是整个替代者名单里几乎没有第二个做到的事后文第三节详述。三、迁移窗口拉取式迁移让「不停机换库」成为可能对象存储迁移的传统姿势是rclone/mc mirror全量拷贝 停写窗口大集群上动辄数周。RustFS 的 On-Demand MigrationODM 模块把这个问题换了一个解法把源桶「挂」过来读到哪搬哪。ODM 将外部 S3 兼容源桶MinIO、AWS、R2、GCS、Azure 等 provider绑定到一个本地桶。客户端 GET 一个本地不存在的 key 时RustFS 从源拉取、流式回给客户端、同时落盘本地——同一次读取完成迁移之后的所有读取全部本地化。模块默认开启可用RUSTFS_ON_DEMAND_MIGRATION_ENABLEDfalse全局关闭实现位于 rustfs/src/on_demand_migration/核心文件分工明确文件职责config.rs每桶配置模型与参数边界阈值、并发、带宽、TTLsource_client.rs出站源客户端多 providerpull.rs拉取写回管线breaker.rs/negative_cache.rs每源熔断器 / 每 key 负缓存backfill.rs后台全量回填任务带可恢复 checkpoint配置走 Admin API且强制先dry-run探测源再落盘——这是很典型的「迁移是高风险操作」的工程态度# 1. dry-run验证源可达HeadBucket 可列举一次 ListObjectsV2不保存 awscurl --service s3 --region us-east-1 \ --access_key $AK --secret_key $SK \ --request PUT --header Content-Type: application/json \ --data $(cat /tmp/odm.json) \ http://host:9000/rustfs/admin/v3/on-demand-migration/photos?dry-runtrue # 2. 去掉 dry-run 保存配置集群内元数据自动刷新 # 3. GET .../status 查看每节点的熔断器、队列深度、拉取计数响应头x-rustfs-on-demand-migration: source会标记每一个来自源桶的响应配合rustfs_on_demand_migration_*指标拉取字节数、失败数、熔断状态、延迟分位迁移进度是可观测的而不是黑箱等待。防循环回源anti-loop marker、单 key 单飞singleflight、有界拉取队列、可选带宽限制这些生产级保护都写在模块文档里而不是 PPT 里。而迁移之所以「敢在原地切换」底层还有一块很少被宣传的基石RustFS 与 MinIO 的纠删码在字节层面同源。docs/architecture/erasure-coding.md 是仓库中标注为 normative规范级的契约文档其中写明RustFS 采用与 MinIO 完全同族的GF(2⁸) 上的 Reed–Solomon、Vandermonde 生成矩阵、算法标识rs-vandermonde、1 MiB 纠删块、HighwayHash-256 bitrot 校验——「这正是与 MinIO 实现字节级xl.meta互操作的可能」。docs/architecture/minio-file-format-compat.md 则把互操作能力拆成了带代码出处的矩阵未加密的xl.metameta_ver 1–3含 inline、multipart、versioned、delete marker可读重写时归一化到 meta_ver 3.metadata.bin桶配置msgpack字段名与 MinIO 的bucketMetadata一一映射可读并导入config/iam/下的 IAM 配置导入且归一化遗留字段别名导入器是单向幂等的实现在 crates/ecstore/src/bucket/migration.rs 的try_migrate_bucket_metadata/try_migrate_iam_config由 rustfs/src/startup_bucket_metadata.rs 在启动时执行从.minio.sys布局迁到.rustfs.sys。也就是说RustFS 给出的迁移路径不是「重新拷一份数据」而是「同一块纠删码分片换一套读它的运行时」——对已有 MinIO 卷这意味着磁盘格式层的迁移成本趋近于零网络层只剩元数据与可选的对象拉取。兼容性广度方面仓库没有用「全兼容」这种模糊说法而是直接跑 s3tests 并维护四份测试清单docs/architecture/s3-compatibility-matrix.mdimplemented_tests.txt556 例、unimplemented_tests.txt37 例、excluded_tests.txt317 例厂商专有行为、lifecycle_behavior_tests.txt53 例。556 对 37且「尚未通过」项被明确列出——这种「把边界写在明处」的兼容矩阵比任何兼容性宣传都更有工程说服力。四、窗口期的冷水阻力是真实存在的严谨地讲这个「机会窗口」不等于「免费通道」。仓库自己的文档把迁移的边界标得非常清楚任何基于 RustFS 做迁移决策的团队都应当把以下几点纳入方案1. MinIO SSE 对象是最大的硬骨头。按 minio-file-format-compat.md 的 Part CSSE-S3 / SSE-KMS / SSE-C 对象在默认构建下是fail closed拒绝读取并给出诊断需要用rio-v2feature 构建的迁移二进制cargo build时启用不在 default/full 构建内且要求持有源 MinIO 的静态主密钥RUSTFS_SSE_S3_MASTER_KEY与源端一致而凡是由外部 KES / KMS 插件 / MinKMS 密封 DEK 的对象明确不在支持计划内只能先在 MinIO 侧解密或重加密。crates/rio-v2/ 的 reader 专门补齐了 MinIO 的 sealed-key 槽位解码decrypt_minio_kms_data_key同时兼容sealed‖iv‖nonce与旧版 JSON 两种封包形态。换句话说明文与静态密钥加密的对象可以近乎零成本迁移托管 KMS 加密的对象需要额外工程。2. 迁移是单向的。同一份契约文档明确「RustFS 写入的卷MinIO 二进制无法回读」MinIO 找.minio.sysRustFS 写.rustfs.sys反向的 SSE 对象同样不支持。切过去就是单行道——这本身是合理的架构决策避免双写脑裂但意味着回滚方案必须建立在「源桶保留」上ODM 文档的升级/回滚章节为此专门写了 rc.5 混合版本的坑旧版本节点写桶元数据会丢弃 ODM 配置字段且不可恢复因此必须全节点升级后再启用 ODM。3. S3 兼容不是 100%且差距是可见的。37 个 unimplemented 用例里有桶访问日志、POST Object 表单上传的校验和处理等站点复制Site Replication也明确要求对端是 RustFS 兼容的 Admin API通用 S3 服务只能作为桶复制的数据目标。对于依赖这些边角行为的存量集成需要先过一遍 scripts/s3-tests/ 的清单。4. 单节点单盘形态不能原地扩展。README 的 Pool expansion notice 沿用了 MinIO 的拓扑规则SNSD单机单盘只能作为独立本地路径存在升级多盘需要新建部署 S3 层迁移。这是从 MinIO 迁移时最需要提前规划的容量/拓扑项。五、接棒能力窗口期考验的是「持续交付」机会窗口对谁打开最终取决于谁能持续接住。评估一个存储系统的社区接棒能力不看 Star 曲线看三样东西修复节奏、测试覆盖、文档与运维资产。修复节奏。当前 CHANGELOG.md 的 Unreleased 部分密度相当高两条 GHSA 级别的 SigV4 签名头漏洞修复未签名x-amz-*头可导致预签名 PUT 被升级为 CopyObject / 任意属性注入、站点复制中断恢复的 30 秒有界重试排空 600 秒全量对账、锁 RPC 超时风暴的驱逐限流新增rustfs_remote_lock_*指标族、KMS 失败从一律 500 拆分为 400/403/401 之外的完整状态分类、多池异构拓扑下逐池解析纠删 parity修复小池解析出 0 个数据分片导致 Reed-Solomon 构造 panic 的缺陷。这些不是功能 PR而是一个系统在按生产事故的速度迭代正确性——对一个「维护模式」的对手而言这是质变。测试覆盖。crates/e2e_test/ 下有 94 个端到端测试文件按主题命名到回归级别degraded_read_eof_regression_test.rs、heal_erasure_disk_rebuild_test.rs、degraded_listing_availability_test.rs、checksum_upload_test.rs……加上 556 例 s3tests 门禁、crates/e2e_test/src/distributed/ 的分布式场景、以及 scripts/s3-tests/ 里与 Ceph s3tests 用例的双目标对比工具compare_dual_targets.py兼容性主张是被 CI 持续验证的而不是文档断言。运维资产。仓库里的文档结构本身就是一种「接棒声明」docs/architecture/ 下 40 份契约文档每份都写明 Source of truth 对应的源码符号scripts/check_doc_paths.sh在每次提交时校验路径有效性docs/operations/ 下 50 份运维 runbookKMS 灾备演练、滚动重启、decommission 兼容性、锁风暴防护、分层 ILM 调试。高变更风险的纠删码/元数据改动要求对抗性评审 真实 MinIO 迁移样本的回归测试规则直接写在 docs/architecture/erasure-coding.md 的 §13。协议面与部署面。管理协议不止 S3Swift API 与 Keystone 认证原生支持SFTP/FTPS/WebDAV 通过StorageBackendtrait 复用同一套 multipart 流式上传路径S3 Tables 以 Iceberg REST Catalog 形态交付Preview。部署形态覆盖 Docker/Podman、Helmhelm/rustfs/Chart 有独立版本治理脚本、Nix Flake NixOS 模块nix/rustfs-module.nix乃至 x-cmd。容器默认以非 root 用户rustfs10001:10001运行README 连 bind mount 的属主要求都写明了。管理面则是完整的 Web 控制台9001 端口 Admin API/minio/前缀下的集群管理、IAM、指标结语MinIO 维护模式的本质是自建 S3 生态第一次出现「事实标准真空」。真空期最危险的错觉是以为迁移可以无限延期——但镜像删掉之后每一天的存量都停留在一个没有安全承诺的版本上。RustFS 给出的答案不是「换个地方存数据」而是三层递进的能力Apache 2.0 的许可证安全感、与 MinIO 同源纠删码带来的磁盘格式层零成本、以及 On-Demand Migration 提供的不停机渐进切换。阻力同样真实且已被仓库自己写明托管 KMS 加密对象、单向不可逆、37 个未通过的兼容用例、SNSD 拓扑不可扩展。对一个窗口期而言这些「诚实的边界」比「全兼容」的广告更有价值——它让迁移决策可以建立在工程评估上而不是叙事上。接下来的观察点也很明确ODM 从「模块」到「默认推荐路径」的成熟度、rio-v2迁移构建从 feature-gated 走向独立发布形态的进度以及 s3tests 未通过清单的收缩速度。这三条曲线决定 RustFS 们接过的究竟是机会还是责任。【免费下载链接】rustfsRustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考