MinIO 是過去五年自架 S3 相容儲存的預設答案——文件齊全、社群夠大、部署一支二進位就能跑，幾乎所有 Ceph 撐不起的小型場景都會回頭選它。這個地位在 2026 年 2 月斷了。MinIO 官方在 2026-02-13 把開源版 GitHub repo 標為 archived，同一天內留下 6 個未修的 CVE，之後所有安全性更新只推商業版。用 RustFS 這種 Rust 重寫、drop-in 相容的方案接手變成短期內最務實的路線——它 4 月釋出 Beta，可以直接掛 MinIO 原本的資料目錄啟動，物件、metadata、IAM 設定都不用搬。
同一時間 Garage、SeaweedFS 也在承接 MinIO 的用戶，但這三個方案的技術定位其實不太一樣。RustFS 的差異在於它是唯一一個把「二進位換掉就能繼續跑」列為 Day 1 設計目標的專案——這件事在遷移壓力大的環境下比純粹的效能數字重要。
開源版被 archive 這件事有多重
MinIO 的商業策略轉向不是新聞——2024 年開始把 Console UI 從 OSS 拉走、2025 年拿掉 mc client 的部分商業功能——但 2026 年 2 月直接把 repo archive 是質變。Archive 之後 repo 進入 read-only，不接 PR、不接 issue、不再打 tag。留在最後 commit 上的 6 個 CVE 涵蓋認證繞過、bucket policy 解析、SSE-KMS 幾條路徑，這些漏洞對正在 production 跑 MinIO 的人而言是連續性的風險。
商業版繼續維護、也繼續收 CVE fix，但授權從 AGPL v3 轉成需要商業合約，且商業版跟開源版的 wire protocol 在最近版本已經有差異——想「先用 OSS、之後有預算再升商業版」的路徑事實上被切斷。任何跑在 MinIO OSS 上的環境現在都得選邊：付錢升商業版、或是找一個 API 相容的自架方案接手。
Fork MinIO OSS 本身在技術上可行，但 AGPL 的義務加上 Console 從 OSS 剝離的歷史包袱，讓從頭寫一個純 Apache 2.0 的相容實作在維護成本上其實比 fork 划算。這是 RustFS 團隊給出的判斷，也是它從 2024 年開始寫的動機。
RustFS 為什麼選 Rust 從頭寫
MinIO 是 Go 寫的，效能瓶頸主要在 GC 觸發時的尾延遲——在物件小、請求密集（4KB 級別的 metadata 讀寫、AI 訓練資料 loader）情境下 GC pause 直接反映在 p99。RustFS 用 Rust 重寫、走無 GC 路線，官方 benchmark 在 4KB 物件上跑到 MinIO 的 2.3 倍吞吐量。這個差距在大物件（512KB 以上）會收斂到 10~15%，因為那個層級的瓶頸落回磁碟頻寬。
實務上，2.3 倍的優勢主要對兩類工作負載有意義：AI 訓練資料集裡大量小 tensor 分片、以及背後接 Iceberg、Delta Lake 這類 lakehouse 格式的 metadata 檔。純備份、影音存檔這類寫入模式差異很有限，改用 RustFS 的動機主要落在「持續有 CVE 修補」而不是效能。
架構上 RustFS 把 S3 API layer、物件放置邏輯、儲存層明確拆開，S3 前端用 axum 起 HTTP，物件層做 erasure coding 跟一致性檢查，儲存層直接跟本地 XFS/ext4 對接。這個分層跟 MinIO 的 monolith 相比更容易在中間插入額外功能——比如 KMS、外部 metadata 快取——但 alpha 到 beta 這段時間也代表這些介面還可能變動。
Reed-Solomon 這一層跟 MinIO 幾乎一致
Erasure coding 是自架 S3 儲存能不能省成本的關鍵。三副本模式儲存效率固定 33%，Reed-Solomon 在 k+m 配置下可以推到 50~80%，同時容忍 m 個節點同時掛。RustFS 用的是 Vandermonde 矩陣變體的 Reed-Solomon 實作，跟 MinIO 走同一條路——原因很單純，Vandermonde 矩陣的解碼運算能靠 SIMD 加速，Cauchy 矩陣在小資料塊上編碼快但解碼吃 CPU 更兇。
預設策略是 RS(10,4)：10 個資料分片加 4 個校驗分片，總共 14 個節點分布，儲存效率 71%，可以同時掛 4 個節點。這個配置在小型自架叢集（8 到 12 顆磁碟）上會退化成 RS(4,2) 或 RS(6,2)，RustFS 會根據啟動時看到的磁碟數自動選擇，跟 MinIO 一樣。
值得提醒的是，erasure coding 對磁碟 IOPS 的敏感度比純副本高——每一次寫入都會觸發多個磁碟的併發寫，讀取則要重組多個分片。用 HDD 撐 erasure coding 在小物件密集寫入時延遲會爛掉，NVMe SSD 或至少 SATA SSD 是實際跑起來的基本條件。這一點跟原生 MinIO 沒差，遷移前配置在什麼硬體上、遷移後就繼續維持。
遷移這一步到底能省多少事
RustFS 相對其他 MinIO 替代方案最強的一點是它接受 MinIO 原本的資料目錄格式。實務流程是把 MinIO 停掉、把 rustfs 二進位放進去、用相同的 volume 路徑跟認證環境變數啟動，物件就出來了。這件事在 Garage、SeaweedFS 都做不到——那兩個需要走 mc mirror 或 rclone 把資料整份複製過去，對 TB 級叢集是幾小時到幾天的停機。
實際能無縫接手的範圍包括：bucket metadata、物件（含 tag、object lock、版本控制）、bucket 複製設定、IAM 設定、生命週期規則、多層儲存策略。不能直接接手的部分列出來就三塊：Site replication（跨區複製狀態）、Event notifications（webhook、MQ 觸發設定）、以及 LDAP 跟 OIDC 認證——這三個要在 RustFS 端重新設定，其他的都是掛上就跑。
Docker 環境改動也很小：把 image 從 minio/minio 換成 rustfs/rustfs:1.0.0-beta（beta 版本後綴會跟版號一起走），環境變數從 MINIO_ROOT_USER 這類前綴改成 RUSTFS_ROOT_USER，volume mount 路徑不變。Compose 檔改動大概 5 行。
實務上建議的流程是：先在 staging 環境把資料目錄 rsync 一份出來、掛 RustFS 起，跑一輪讀寫測試跟 IAM 檢查、確認 SDK 相容性沒問題（AWS SDK、Boto3、s3cmd 全支援），再排 production 的停機時間。停機視窗抓 15 分鐘綽綽有餘，實際切換動作可能不到 3 分鐘。
分散式模式現在能不能上 production
這是 RustFS 目前最敏感的問題。單節點模式在 alpha 88 之後已經算穩定，跑小型自架 S3、Iceberg backend、備份儲存都合理。但分散式模式（多節點叢集、跨節點 erasure coding、節點失效自癒）在 Beta 階段仍然掛著 testing 的標籤——官方文件在 2026 年 5 月的更新裡明確寫「distributed cluster mode is under active testing, not recommended for critical production deployments yet」。
這個限制對從 MinIO 遷移的用戶影響分兩塊：如果原本跑的是 MinIO 單節點多磁碟模式（single-node multi-drive），RustFS 現在就能無縫接手；如果原本是 MinIO 分散式模式（multi-node multi-drive），保守做法是等 RustFS 1.0 GA 之後再遷，或者暫時降到單節點模式配合外部備份策略。
分散式模式落後單節點模式一段時間是這類專案的常態——單節點的邊界情境數量遠少於分散式的節點協商、split brain、跨節點一致性。RustFS 團隊給出的 1.0 GA 時間點落在 2026 年下半年，跟其他相容專案的成熟度時程差不多。
RustFS、Garage、SeaweedFS 該選哪一個
三個都是 MinIO archive 之後的實際選項，但用途分得很清楚。
RustFS 是唯一能直接接手 MinIO 資料目錄的方案。適合場景：已經跑 MinIO 的環境需要保持 API 跟資料格式相容、想繼續拿 CVE 更新、單節點或未來會升成分散式（等 GA）。跟 MinIO 幾乎是 1:1 對應。
Garage 走的路線完全不同——geo-distributed 設計，跨區複製是 Day 1 一等公民、不是外掛。適合場景：多資料中心、跨區同步儲存、備份跟主資料在不同地理位置。單機或單機房效能不如 RustFS，但地理層級的可用性是它獨有的。
SeaweedFS 定位更偏「大量小檔案」——照片、影音縮圖、日誌片段這類百萬到億等級小物件。它的 volume server 架構對小檔案 metadata 開銷比 Reed-Solomon 系列低，但 S3 API 相容度歷史上比 MinIO/RustFS 差一截，某些 SDK 呼叫會踩雷。
一個實務判斷：從 MinIO 遷過來、不改架構、想繼續享受同一套 SDK 生態，RustFS 是最短路徑；跨資料中心設計、單機房不是重點，選 Garage；小檔案是核心工作負載、S3 相容度可以妥協，選 SeaweedFS。
什麼時候該遷、什麼時候該等
RustFS beta 現階段的判斷點很清楚。已經在 MinIO OSS 上跑 production 且要修 CVE 的環境應該現在就規劃遷移，畢竟原上游沒人在修了，繼續拖只是把風險累積下去。單節點模式的用戶可以直接動、分散式模式的用戶建議等 1.0 GA 或先降回單節點加外部備份策略。
新起的自架 S3 環境同樣可以直接選 RustFS——單節點跑穩定、Beta 期間也有主動維護、Apache 2.0 授權比商業版 MinIO 或 fork MinIO 都乾淨。要注意的是 Site replication、Event notifications、LDAP/OIDC 這幾個功能得等 GA 之後再上，短期內用 external tooling（rclone、Vault、Authentik）繞開。
對於在 VPS 上跑自架物件儲存的場景，RustFS 對硬體條件的實際要求跟 MinIO 一樣：NVMe SSD 撐 IOPS、每個節點至少 4 顆磁碟（單節點模式下也是這樣）、記憶體 4GB 起跳應對 Rust 的物件層快取。這幾個門檻在中等規格 VPS 上都容易達到，不需要走專用儲存機的路線。
NCSE Network 在臺灣是方電訊機房提供的 VPS 主機採用 Intel Xeon Gold CPU 與 NVMe SSD，單節點物件儲存的 IOPS 需求跟本地低延遲線路都能穩定覆蓋，對於想自架 S3 相容儲存做 backup、Iceberg backend、或 AI 訓練資料集的場景是實際可行的底層。詳細規格與方案請參考 ncse.tw。
