
存储迁移的讨论通常从迁去哪开始但真正决定成败的问题在前面要不要迁、现在迁还是等等看。迁移是有成本的工程撞上窗口期的业务事故损失往往超过留在原地的风险。这里把动存储之前该过的六道检查摆出来过完再决定方向不迟。第一道把依赖面数清楚列出所有消费这个存储的东西应用的桶和 key 前缀、SDK 版本、定时任务、备份脚本、监控里的采集项。迁移项目翻车最常见的形态是漏了一个低频消费方——季度跑一次的报表任务半年后才发现数据源断了。清单里要给每个消费方标注它用了哪些 S3 特性。版本化、对象锁、服务端加密、事件通知每一项都要对照目标存储的兼容矩阵核对读矩阵要看 scope 栏别只看勾选列。有个现成的例子RustFS 的兼容文档写明 MinIO 的 SSE 加密对象在默认构建下不可读如果原集群用服务端加密存了数据迁移路径就得先解密再搬。这种信息不提前查搬家当天才知道。ETag 也在依赖清单里开着服务端加密的桶对象的 ETag 不再是内容摘要靠 ETag 做去重或完整性校验的下游逻辑迁移后会整体失灵。这类隐性依赖自己很难想全让每个消费方照着我用了哪些特性交清单比架构师凭记忆罗列靠谱。第二道数据形态决定工程量数据本身怎么搬取决于它在原地的形态。mc mirror全量加增量是通用解但有几个变量要先量清楚总数据量、对象数量级亿级小对象的列举和传输时间和大文件完全不是一个量级、带宽上限、业务能接受的追赶窗口。数据量自己算别拍脑袋对象数乘平均大小只是下限multipart 的碎片和未完成上传也占空间。家底一条命令量出来mcdumyminio/my-bucket输出末尾直接带对象计数体积和对象数一条命令都拿到除以可用带宽追赶窗口多长就有数了。别用mc ls --recursive | wc -l去数对象亿级桶上这条要把全部对象完整列举一遍网络和时间都搭进去总数看mc du的计数就够。亿级对象的列举本身就是一场持久战排窗口时把列举时间也算进去。未完成的 multipart 上传也容易漏它们是独立的碎片占真实空间。旧桶搬完后跑一轮mc rm --incomplete --force清碎片新桶要不要定期做同样的事写进例行维护清单。mirror 的边界官方文档写得很直白它只同步当前对象版本信息和标签以外的元数据都不带要搬版本历史得走桶复制或站点复制桶策略默认也不跟过去加--preserve才保留。开着版本化的桶用 mirror 搬等于只搬了最新一版旧版本历史留在原地这条要在选方案时就知道别等搬完才发现。第三道回滚路径先于切换存在切换方案里最先写的应该是回滚旧集群保留多久、切换后数据是否继续往旧集群镜像、回切是几步操作。先迁过去看看不是回滚方案。健康的切换是双向镜像一段时间、消费方分批切、旧集群保留到一个明确日期任何一环缺失都意味着回滚只剩嘴上说说。回滚步骤写成脚本和切换脚本放在同一个仓库里。双向镜像的前提不复杂mirror 是客户端行为只要新旧两边都讲标准 S3 接口就跑得起来对端没有什么专有能力要求。真正要盯的是滞后镜像天然追不实时切每一批消费方之前先核对追赶进度拿mc du的对象计数对一遍或抽查最新写入的对象在新集群能不能读到确认追平再切流量。切换前还要拿真实业务做一轮读写校验业务的关键路径在新集群上跑得通读回的数据对得上。拷贝完成和业务可用是两回事中间这道冒烟不能省。第四道凭据和权限重建目标集群的凭据体系要在切换前建完root 凭据只做管理业务用 IAM 用户按桶授权自动化用独立 service account。旧集群的 IAM 用户和桶策略清单先导出一份按目标集群的模型重排好别等切换当晚现想。有两个容易漏的点一是多节点部署的节点间认证变量比如 RustFS 的RUSTFS_RPC_SECRET要在首日就显式写死事后补要滚动重启二是旧集群的 ACL 和桶策略不会自动翻译过来逐桶核对一遍再放流量。ACL 能不用就不用各家 S3 实现对它的支持参差不齐权限尽量用桶策略和 IAM 表达梳理出来的 ACL 规则在迁移时直接换算成目标端的桶策略比原样照搬稳。第五道监控和告警从零重建存储换了监控栈的所有仪表盘、告警规则、值班手册都作废重做。好消息是这层有现成的起点RustFS 的遥测走 OTLP接一层 Collector 就进 Prometheus官方还带了仪表盘和告警规则做底子读者自己的环境多半已有 Prometheus/Grafana要做的不是重建一套是把存储指标并进现有面板。告警阈值照抄旧集群的数字没有意义按新集群的容量和负载重标定。值班手册也要重写换盘步骤、扩容入口、日志在哪看、紧急联系方式指向谁这些内容跟着产品走旧手册的页面引用全部失效。演练一次故障注入停一个进程、打满一块盘新手册才算验证过。第六道不做也可以但要写下来最后这道检查反着问留在原地行不行把不迁的理由也写下来现有版本的安全支持到什么时候、许可条款对使用方式有没有约束、业务增长会不会撞到现有架构的天花板。如果答案都是目前没有压力那就明确一个复查日期把暂时不迁从一个默认状态变成一个决策。这六道里第一、三、六道决定要不要动第二、四、五道决定怎么动。全过完是绿灯迁移才排期任何一道是红灯要么补齐条件要么把不迁写成正式决策。存储这东西最贵的状态是既没想清楚要不要迁又已经开始迁了。复查日期写进日历到期把六道重新过一遍情况变了决策跟着变。触发条件可以比日历更敏感原厂发重大安全公告、许可条款变更、容量用到七成、或者业务侧冒出新的存储需求任何一件发生就提前复查不必等到日期。六道检查里反复出现的兼容矩阵入口在官方文档的 S3 兼容页每一项都带 scope 说明别只看勾选列RustFS 1.0.0 于 2026 年 9 月 16 日发布源码在 GitHub 的 rustfs/rustfs 仓库。