★ FEATURED ARTICLE 一提到 AWS S3 Glacier 数据恢复可能有人以为和硬盘、U盘、手机的数据恢复是一回事其实完全两码事。Glacier 是 AWS 对象存储 S3 的归档层专门用来存放一年可能只访问一两次的冷数据单价低到每 GB 每月只要几分钱但它会把你的数据从“随时可读”变成“先申请、再等待、要收费、还有时效”的状态。所以真正的 Glacier 恢复核心就三件事判断数据在哪一层、评估取回要多久花多少钱、然后把恢复任务发出去并在窗口期内把数据搬走或转存。这篇文章我会用自己实际恢复几百 GB 数据的过程把控制台、CLI、SDK、Vault 模式的完整操作和踩过的坑全部写出来适合运维、开发和新接触 AWS 的同学直接照着操作。1. 先确认对象在 Glacier 的哪个档位方向错了后面全白费很多人在控制台里看到对象列表的 Storage class 一列显示“Glacier”第一反应就是直接点恢复按钮。但实际上 AWS 现在的 Glacier 不是一个单一存储层而是好几档“冷数据服务”的总称。选错了档位要么恢复动作根本不需要做要么你等了几个小时发现任务压根不匹配。先说现在的完整情况。你在 S3 里能看到以下四种和 Glacier 相关的存储类别存储类别是否需要发起恢复典型等待时间适合的数据Glacier Instant Retrieval不需要毫秒级极少访问但偶尔访问时必须秒回Glacier Flexible Retrieval需要分钟到 12 小时级可接受几小时等待的冷数据Glacier Deep Archive需要12 到 48 小时级几年都不碰一次的归档数据传统 Glacier Vault需要和 Flexible 类似通过 Glacier 原生 API 写入的数据1.1 用几行命令快速确认对象的真实存储类别控制台里看 Storage class 一列是最直观的但如果对象很多我建议直接上 CLIaws s3api list-objects-v2 \ --bucket my-bucket \ --query Contents[*].{Key:Key,StorageClass:StorageClass} \ --output table输出里会明确显示GLACIER、DEEP_ARCHIVE、GLACIER_IR或STANDARD等。这里有个容易懵的点控制台显示名称和 API 返回值不一样。“Flexible Retrieval”在 API 里就是GLACIER“Deep Archive”对应DEEP_ARCHIVE“Instant Retrieval”对应GLACIER_IR。如果你刚接手一个老账号习惯用 CLI 看会准确很多因为控制台界面的中文名在不同时期改过好几轮。1.2 生命周期规则是“隐形搬运工”动手前先查一遍有些对象变成 Glacier 状态并不是你手动操作过而是生命周期规则在后台自动转换的。最常见的一条规则是“创建 30 天后转入 Glacier90 天后转入 Deep Archive”。这种规则的好处是省钱坏处是你可能完全忘了它的存在恢复的时候就会踩一个很隐蔽的坑你刚把数据恢复出来规则又把对象转回 Glacier 了这个问题后面我会专门讲。查规则的命令很简单aws s3api get-bucket-lifecycle-configuration \ --bucket my-bucket输出会列出这个 bucket 下所有的转换和过期规则。看到Transition里包含GLACIER或DEEP_ARCHIVE时心里就要有数恢复前如果不处理你搬出来的数据可能很快又被送回冷层。2. 恢复前把时间、费用和配额算清楚别等账单出来才后悔Glacier 恢复不是点一下按钮就完事它更像“预约取货”。AWS 给你提供了几种不同速度的取回档位速度越快价格越高而且收费不只看数据量还要看请求次数和数据流量。很多第一次操作 Glacier 的人恢复完看到账单直接傻眼就是因为只盯着“每 GB 检索费”忽略了其它部分。2.1 三种取回档位怎么选从 1 分钟到 48 小时的真实差距Glacier Flexible Retrieval 支持三种取回档位Deep Archive 只支持两种取回档位Flexible Retrieval 参考时间Deep Archive 参考时间费用量级适用场景Expedited约 1–5 分钟不支持最高紧急恢复、审计要求、故障排查Standard约 3–5 小时约 12 小时内中等日常恢复的大多数情况Bulk约 5–12 小时约 48 小时内最低海量数据、不急、批量迁出注意Expedited 档位虽然快但 AWS 并不保证你在没有“预置容量”的情况下每次都能享受到 1–5 分钟的取回速度。如果你真的非常在意紧急恢复速度要先购买 Provisioned Capacity。我们平时说的“恢复”绝大多数走 Standard 或 Bulk 就足够了。我处理过一次客户要恢复 300GB 文件业务方当时着急结果选了 Expedited恢复完成确实快但那笔费用足够后悔半年——而实际上数据本身并不算特别关键等三小时完全没问题。2.2 检索费用到底怎么算不是只看每 GB 单价恢复费用大致由三块组成取回量费用按实际取出的数据字节数收费不同档位单价不同。请求费用按请求次数计费通常以每千次请求为单位虽然比取回量费用少但大量零碎文件恢复时积少成多。数据传输费用如果你把恢复出来的数据从 S3 下载到本地或者跨区域传输这部分流量费是另外算的。官方目前会给一点免费额度比如 Glacier Flexible Retrieval 和 Deep Archive 每个月合计有 10GB 的标准取回免费额度但具体规则在不同区域可能调整你动手前一定要去 AWS 官网 S3 定价页确认不要凭记忆估算。我给一个简单的估算公式总费用 ≈ 取回数据量 × 取回档位单价 请求次数 / 1000 × 每千次请求单价 下载跨区域传输流量费比如你要恢复 200GB 数据到本地区域后直接下载到本地估算逻辑是这样的取回量费按 bulk 档位算可能只需要几块钱但下载流量费可能占比更高因为流量单价通常远高于冷数据存储价。这就是为什么很多人恢复完发现“说好的便宜呢”。2.3 一次 200GB 恢复账单复盘我上个月帮一个客户恢复一批 2023 年的访问日志总共约 180GB用的是 Bulk 档位恢复到同区域 S3 标准存储桶后再通过专线拉回本地机房。大概费用结构是取回量费约 1 美元以内Bulk 确实便宜请求费文件数量约 4 万多个请求费占了几美元流量费下载到本地的流量费用是大头接近 20 美元如果当时脑子一热选 Expedited取回量费会变成几十美元甚至更高。所以我的建议是先问自己三个问题——数据多紧急量多大要不要下载出 AWS想清楚再选档位能省下一大半费用。3. 三种恢复操作控制台、CLI 脚本、SDK从救急到批量明确数据层级和费用预期后就可以动手恢复了。实操层面通常有三种方式控制台点选、CLI 脚本批量、SDK 集成到自己的系统。我平时用的最多的是 CLI因为控制台适合看状态和临时救急但一旦涉及几百个文件控制台点到手软容易出错。3.1 控制台界面恢复的完整流程如果你只有零星几个文件要恢复控制台是最直观的打开 S3 控制台进入目标 bucket找到要恢复的对象或文件夹前缀。勾选对象点击顶部菜单里的Actions → Restore from Amazon S3 Glacier。在弹出窗口里选择取回档位Expedited、Standard 或 Bulk。设置恢复有效期Days范围是 1 到 365 天意思是数据恢复出来后可访问多少天。点击 Restore。提交后对象状态会先显示“Restore in progress”恢复完成后会显示“Restored until 某个日期”。这个“某个日期”就是你的访问窗口过了这个日期对象又会回到不可直接读取的归档状态。3.2 CLI 恢复单文件和批量遍历的写法单文件恢复用restore-object即可aws s3api restore-object \ --bucket my-bucket \ --key archive/2024/12/server.log \ --restore-request {Days: 7, GlacierJobParameters: {Tier: Standard}}这里有个细节Days是恢复副本可保留的天数Tier是取回档位参数名是固定的大小写也严格。如果你写成tier或者daysAWS 会直接报参数校验错误命令行是沉默了一点但报错信息会告诉你哪个字段不对。批量恢复时我习惯先把文件清单捞出来再逐条调用aws s3api list-objects-v2 \ --bucket my-bucket \ --prefix archive/2024/ \ --query Contents[?StorageClassGLACIER].Key \ --output text | tr \t \n keys.txt while read -r key; do aws s3api restore-object \ --bucket my-bucket \ --key $key \ --restore-request {Days: 7, GlacierJobParameters: {Tier: Bulk}} sleep 0.2 done keys.txttr \t \n这一步是把list-objects-v2输出的制表符分隔结果转成一行一个 key否则后面循环会出问题。加sleep 0.2是为了避免请求太密集虽然平时可能用不上但大批量恢复时能减少偶发的限流报错。如果你的文件量实在太大比如十万级以上我建议直接用 AWS S3 Batch Operations 或者写个简单的 Python SDK 脚本带有断点续跑和失败重试比 shell 循环更稳。3.3 怎么用 head-object 实时看恢复进度恢复任务提交后最关心的问题就是“好了没”。控制台能看到状态但轮询起来不方便。CLI 一条命令就能看到aws s3api head-object \ --bucket my-bucket \ --key archive/2024/12/server.log \ --query Restore \ --output text返回结果有两种典型情况ongoing-requesttrue表示恢复还在进行中此时如果要直接 GET 这个对象会得到一个类似InvalidObjectState的 403 错误这不是数据丢了而是还没准备好。ongoing-requestfalse, expiry-date2025-04-10T12:00:00.000Z表示恢复已完成且副本会保留到这个时间。注意时区是 UTC换算成国内时间要加 8 小时很多人会看懵。更高级一点的做法是开启 S3 事件通知监听s3:ObjectRestore:Complete事件恢复完成时自动发 SNS 消息到邮箱或钉钉机器人。这样就不用一遍遍去刷状态了尤其是动辄几万对象的恢复任务非常实用。3.4 恢复完成后别急着下载先做校验副本恢复完成的瞬间对象其实还是 Glacier 存储类别只是 S3 服务在幕后给你准备了一个“临时副本”。这个时候可以直接 GET 数据但如果你想长期留在标准存储里必须主动复制aws s3 cp \ s3://my-bucket/archive/2024/12/server.log \ s3://my-bucket/restored/server.log \ --storage-class STANDARD这一步很多人漏了。它有两个作用一是把数据从临时窗口里“固化”下来不受Days限制二是方便后续下载或处理因为标准存储没有恢复时效的问题。4. 恢复时最容易翻车的四个环节都是真实账单换来的操作流程本身不难难的是细节。我自己在生产和半生产环境里恢复过不少数据也帮同事擦过屁股下面这四个坑是出现频率最高的。4.1 生命周期规则把刚恢复的数据又送回了冰川开头我提过生命周期规则的坑这里展开讲。有一次我恢复了某个 bucket 里 500GB 的备份文件设置Days3刚开始下载都正常第二天同事说有部分文件下载时报 403。查了半天发现这个 bucket 里有一条规则创建时间超过 90 天的对象转入DEEP_ARCHIVE。恢复出来的临时副本确实不影响但因为对象本身又被触发了新一轮转换AWS 后台可能把恢复好的副本作废掉导致访问窗口大大缩短。这个问题最稳的处理方式是在恢复之前临时停掉相关的生命周期转换规则等数据全部迁移或下载完毕后再把规则开回去。如果规则不好动至少要把恢复窗口期和规则触发时间错开并设置足够长的Days比如 7 天以上。4.2 恢复天数设置太短下载没完成副本就过期这个坑看起来很低级但特别容易犯尤其是数据量大的时候。假设你恢复了 1TB 数据Bulk 档位可能需要 8 小时才完成恢复但你把Days设成了 1。恢复完成后你只剩约 16 小时可以下载。如果下载带宽有限或者中间有网络抖动一个晚上没下完第二天早上起来发现过期了只能重新发起一次恢复费用和等待时间都得重来。我的经验是恢复量大时Days至少设置 3 天以上甚至 7 天。虽然多保留几天可能会产生一点临时副本的存储费用但对比重新恢复的成本和风险这点钱非常划算。4.3 大批量恢复撞上配额限制AWS 对恢复任务是有配额限制的不是你随便一次提交几万个请求都能立刻处理。尤其是 Expedited 档位为了保证服务水平AWS 对同时进行的请求数量有严格控制。普通账号如果没有购买预置容量用 Expedited 批量恢复几千个对象时很快就会收到SlowDown或LimitExceeded之类的报错。我当时遇到的情况是一次性对 8 万个对象发起了 Standard 档位的恢复请求跑到一万多个时开始出现间歇性 503 错误。解决方案很简单把循环改成分批跑每批 1000 个左右批次之间停 5 秒钟并且在脚本里加重试逻辑。如果你确实有大量紧急恢复需求提前在 Service Quotas 控制台提交配额提升申请别临时抱佛脚。4.4 把“恢复中”和“可访问”当成一个状态这个不算坑更多是理解偏差但排查时很耽误时间。有次同事急着要文件看到控制台显示“Restore in progress”就反复刷新然后问我“为什么这个文件明明显示在恢复还是下载不了”。其实这就是状态理解的问题——恢复中意味着还在路上必须等状态变成“Restored until xxx”才能正常下载。这里还延伸出一个常见误解有人以为Days是从恢复任务提交就开始计时。实际上计时是从恢复完成那一刻开始算的也就是出现ongoing-requestfalse之后才开始消耗可见时间。理解了这个逻辑就不会把时间算错。5. 如果数据在传统 Glacier Vault 里恢复路径完全不同到现在为止说的都是 S3 对象存储里的 Glacier 存储类别。但 AWS 还有一个“上古时代”的服务就叫 S3 Glacier它的数据组织方式是 Vault而不是 Bucket。如果你的公司早期用 Glacier 原生 API 直接写过大量归档数据那你在 S3 桶里是看不见这些文件的恢复路径也完全不同。5.1 Vault 模式和 S3 Bucket 模式的区别传统 Glacier Vault 里存的东西不叫对象叫 Archive。每个 Archive 有一个唯一的 Archive ID但没有类似 S3 的目录结构也没有 key 的概念。你想恢复数据要么知道 Archive ID要么先跑一个 Inventory 任务拿到整个 Vault 的档案清单。这和 S3 里“通过路径找到文件再恢复”是两套逻辑。一个很典型的场景是老员工离职前用 Windows 客户端往 Vault 里传了一批历史邮件备份后来客户端删了只知道数据在 Vault 里但完全不知道有哪些 Archive。这种时候你得先做一次清单检索5.2 Vault 里发起检索任务的实操流程在控制台里你可以从 S3 服务页面左侧找到 S3 Glacier 区域列出所有 Vault。选择某个 Vault 后进入 Jobs 或 Archive retrieval jobs 页面发起一次 Inventory Retrieval。等这个任务完成通常也是几小时你就能拿到一个 JSON 格式的清单里面包含每个 Archive 的 ID 和大小。如果已经知道 Archive ID可以直接用 CLI 发起恢复aws glacier initiate-job \ --account-id - \ --vault-name my-vault \ --job-parameters {Type:archive-retrieval,ArchiveId:archive-id-xxx,Tier:Standard} \ --region us-east-1命令返回一个 jobId然后用这个 jobId 轮询任务状态完成后拉取数据aws glacier get-job-output \ --account-id - \ --vault-name my-vault \ --job-id $JOB_ID \ output.bin这里的--account-id -是固定写法用短横线表示当前账号不是漏填了参数。5.3 取回后尽快转存为普通对象从 Vault 里拿回来的数据是一份原始数据流没有文件系统结构。拿到output.bin之后我通常会把它重新命名并上传到 S3 标准存储桶aws s3 cp output.bin s3://my-bucket/recovered/backup-2023.bin \ --storage-class STANDARD为什么建议转存因为 Vault 模式的数据不管是查清单还是取数据等待时间都很长而且没有一个统一的管理界面。把数据放回 S3 Bucket 后至少以后你能用常规方式管理、检索、备份不用再和 Archive ID 打交道。6. 恢复只是起点验证完整性、调整生命周期、沉淀应急预案数据能下载下来不代表恢复流程结束。我见过很多团队恢复完数据后直接开始用完全不校验结果用到一半发现某个文件是损坏的又得重新恢复一次。所以恢复的收尾工作同样重要。6.1 验证数据完整性ETag、MD5、还有多段上传的特殊情况常规的校验方式是对比本地文件的 MD5 和 S3 对象的 ETag。对单段上传的对象ETag 就是文件内容的 MD5可以直接比md5sum file.binaws s3api head-object \ --bucket my-bucket \ --key restored/server.log \ --query ETag \ --output text但如果原对象当初是用分片上传Multipart Upload写入的ETag 就不等于整个文件的 MD5而是各分片 MD5 拼接后再做哈希的结果格式通常是“一串十六进制字符串-分片数量”。这种情况下直接用 MD5 对比会误判正确的做法是把文件下载下来后用同样分片大小重新计算组合 MD5或者干脆对比文件内容和业务层面校验值比如日志条数、压缩包能不能正常解压。6.2 调整生命周期策略而不是一股脑全归档这次恢复完我强烈建议你回头看一遍整条存储策略。最常见的问题是把所有数据一刀切创建 30 天后就全转 Glacier。但实际业务里有些数据虽然不常用却需要快速访问比如合同扫描件、历史工单记录真到用的时候等 5 小时恢复很难受。合理的做法是分几层处理活跃数据留在 Standard或者配合 S3 Intelligent-Tiering 自动分层偶尔访问的数据转到 Standard-IA一年到头碰不了几次的数据转到 Glacier Flexible Retrieval法律合规要求留存多年、几乎不可能访问的数据才进 Deep Archive另外对于特别重要的归档数据建议开启 S3 版本控制和 Object Lock避免误删除或者被勒索软件加密时没法恢复。这一点在日常操作中容易被人忽略出了事故才想起来代价就大了。6.3 建立一份恢复预案避免下次再手忙脚乱真实经验告诉我们凡是没有预案的云账号遇到数据恢复需求时基本都是现场拍脑袋。别说档位怎么选可能连哪个 bucket 里有什么数据都不完全清楚。我的建议是提前做四件事用 S3 Inventory 开启每日或每周清单导出你随时知道哪些数据在哪个存储层。对关键 bucket 做一次小规模的测试恢复比如每个季度恢复几个小文件验证权限、事件通知、SNS 告警链路都是通的。把恢复常用命令封装成脚本放到公共运维平台或专门的 runbook 文档里别等要用的时候再搜索回忆。在 AWS 定价计算器里预先模拟一次较大规模的恢复费用让业务方对成本有预期避免恢复完被账单吓一跳。我个人现在接手任何公司账号第一步一定是先把全部生命周期规则和存储类别分布导出来看一遍再谈优化或恢复。归档存储这个领域很多时候问题不是数据取不回来而是取回的姿势不对、账单不对、时间不对。希望这篇能帮你把这条路走顺一点。
阅读完成 · 觉得有帮助？
