112

我正在寻找一些建议或最佳实践来备份 S3 存储桶。
从 S3 备份数据的目的是防止数据丢失，原因如下：

  1. S3 问题
  2. 我不小心从 S3 中删除了这些数据的问题

经过一番调查，我看到以下选项：

  1. 使用版本控制http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html
  2. 使用 AWS 开发工具包从一个 S3 存储桶复制到另一个
  3. 备份到 Amazon Glacier http://aws.amazon.com/en/glacier/
  4. 备份到本身已备份的生产服务器

我应该选择什么选项以及仅在 S3 上存储数据的安全性如何？想听听你的意见。
一些有用的链接：

4

8 回答 8

72

最初发布在我的博客上：http ://eladnava.com/backing-up-your-amazon-s3-buckets-to-ec2/

定期将您的 S3 存储桶同步到 EC2 服务器

这可以通过使用多个命令行实用程序轻松实现，这些实用程序可以将远程 S3 存储桶同步到本地文件系统。

s3cmd
起初，s3cmd看起来非常有前途。然而，在我巨大的 S3 存储桶上尝试它之后 - 它无法扩展，并出现Segmentation fault. 不过，它在小桶上确实工作得很好。由于它不适用于大桶，我开始寻找替代方案。

s4cmd
较新的多线程替代s3cmd. 看起来更有希望，但是，我注意到它不断重新下载本地文件系统上已经存在的文件。这不是我对同步命令所期望的那种行为。它应该检查远程文件是否已在本地存在（哈希/文件大小检查会很整洁）并在下一次同步运行在同一目标目录上时跳过它。我打开了一个问题（bloomreach/s4cmd/#46）来报告这种奇怪的行为。与此同时，我开始寻找另一种选择。

awscli
然后我发现awscli. 这是亚马逊的官方命令行界面，用于与其不同的云服务进行交互，包括 S3。

AWSCLI

它提供了一个有用的同步命令，可以快速轻松地将远程存储桶文件下载到本地文件系统。

$ aws s3 sync s3://your-bucket-name /home/ubuntu/s3/your-bucket-name/

好处：

  • 可扩展 - 支持巨大的 S3 存储桶
  • 多线程 - 通过利用多个线程更快地同步文件
  • 智能 - 仅同步新文件或更新文件
  • 快速 - 得益于其多线程特性和智能同步算法

意外删除

方便的是，sync如果源（S3 存储桶）中缺少目标文件夹（本地文件系统）中的文件，该命令不会删除它们，反之亦然。这非常适合备份 S3 - 如果文件从存储桶中删除，重新同步它不会在本地删除它们。如果您删除本地文件，它也不会从源存储桶中删除。

在 Ubuntu 14.04 LTS 上设置 awscli

让我们从安装开始awscli。有几种方法可以做到这一点，但是，我发现通过apt-get.

$ sudo apt-get 安装 awscli

配置

接下来，我们需要通过创建用户并附加AmazonS3ReadOnlyAccess策略来配置您必须从IAMawscli获取的访问密钥 ID 和密钥。这也将阻止您或任何有权访问这些凭据的人删除您的 S3 文件。确保输入您的 S3 区域，例如.us-east-1

$ aws 配置

aws 配置

准备

让我们准备本地 S3 备份目录，最好在/home/ubuntu/s3/{BUCKET_NAME}. 确保替换{BUCKET_NAME}为您的实际存储桶名称。

$ mkdir -p /home/ubuntu/s3/{BUCKET_NAME}

初始同步

让我们继续使用以下命令第一次同步存储桶：

$ aws s3 同步 s3://{BUCKET_NAME} /home/ubuntu/s3/{BUCKET_NAME}/

假设存储桶存在，AWS 凭证和区域正确，并且目标文件夹有效，awscli将开始将整个存储桶下载到本地文件系统。

根据存储桶的大小和您的 Internet 连接，它可能需要几秒钟到几小时不等。完成后，我们将继续设置自动 cron 作业，以使存储桶的本地副本保持最新。

