使用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的要求，發生了很多完整性檢查。