迁出S3深度归档前，先分清原对象与临时恢复副本

准备把一批归档文件迁出时，看到控制台出现“恢复”入口，不宜把它理解为原对象已经永久转到普通存储。迁移清单中的对象身份、读取状态和恢复副本有效期，需要分别记录，否则任务可能在副本到期后仍显示“已恢复可下载”。

AWS文档说明，S3 Glacier Deep Archive对象不能实时读取，需要发起恢复并等待临时副本可用。临时副本生成后，原对象的存储类别仍保持不变；副本只在指定期限内保留，到期后被删除。文档同时提示，归档对象和临时恢复副本都会产生相应存储费用。[1] 本文不据此估算具体账单金额。

将“已请求”和“可读取”分开

恢复请求发出，只是流程开始，不代表内容已经可以复制。迁移任务可以分别记录请求时间、实际完成状态和准备读取的对象版本，并在真正读取后留下结果。没有完成通知或状态核验，就不应把整个批次直接标成可迁移。

有效期应跟着副本走

原始归档对象仍在，临时副本却有期限。对迁移协调人员来说，需要知道的是哪个副本何时可用、何时到期，以及任务是否在其有效期间完成。若计划调整，不能仅凭最初请求表推定副本仍有效，应由负责存储操作的人核对实际状态。本文不提供生产批量恢复、删除或改类命令。

费用清单按事件拆开

只比较目标存储单价，无法描述整个迁移过程。至少应将原有存储、临时恢复副本及相关取回或传输等待核对项目分别列出，再由负责账单的人依据实际地区、对象和操作方式核实。AWS存储类别介绍也提醒归档类别涉及最低存储期间与取回费用。[2] 这里提供的是费用项目识别，不是投资、采购或财务决策建议。

不要混用相似的归档名称

AWS在同一文档中特别区分Glacier相关类别与Intelligent-Tiering的归档访问层：后者的恢复行为是回到Frequent Access层，与前者的临时副本机制不同。[1] 因此，清单中保留完整存储类别或层级名称很有必要，不能只用“冷数据”两个字覆盖所有对象。

迁移完成也需要独立证据

临时副本可读，并不等于目标端已经接收完整。迁移记录应继续区分读取、目标写入和核验结果，缺少哪一步就写明哪一步。本文没有访问任何用户存储，也不声称归档文件已经迁出；它帮助团队把准备阶段的状态与证据整理清楚。

参考来源：[1] AWS，Working with archived objects；[2] Understanding and managing Amazon S3 storage classes。两页本次核对未见明确发布日期，费率与具体适用条件需另行核对。