设置 Cron 作业

继续并sync.sh在以下位置创建一个文件/home/ubuntu/s3：

$纳米/home/ubuntu/s3/sync.sh

将以下代码复制并粘贴到sync.sh：

#!/bin/sh

# 回显当前日期和时间

回声'--------------'
日期
回声'--------------'
回声''

# 回显脚本初始化
echo '正在同步远程 S3 存储桶...'

# 实际运行同步命令（将 {BUCKET_NAME} 替换为您的 S3 存储桶名称）
/usr/bin/aws s3 同步 s3://{BUCKET_NAME} /home/ubuntu/s3/{BUCKET_NAME}/

# 回显脚本完成
echo '同步完成'

确保将{BUCKET_NAME}替换为您的 S3 存储桶名称，在整个脚本中使用两次。

专业提示：您应该使用/usr/bin/aws链接到aws二进制文件，因为crontab在有限的 shell 环境中执行命令并且无法自行找到可执行文件。

接下来，确保chmod脚本可以由crontab.

$ sudo chmod +x /home/ubuntu/s3/sync.sh

让我们尝试运行脚本以确保它确实有效：

$ /home/ubuntu/s3/sync.sh

输出应该与此类似：

sync.sh 输出

crontab接下来，让我们通过执行以下命令来编辑当前用户：

$ crontab -e

如果这是您第一次执行crontab -e，您需要选择一个首选编辑器。我建议选择nano它，因为它对初学者来说最容易使用。

同步频率

我们需要crontab通过编写命令来确定脚本运行的频率以及脚本在本地文件系统中的位置。该命令的格式如下：

mh dom mon dow 命令

以下命令配置为每小时crontab运行一次脚本（通过 minute:0 和 hour:* 参数指定）并将脚本的输出通过管道传输到我们目录中的文件：sync.shsync.logs3

0 * * * * /home/ubuntu/s3/sync.sh > /home/ubuntu/s3/sync.log

crontab您应该将此行添加到您正在编辑的文件的底部。然后，继续按Ctrl + W将文件保存到磁盘，然后按 Enter。然后，您可以nano按Ctrl + X退出。crontab现在将每小时运行一次同步任务。

专业提示：/home/ubuntu/s3/sync.log您可以通过检查、检查执行日期和时间的内容以及检查日志以查看已同步哪些新文件来验证每小时 cron 作业是否已成功执行。

可以了，好了！您的 S3 存储桶现在将每小时自动同步到您的 EC2 服务器，您应该一切顺利。请注意，随着时间的推移，随着您的 S3 存储桶变大，您可能必须增加 EC2 服务器的 EBS 卷大小以容纳新文件。您始终可以按照本指南增加 EBS 卷大小。

于 2015-10-03T20:39:33.900 回答
33

考虑到相关链接，它解释了 S3 具有 99.999999999% 的耐用性，我会放弃你的担忧 #1。严重地。

现在，如果 #2 是一个有效的用例并且是您真正关心的问题，我肯定会坚持使用选项 #1 或 #3。其中哪一个？这实际上取决于一些问题：

  • 您是否需要任何其他版本控制功能，或者只是为了避免意外覆盖/删除？
  • 版本控制带来的额外成本是否负担得起？
  • Amazon Glacier is optimized for data that is infrequently accessed and for which retrieval times of several hours are suitable.这适合你吗？

除非您的存储使用量真的很大，否则我会坚持使用存储桶版本控制。这样，您将不需要任何额外的代码/工作流程来将数据备份到 Glacier、其他存储桶甚至任何其他服务器（恕我直言，这确实是一个糟糕的选择，请忘记它）。

于 2013-07-24T16:20:51.487 回答
16

如何在 S3 存储桶本身上使用现成的跨区域复制功能？以下是有关该功能的一些有用文章

于 2016-10-14T00:51:27.267 回答
15

