使用Python Boto和Amazon Glacier concurrent.ForcurrentUploader保证数据完整性？

Question

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

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

它使用concurrent.ConcurrentUploader

我只是好奇，我有多大的把握可以是数据都是在冰川成功后获得一个ID后面？ concurrentUploader是否执行任何类型的散列检查以确保所有位都到达？

我想从我的本地磁盘中删除文件，但担心我应该实施某种散列检查...我希望这是发生在引擎盖下。我试过并成功检索了一些档案，并能够解除焦油。只是要非常小心。

是否有人知道是否有检查引擎盖内的所有传输成功上传？如果没有，有没有人有任何python示例代码如何实现与散列检查上传？

非常感谢！

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

UPDATE： 望着实际宝途码（https://github.com/boto/boto/blob/develop/boto/glacier/concurrent.py）线132似乎表明散列自动计算的，但我不清楚是什么的

[None] * total_parts 

的意思。这是否意味着哈希值确实被计算出来，还是留给用户来执行？

Answer 1

冰川本身旨在使任何应用程序都无法在没有数据完整性保证的情况下完成分段上传。

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

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

对于应用程序来说，设计Glacier API实际上是不可能的，可以“成功”上传一个不完整的文件，并返回一个档案ID。

Answer 2

是的，并发上传器计算每个部分的树散列和整个上传的有效载荷的线性散列。行：

[None] * total_parts 

刚刚创建包含total_parts数None值的列表。之后，None值将由特定部分的适当树散列替换。然后，最后，使用树散列值列表来计算整个上传的最终线性散列值。

因此，根据Glacier API的要求，发生了很多完整性检查。