3

我在脚本中使用 Python 和 Boto 从本地磁盘复制多个文件，将它们转换为 .tar 文件并上传到 AWS Glacier。

我的脚本基于： http: //www.withoutthesarcasm.com/using-amazon-glacier-for-personal-backups/#highlighter_243847

其中使用 concurrent.ConcurrentUploader

我只是好奇在成功取回 ID 后，我能确定数据都在 Glacier 中吗？concurrentUploader 是否进行任何类型的哈希检查以确保所有位都到达？

我想从本地磁盘中删除文件，但担心我应该实施某种哈希检查......我希望这发生在幕后。我已经尝试并成功检索了几个档案，并且能够解压缩。只是想非常谨慎。

有谁知道是否有在后台检查所有传输的部分是否已成功上传？如果没有，是否有人有任何 python 示例代码来说明如何使用哈希检查实现上传？

非常感谢！

Boto 并发上传器文档： http ://docs.pythonboto.org/en/latest/ref/glacier.html#boto.glacier.concurrent.ConcurrentUploader

更新：查看实际的 Boto 代码（https://github.com/boto/boto/blob/develop/boto/glacier/concurrent.py）第 132 行似乎表明哈希是自动计算的，但我不清楚是什么

[None] * total_parts

方法。这是否意味着确实计算了哈希值，还是留给用户实现？

4

2 回答 2

3

Glacier 本身旨在尝试使任何应用程序都无法在不保证数据完整性的情况下完成分段上传。

http://docs.aws.amazon.com/amazonglacier/latest/dev/api-multipart-complete-upload.html

返回存档 ID 的 API 调用与“树哈希”一起发送——上传内容的每个 MiB 的 sha256 哈希的 sha256，计算为合并为单个哈希的树——以及上传的总字节数。如果这些与每个部分中实际上传的内容不匹配（同时也在上传时针对 sha256 哈希和子树哈希进行了验证），那么“完整的多部分”操作将失败。

根据 Glacier API 的设计，应用程序几乎不可能“成功”上传不完整的文件并返回存档 ID。

于 2014-02-09T03:38:47.610 回答
1

是的，并发上传器确实会计算每个部分的树形哈希和整个上传负载的线性哈希。该行：

[None] * total_parts

只需创建一个包含total_parts多个None值的列表。稍后，这些None值将替换为特定部分的适当树哈希。然后，最后，树哈希值列表用于计算整个上传的最终线性哈希。

因此，Glacier API 需要进行大量完整性检查。

于 2014-02-09T03:39:06.890 回答