您可以使用以下方法备份 S3 数据

  1. 使用 AWS 数据管道计划备份过程，可以通过以下两种方式完成：

    一个。使用 datapipeline 的 copyActivity，您可以使用它从一个 s3 存储桶复制到另一个 s3 存储桶。

    湾。使用数据管道的 ShellActivity 和“S3distcp”命令将递归 s3 文件夹从存储桶递归复制到另一个存储桶（并行）。

  2. 在 S3 存储桶内使用版本控制来维护不同版本的数据

  3. 使用冰川备份您的数据（当您不需要将备份快速恢复到原始存储桶时使用它（由于数据以压缩格式存储，需要一些时间从冰川中取回数据）或当您想要保存时通过避免使用另一个 s3 存储桶来备份一些成本），可以使用您要备份的 s3 存储桶上的生命周期规则轻松设置此选项。

选项 1 可以为您提供更高的安全性，假设您不小心删除了原始 s3 存储桶，另一个好处是您可以将备份存储在另一个 s3 存储桶的日期文件夹中，这样您就可以知道您在特定日期拥有哪些数据并且可以恢复特定日期的备份。这完全取决于您的用例。

于 2014-11-07T17:59:50.877 回答
10

您会认为现在有一种更简单的方法可以在差异区域上保存某种增量备份。

上述所有建议都不是真正简单或优雅的解决方案。我真的不认为冰川是一种选择，因为我认为这更像是一种存档解决方案，而不是一种备份解决方案。当我想到备份时，我认为初级开发人员的灾难恢复递归地删除了一个存储桶，或者可能是您的应用程序中从 s3 删除内容的漏洞利用或错误。

对我来说，最好的解决方案是一个脚本，它只将一个存储桶备份到另一个区域，每天一个，每周一个，这样如果发生可怕的事情，你可以切换区域。我没有这样的设置，我已经调查过了，只是还没有开始这样做，因为这样做需要一些努力，这就是为什么我希望有一些库存解决方案可以使用。

于 2014-12-14T04:47:00.037 回答
8

虽然这个问题是前段时间发布的，但我认为在其他解决方案中提及MFA 删除保护很重要。OP 正在尝试解决意外删除数据的问题。多因素身份验证 (MFA) 体现在两种不同的场景中 -

  1. 永久删除对象版本 - 在存储桶的版本控制上启用 MFA 删除。

  2. 意外删除存储桶本身 - 设置存储桶策略，拒绝在没有 MFA 身份验证的情况下删除。

与跨区域复制和版本控制相结合，以降低数据丢失的风险并改善恢复场景。

这是有关此主题的博客文章，其中包含更多详细信息。

于 2018-06-16T12:56:28.063 回答
1

由于这个主题是很久以前创建的并且仍然非常实际，这里有一些更新的消息：

外部备份

没有任何改变，您仍然可以使用 CLI 或任何其他工具在其他地方（在 AWS 内外）安排副本。

有工具可以做到这一点，以前的答案非常具体

“内部”备份

S3 现在支持以前版本的版本控制。这意味着您可以正常创建和使用存储桶，并让 S3 管理同一存储桶中的生命周期。

如果您删除文件，可能的配置示例如下：

  1. 标记为已删除的文件（仍然可用，但对正常操作“不可见”）
  2. 文件在 7 天后移至 Glacier
  3. 30 天后删除文件

您首先需要激活版本控制，然后转到生命周期配置。非常简单：仅限以前的版本，删除是您想要的。 S3 生命周期面板

然后，定义您的策略。您可以根据需要添加任意数量的操作（但每次转换都会花费您）。您不能在 Glacier 中存储少于 30 天。 S3 生命周期操作面板

于 2021-01-26T10:43:26.000 回答
1

如果，我们有太多的数据。如果您已经有一个存储桶，那么第一次同步将花费太多时间，就我而言，我有 400GB。第一次用了3小时。所以我认为我们可以使副本成为 S3 Bucket 备份的一个很好的解决方案。

于 2019-11-23T06:52:24.530 回答