我正在尝试将已启用生命周期规则的文件还原到Glacier深度存档。当我尝试在AWS CLI上使用以下命令还原到其他目录时，下载少量文件后会引发错误。
用于恢复目录的命令：aws s3 cp s3：// xxxxxxx / cf-ant-prod / year = 2020 / s3：// xxxxxxxx / atest / --force-glacier-transfer --storage-class STANDARD --recursive --profile MFA
错误：调用CopyObject操作时发生错误（InvalidObjectState）：操作对源对象的存储类别无效
答案 0 :(得分：1)
如your other question所述，--force-glacier-transfer参数不会不还原存储在Glacier中的对象。这只是避免发出警告通知的一种方法。
要从Glacier Deep Archive中检索，您将需要：
不可能进行即时还原或Restore + Copy。
答案 1 :(得分：0)
正如约翰·罗滕斯坦（John Rotenstein）所提到的那样-从Glacier看来，对象的简单还原必须“就地”完成，一旦还原，就可以根据需要进行操作（复制）。
我试图通过Lambda做与问题主题类似的事情，并且挣扎了一段时间，因为发现restoreObject()请求是SQL Select对象这一事实使documentation变得模糊不清恢复 OR ，一个简单的单个对象恢复...以及最重要的是，哪些参数适用于哪种操作模式。
我的目标是将一个对象从Glacier中恢复到同一存储桶中的新位置/文件名。该文档强烈建议这样做是可能的，因为OutputLocation中有一些参数可以指定BucketName和Prefix……似乎这些参数仅适用于SQL Select对象还原。
对我来说，令人困惑的部分与restoreObject()方法的参数有关，没有足够的区分来知道您例如在进行简单的还原请求时无法提供Description参数使用GlacierJobParameters参数...让我感到沮丧的是，我会遇到诸如以下的错误：
MalformedXML: The XML you provided was not well-formed or did not validate against our published schema
没有迹象表明已发布的模式位于何处，对已发布的模式进行谷歌搜索没有产生似乎适用于S3 API的结果...我希望我可以摆脱API文档并直接引用到“已发布的架构” ...（在哪里/如何发布？）
我的建议是改进restoreObject()方法的文档和/或将restoreObject()方法拆分为simpleRestoreObject()和sqlRestoreObject()对象，以便参数模式完全不同。
答案 2 :(得分：0)
必须分别完成从S3 Glacier Deep Archive（或就此而言，Glacier）中还原对象的操作，并且 将这些对象复制到其他位置之前。
一种实现此目的的方法是，例如，首先使用s3 ls检索所需文件夹中的对象列表
aws s3 ls s3://xxxxxxx/cf-ant-prod/year=2020/ --recursive
，并使用每个对象名称分别运行恢复命令：
aws s3api restore-object --bucket s3://xxxxxxx --key <keyName> --restore-request Days=7
这将为每个对象发起一个标准的还原请求，因此预计这需要12-24小时。然后，还原完成后，您可以使用上述语法自由复制那些对象。
另一种选择是使用诸如s3cmd之类的工具，该工具在给定存储桶和文件夹的情况下支持递归还原。但是，在运行cp命令之前，您仍然必须等待还原请求完成。