Question

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

我最近的困境与restore()库中的boto函数有关。很简单，它根本不起作用。我有一段时间怀疑这个问题与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

一些澄清。我知道在存储桶中搜索密钥的for循环效率非常低，但这恰恰是个谜。

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

第二个：u'GLACIER'

现在向前迈进，我认为这种不一致正在影响restore()手术的效果。如果我尝试key.restore(days=num_days)上的任何一个＆＃39;键＆＃39;我在上面列出的派生词，它们都没有表明它在将对象从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变回S3标准（要做到这一点，你必须复制一个对象并确保副本在标准存储）。

密钥不一致仍然是一个问题，但我发现了一些黑客的方法（我最好避免，但是，现在，我别无选择）。

boto的Glacier-to-S3 restore（）函数不起作用

2 个答案: