S3 Glacier对象未恢复：批量恢复后无法同步至其他S3桶

我来帮你一步步排查和解决这个问题——从你描述的操作来看，核心问题大概率是批量恢复的对象还未完成解冻，或者是恢复命令的小失误导致任务没正确执行，下面是具体的解决步骤：

1. 先确认恢复任务的真实状态 #

你用的是bulk（批量）优先级恢复，这个优先级的解冻速度比标准优先级慢很多，10.5TiB的大文件夹可能需要数小时甚至更久才能完成全部对象的恢复。你可以通过以下命令检查单个对象的恢复状态：

aws s3api head-object --bucket mybucket --key folder1/your-large-test-file.ext

在返回的响应里，找到Restore字段：

• 如果显示"Restore": "ongoing-request=\"true\", expiry-date=\"xxxx-xx-xxTxx:xx:xxZ\""，说明对象还在恢复过程中，需要继续等待；
• 如果没有这个字段，或者显示恢复已完成，那再排查其他问题。

你也可以批量列出所有恢复中的对象：

aws s3api list-objects-v2 --bucket mybucket --prefix folder1/ --query "Contents[?StorageClass=='GLACIER' || StorageClass=='DEEP_ARCHIVE'] | [?Restore!=null]"

2. 检查s3cmd恢复命令的正确性 #

注意到你写的命令里有个小错误：-restore-priority=bulk应该是两个横杠的长选项--restore-priority=bulk。s3cmd对长选项要求必须用双横杠，单横杠是短选项（比如-r对应--recursive）。如果这个参数没生效，可能默认用了标准优先级，但不管怎样，先确认恢复任务是否真的被触发——可以通过上面的head-object命令验证对象是否有恢复请求记录。

3. 调整同步策略，适配恢复进度 #

aws s3 sync默认会跳过仍在恢复中的冰川/深度归档对象，因为这些对象暂时无法直接访问。如果不想等待全部恢复完成，可以尝试以下两种方法：

方法一：逐个触发恢复并同步 #

结合aws s3 ls和循环，逐个处理对象（适合补漏或重新触发恢复）：

# 处理folder1
aws s3 ls s3://mybucket/folder1/ --recursive | awk '{print $4}' | while read key; do
  aws s3 cp s3://mybucket/$key s3://mybucket2/$key --restore-request Days=4,Priority=BULK
done

# 处理folder2
aws s3 ls s3://mybucket/folder2/ --recursive | awk '{print $4}' | while read key; do
  aws s3 cp s3://mybucket/$key s3://mybucket2/$key --restore-request Days=4,Priority=BULK
done

这个命令会在复制对象的同时触发恢复请求，如果对象已经在恢复中，也会等待它完成后再复制。

方法二：等待全部恢复完成后再同步 #

如果时间允许，建议先等待所有对象恢复完成。你可以定期用前面的list-objects-v2命令检查恢复进度，当没有返回任何恢复中的对象时，再重新执行aws s3 sync命令即可。

4. 验证权限与存储类配置 #

• 确保你使用AWS CLI的用户拥有s3:GetObject、s3:RestoreObject、s3:ListBucket等必要权限，且和s3cmd使用的是同一个权限身份（避免因权限不一致导致看不到恢复状态）；
• 确认源存储桶的对象确实属于GLACIER或DEEP_ARCHIVE存储类——如果是标准存储类，根本不需要恢复，那可能是其他配置问题（比如对象权限、存储桶策略等）。

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