我在脚本中使用 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
方法。这是否意味着确实计算了哈希值还是留给用户来实现？
最佳答案
Glacier 本身旨在尝试使任何应用程序无法在没有数据完整性保证的情况下完成分段上传。
http://docs.aws.amazon.com/amazonglacier/latest/dev/api-multipart-complete-upload.html
返回存档 ID 的 API 调用与“树哈希”一起发送 - 上传内容的每个 MiB 的 sha256 哈希的 sha256，计算为合并为单个哈希的树 - 以及上传的总字节数。如果这些与每个部分中实际上传的内容不匹配(同时，它们也在上传时针对 sha256 哈希和子树哈希进行验证)，那么“完整的多部分”操作将失败。
根据 Glacier API 的设计，应用程序几乎不可能“成功”上传不完整的文件但返回存档 ID。
关于python - 使用 Python Boto 和 Amazon Glacier concurrent.ConcurrentUploader 保证数据完整性？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/21654021/