将经典Azure Storage账户迁移至ARM：迁移时长及密钥变更咨询

一、750GB数据迁移时长参考 #

我之前处理过几次类似规模的生产环境Azure存储迁移（仅包含blobs、tables、queues，无VM关联），用Portal的Storage Blade工具的话，时长可以拆成两个关键阶段来看：

• 预同步阶段（无停机）：这部分是后台异步同步大部分存量数据，速度主要取决于存储账户的性能层级（Standard vs Premium）和数据类型：
  • 块Blob的同步速度大概在每小时100-200GB左右（Azure内部跨区域/跨订阅复制的带宽通常能跑满存储账户的默认配额）；
  • Tables和Queues的数据量如果占比较小（比如总750GB里只有几十GB），同步速度会更快，因为这类数据的单位体积同步开销更低。
    以750GB主要是块Blob的情况为例，预同步大概需要4-8小时，这个阶段完全不影响生产读写。
• 停机切换阶段：当预同步完成后，需要暂停生产读写，同步最后增量数据并完成切换。这个阶段的耗时取决于增量数据的多少，我之前迁移600GB的存储账户时，最后增量只有30GB左右，切换+验证只用了40分钟。如果你的增量数据不多，完全可以控制在你能接受的1-2小时停机窗口内。

二、迁移后存储密钥与应用配置的注意事项 #

• 迁移完成后，目标存储账户的访问密钥是全新的，和源账户完全不同，源账户的密钥不会同步到目标账户。
• 你必须更新所有应用设置、配置文件中引用的源存储账户连接字符串（或单独的存储密钥），替换为目标账户的对应信息。除此之外，还要排查以下容易遗漏的引用点：
  • 第三方集成服务（比如ETL工具、监控告警系统）；
  • 内部脚本、备份工具；
  • 前端应用的配置（如果有直接调用存储服务的场景）。
• 建议在停机切换前，先把所有配置准备好，切换完成后立即更新并验证应用连通性，避免业务中断时间延长。

额外小提示 #

• 迁移前建议用小批量数据做一次测试迁移，熟悉流程并预估自己环境下的实际速度；
• 迁移过程中可以在Portal的迁移进度页面实时监控同步状态；
• 确保目标存储账户的性能层级、冗余策略和源账户一致，避免迁移后出现性能或可用性问题。

内容的提问来源于stack exchange，提问作者Simon