boto 的 Glacier-to-S3 restore() 功能不起作用

Question

我对 python 和boto 提供的 S3/Glacier 集成接口都很陌生。但是，我发现了一些似乎特别没有记录/未解决的缺陷，这些缺陷严重阻碍了我当前工作项目的进展。

我最近的困境与boto 库中的restore() 函数有关。很简单，它根本不起作用。一段时间以来，我一直怀疑该问题与Key 对象与跟踪存储在 S3 存储桶中的storage_class 的数据不一致的问题有关。此页面可以作为该问题某些细节的资源：@​​987654321@

要详细说明Key 一致性问题，请考虑以下有关已从 S3 归档到 Glacier 的对象的场景：

from boto.s3.connection import S3Connection
from boto.s3.key import Key
...
conn = S3Connection(access_key_id, secret_key)
bucket = conn.get_bucket(bucket_name)
key_object = Key(bucket)

print bucket.get_key(filename).storage_class
...
key_object.key = filename
for item in bucket.list():
    if item.key == filename:
        break

print item.storage_class

一些澄清。我知道在存储桶中搜索密钥的for 循环效率极低，但这正是其中的奥秘。

第一个print 语句将产生：u'STANDARD'

第二个：u'GLACIER'

现在继续前进，我相信这种不一致正在影响restore() 操作的功效。如果我尝试key.restore(days=num_days) 对上面列出的任一“密钥”派生，它们都没有表明它将对象从 Glacier 恢复到标准 S3 可访问性有任何影响。此外，尝试restore 会返回None。在这一点上，我完全不知道什么可以解释这个故障。这是我的程序错误吗？或者boto 有什么天生的缺陷？

如果您能给我提供任何帮助，我们将不胜感激。

谢谢。

注意：我没有忘记基本错误检查，即文件是否存在于存储桶中？文件已经恢复了吗？等等

Answer 1

如果您已经在跟踪文件名，您是否尝试过通过http://docs.pythonboto.org/en/latest/s3_tut.html#transitioning-objects-to-glacier 遵循文档的示例

conn = S3Connection(access_key_id, secret_key)
bucket = conn.get_bucket(bucket_name)
key = bucket.get_key(filename)
key.restore(days=5)

使用 key.ongoing_restore 获取恢复状态

Answer 2

我弄清楚我的困惑是什么。一旦一个物体在 Glacier 上，它就会留在 Glacier 上。它可以恢复以便可以下载，但它的存储类永远不会从 Glacier 更改回 S3 标准（为此，您必须制作对象的副本并确保副本位于标准存储）。

密钥不一致仍然是一个问题，但我找到了一些解决方法（我最好避免，但目前我别无选择）。