python-2.7 - boto 的 Glacier-to-S3 Restore() 功能不起作用

Question

我对 python 和 boto 提供的 S3/Glacier 集成接口(interface)都相当陌生。然而，我发现了一些似乎特别没有记录/ Unresolved 缺陷，这些缺陷严重阻碍了我当前工作项目的进展。

我最近遇到的困境与 boto 库中的 restore() 函数有关。很简单，它根本不起作用。一段时间以来，我怀疑该问题与 Key 对象在跟踪存储在 S3 存储桶中的 storage_class 数据方面不一致有关。此页面可以是有关该问题的一些细节的资源:https://github.com/boto/boto/issues/1173

为了详细说明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

一些澄清。我知道在存储桶中搜索 key 的 for 循环效率极低，但这正是谜团所在。

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

第二个:u'GLACIER'

现在，我相信这种不一致正在影响 restore() 操作的效率。如果我尝试对上面列出的任一“ key ”派生进行 key.restore(days=num_days)，它们都不会表明它对将对象从 Glacier 恢复到标准 S3 可访问性有任何影响。此外，尝试恢复会返回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 获取恢复状态