更快的 s3 存储桶复制答案

【问题标题】：Faster s3 bucket duplication更快的 s3 存储桶复制
【发布时间】：2011-01-11 21:48:58
【问题描述】：

我一直在尝试寻找比s3cmd 更好的用于复制存储桶的命令行工具。 s3cmd 可以复制桶，而无需下载和上传每个文件。我通常使用 s3cmd 复制存储桶的命令是：

s3cmd cp -r --acl-public s3://bucket1 s3://bucket2

这可行，但它非常慢，因为它通过 API 一次复制每个文件。如果s3cmd 可以并行运行，我会非常高兴。

是否有其他可用的命令行工具或代码可供人们用来复制比s3cmd 更快的存储桶？

编辑：看起来s3cmd-modification 正是我正在寻找的。太糟糕了，它不起作用。还有其他选择吗？

【问题讨论】：

不知道为什么这个问题反复被关闭，因为似乎有很多开发人员遇到了这个问题。无论如何，我以高度并行的方式解决了它，这是链接：github.com/cobbzilla/s3s3mirror 谢谢！ - 乔纳森。

标签： amazon-web-services amazon-s3

【解决方案1】：

AWS CLI 似乎完美地完成了这项工作，并且具有成为官方支持工具的好处。

aws s3 sync s3://mybucket s3://backup-mybucket

http://docs.aws.amazon.com/cli/latest/reference/s3/sync.html

默认支持并发传输。见http://docs.aws.amazon.com/cli/latest/topic/s3-config.html#max-concurrent-requests

要快速传输大量小文件，请从 EC2 实例运行脚本以减少延迟，并增加 max_concurrent_requests 以减少延迟的影响。例如：

aws configure set default.s3.max_concurrent_requests 200

【讨论】：

它支持基于文件修改时间、大小等的非并发同步。当我尝试时，它非常快。我相信这些对象是直接在 S3 上复制的，而无需将它们下载到本地机器上。默认情况下它不会并行运行，但我相信您可以同时在不同的子文件夹上运行多个同步命令。它足够快，您可能无论如何都不需要它并行运行。我只是在几分钟内复制了 100GB 的数据。
如果文件数量多，速度会很慢。
当传输许多小文件时，延迟成为关键约束，因此从 EC2 实例运行此命令至关重要。
我用它构建了一个 docker，效果很好github.com/sunshineo/s3-bucket-copier
现在它支持并发同步 :-) docs.aws.amazon.com/cli/latest/topic/…

【解决方案2】：

如果您不介意使用 AWS 控制台，您可以：

选择第一个存储桶中的所有文件/文件夹
点击操作 > 复制
创建一个新存储桶并选择它
点击操作>粘贴

它仍然相当慢，但你可以让它不理会它，让它做它的事情。

【讨论】：

@BradGoss 这是个好问题。我以为它正在使用 Amazon 网络来复制存储桶的内容，并且没有向您的本地计算机进行任何传输，但如果您发现不同，请告诉我。
我今天才用这个方法。它不会将文件拉到您的本地机器上——它会直接复制，而且速度要快得多。
它仍然获取文件列表。如果列表太长（在我的情况下有几十万个文件），那么它会很慢。并且极有可能超时/挂起
不幸的是，此过程与浏览器相关联。 :( 来自the docs: "启动复制过程后，您必须在复制过程中保持浏览器打开。"
我正在尝试在包含 800 万个文件的存储桶上执行此操作。不知道要多少个月才能选中所有的复选框...

【解决方案3】：

我尝试使用 AWS Web 控制台、s3cmd 和 AWS CLI 克隆两个存储桶。虽然这些方法大部分时间都有效，但它们的速度非常慢。

然后我找到了s3s3mirror：一个用于同步两个 S3 存储桶的专用工具。它是多线程的，并且比我尝试过的其他方法快得多。我迅速将千兆字节的数据从一个 AWS 区域转移到另一个区域。

在https://github.com/cobbzilla/s3s3mirror查看它，或从https://registry.hub.docker.com/u/pmoust/s3s3mirror/下载一个 Docker 容器

【讨论】：

如果您有很多文件要传输，这是迄今为止最好的工具。可惜它在答案列表中远远落后......
请注意：需要 Java 6/7 才能编译。
我在 EC2 实例中使用它，它的运行速度快得令人难以置信！我不得不将和替换为实际的存储桶名称（不是端点或 AWS CLI 中的类似名称）。
非常棒的工具，强烈推荐用于处理大量文件。对复制线程数量的控制非常棒。
您不认为使用 aws-cli 而不是第三方应用程序来完成这项工作更安全吗？毕竟，我们需要提供凭据或访问密钥才能使用这些工具。

【解决方案4】：

对于临时解决方案，使用 aws cli 在存储桶之间同步：

aws s3 sync 速度取决于：
- 对 S3 端点的 API 调用延迟
- 并发 API 调用的数量

提高同步速度：
- 从 AWS 实例运行 aws s3 sync（FreeBSD 上的 c3.large 可以；-)）
- 更新 ~/.aws/config 为：
-- max_concurrent_requests = 128
--max_queue_size = 8096

