在恢复时,gsutil似乎重新上传文件

时间:2014-04-08 15:07:01

标签: google-cloud-storage google-compute-engine

我正在尝试从包含总计1TB的约3000个文件的磁盘上传数据到Google云端存储。我正在使用gsutil cp -R <disk-top-directory> <bucket>。我的理解是,如果gsutil恢复/重新启动,它会使用校验和来确定文件何时上传并跳过它。

它似乎没有这样做:它似乎是从顶部恢复上传并再次替换文件。当我连续运行gsutil ls -Rl <bucket/disk-top-directory>十分钟并将它们与diff进行比较时,我看到的是相同文件的大小相同但更改(更新)的日期。 (即与重新上传的同一文件一致。)

例如:

<  404104811  2014-04-08T14:13:44Z  gs://my-bucket/disk-top-directory/dir1/dir2/dir3/dir4/dir5/file-20.tsv.bz2
---
>  404104811  2014-04-08T14:43:48Z  gs://my-bucket/disk-top-directory/dir1/dir2/dir3/dir4/dir5/file-20.tsv.bz2

我用来读取磁盘和传输文件的机器正在运行Ubuntu 13.10。我使用Debian和Ubuntu的pip指令安装了gsutil。

我是否误解了gsutil的可恢复转移是如何工作的?如果没有,任何诊断和修复,以获得正确的恢复行为?提前谢谢!

2 个答案:

答案 0 :(得分:5)

您需要使用-n(No-clobber)开关来阻止重新上传目标中已存在的对象。

gsutil cp -Rn <disk-top-directory> <bucket>

来自帮助(gsutil help cp)

-n            No-clobber. When specified, existing files or objects at the
              destination will not be overwritten. Any items that are skipped
              by this option will be reported as being skipped. This option
              will perform an additional HEAD request to check if an item
              exists before attempting to upload the data. This will save
              retransmitting data, but the additional HTTP requests may make
              small object transfers slower and more expensive.

同样according to this,当传输超过2MB的文件时,gsutil会自动使用可恢复的传输模式。

答案 1 :(得分:0)

如果您已开放使用(仍然是测试版)gsutil v4,则该版本的gsutil具有rsync命令。你可以通过运行来获得这个:

gsutil update gs://prerelease/gsutil_4.0beta2pre_minus_m_sugg.tar.gz

在切换到此主要新版本之前,请务必阅读发行说明,特别是如果您在脚本中使用gsutil v3。