AWS S3存储桶的备份策略

Question

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

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

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

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

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

• Data Protection Documentation
• Data Protection FAQ

Answer 1

  

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

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

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

s3cmd
起初，s3cmd看起来非常有希望。但是，在我的巨大S3存储桶上尝试它之后 - 它无法扩展，错误输出Segmentation fault。不过，它在小型水桶上运行良好。由于它不适用于大型水桶，我开始寻找替代方案。

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

awscli
然后我找到了awscli。这是亚马逊的官方命令行界面，用于与包括S3在内的不同云服务进行交互。

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

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

优点：

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

意外删除

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

在Ubuntu 14.04 LTS上设置awscli

让我们先安装awscli。有several ways这样做，但是，我发现最容易通过apt-get进行安装。

$ sudo apt-get install awscli

配置

接下来，我们需要使用我们的访问密钥ID＆amp; amp;来配置awscli。密钥，您必须通过创建用户并附加 AmazonS3ReadOnlyAccess 政策从IAM获取。这也会阻止您或获得这些凭据访问权限的任何人删除您的S3文件。确保输入您的S3区域，例如us-east-1。

$ aws configure

制备

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

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

初始同步

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

$ aws s3 sync s3://{BUCKET_NAME} /home/ubuntu/s3/{BUCKET_NAME}/

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

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

设置Cron作业

继续在sync.sh中创建/home/ubuntu/s3文件：

$ nano /home/ubuntu/s3/sync.sh

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

中

#!/bin/sh

# Echo the current date and time

echo '-----------------------------'
date
echo '-----------------------------'
echo ''

# Echo script initialization
echo 'Syncing remote S3 bucket...'

# Actually run the sync command (replace {BUCKET_NAME} with your S3 bucket name)
/usr/bin/aws s3 sync s3://{BUCKET_NAME} /home/ubuntu/s3/{BUCKET_NAME}/

# Echo script completion
echo 'Sync complete'

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

  

专家提示：您应该使用/usr/bin/aws链接到aws二进制文件，因为crontab在有限的shell环境中执行命令并赢得“{1}}能够自己找到可执行文件。

接下来，请务必chmod脚本，以便crontab执行该脚本。

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

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

$ /home/ubuntu/s3/sync.sh

输出应该类似于：

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

$ crontab -e

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

同步频率

我们需要通过编写命令告诉crontab运行脚本的频率以及脚本驻留在本地文件系统的位置。此命令的格式如下：

m h  dom mon dow   command

以下命令将crontab配置为每小时运行sync.sh脚本（通过分钟：0和小时：*参数指定）并将脚本的输出传递给sync.log目录中的s3文件：

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

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

  

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

全套！您的S3存储桶现在每小时自动同步到您的EC2服务器，您应该很高兴。请注意，随着时间的推移，随着S3存储桶变大，您可能需要增加EC2服务器的EBS卷大小以容纳新文件。您可以按照this guide。

随时增加您的EBS卷大小

Answer 2

考虑到相关链接，这解释了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，其他存储桶，甚至任何其他服务器（这是一个糟糕的选择恕我直言，请忘记它）。

Answer 3

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

1. 使用AWS datapipeline安排备份流程，可以通过以下两种方式完成：

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

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

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

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

选项1可以为您提供更多安全性，以防您意外删除原始s3存储桶，另一个好处是您可以将备份存储在另一个s3存储桶中的datewise文件夹中，这样您就可以知道特定数据日期并可以恢复特定日期备份。这一切都取决于你的用例。

Answer 4

您认为现在可以更轻松地在diff区域上进行某种增量备份。

上述所有建议都不是简单或优雅的解决方案。我并不认为冰川是一种选择，因为我认为更多的是档案解决方案，而不是备份解决方案。当我认为备份时，我认为来自初级开发人员的灾难恢复会递归地删除存储桶或者应用程序中的漏洞或漏洞，从而删除s3中的内容。

对我来说，最好的解决方案是将一个桶备份到另一个区域的脚本，每天一个，每周一个，这样如果发生可怕的事情，你可以切换区域。我没有这样的设置，我已经调查过没有做过这样的事情，因为这需要花费一些力气才能做到这一点，这就是为什么我希望有一些股票使用的解决方案。

Answer 5

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

• https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/
• http://docs.aws.amazon.com/AmazonS3/latest/UG/cross-region-replication.html

Answer 6

虽然这个问题是在不久前发布的，但我认为用其他解决方案提及MFA delete保护非常重要。 OP正试图解决意外删除数据的问题。多因素身份验证（MFA）在这里表现为两种不同的情况 -

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

2. 意外删除存储桶本身 - 设置存储桶策略拒绝删除而不进行MFA身份验证。

与cross-region replication和versioning结合使用，以降低数据丢失的风险并改善恢复方案。

以下是关于此主题的blog post，其中包含更多详细信息。

Answer 7

由于这个话题是很久以前创建的并且仍然很实际，这里有一些更新的新闻：

外部备份

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

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

“内部”备份

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

一个可能的配置示例，如果你删除一个文件，将是：

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

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

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

Answer 8

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