使用以下配置和实例类型，我能够在 474 秒内同步存储桶（309GB，72K 文件，us-east-1）。

如需更通用的解决方案，请考虑 - AWS DataPipeLine 或 S3 跨区域复制。

【讨论】：

您知道如果我使用 S3 cp 是否可以期待相同的性能吗？您确定当您使用同步时它实际上传输了所有 309GB？ sync 只会同步其他存储桶中不同或不存在的文件。
另外，对于我有 1k 或更少文件但它们更大（10gb）的用例，您对此有何看法？你认为我会看到与你类似的表现吗？
@frosty，在我的例子中，目标存储桶是空的。根据awscli doc - aws sync 仅复制新的和更新的文件。也许你应该期待aws cp 的高性能（复制是在内部完成的，你的客户端只需发出一个 API 调用）。性能取决于以下因素：1. src 和 dst 区域之间的延迟（例如 us-east-X 到 us-west-X） 2. 客户端和 AWS API 端点之间的延迟（发出 API 调用的速度） 3.并发请求的数量（您的客户端每秒可以发出多少个请求）。在我的情况下，309G 是在同一区域（us-east-1）的存储桶之间复制的

【解决方案5】：

由于这是 Google 在此主题上的第一次成功，因此添加了额外信息。

'Cyno' 制作了更新版本的 s3cmd-modification，现在支持并行桶到桶同步。正是我一直在等待的。

拉取请求在https://github.com/pcorliss/s3cmd-modification/pull/2，他的版本在https://github.com/pearltrees/s3cmd-modification

【讨论】：

s3cmd-modification 为我节省了数天的复制时间。

【解决方案6】：

我不知道任何其他 S3 命令行工具，但如果这里没有出现任何问题，那么编写自己的工具可能是最简单的。

选择您喜欢的任何语言和 Amazon SDK/工具包。然后您只需要列出/检索源存储桶内容并复制每个文件（显然是并行的）

查看s3cmd-modification 的源代码（我承认我对 python 一无所知），看起来他们没有并行化桶到桶的代码，但也许您可以使用标准的上传/下载并行代码作为这样做的起点。

【讨论】：

是的。我一直在玩弄这个想法，并用 ruby 用事件机器或用 JRuby 线程化的事件方式编写它。但是， s3cmd 已经很完整了，我宁愿直接使用它。我一直在与 s3cmd 的开发人员交谈，他有几个解决方案正在筹备中，可能会解决性能问题。

【解决方案7】：

一个简单的aws s3 cp s3://[original-bucket] s3://[backup-bucket] --recursive 效果很好（假设您有 aws cli 设置）

【讨论】：

【解决方案8】：

扩展 deadwards 答案，2021 年将对象从一个存储桶复制到另一个存储桶需要 不超过 2 分钟在 AWS 控制台中获得 1.2 GB 数据强>。

创建存储桶，输入存储桶名称，选择区域，从现有存储桶复制设置。创建存储桶。
创建存储桶后，转到要将文件复制到的源存储桶。
全选（如果需要，或者您可以选择所需的文件和文件夹），操作 > 复制。
在目标位置，您需要浏览存储桶，将文件和文件夹复制到其中。
单击复制按钮后，所有文件和文件夹将在一两分钟内复制完毕。

【讨论】：

【解决方案9】：

如果您有 AWS 控制台访问权限，请使用 AWS cloudshell 和

使用下面的命令

aws s3 sync s3://mybucket s3://backup-mybucket

无需安装AWS CLI 或任何工具。

命令取自上述最佳答案。 Cloudshell 将确保即使您失去连接也能顺利运行您的命令，而且由于它是直接的 aws-to-aws，它也会更快地运行。中间没有本地机器。

【讨论】：