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. 备份到亚马逊冰川http://aws.amazon.com/en/glacier/
4. 备份到生产服务器,它本身已备份

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

• 数据保护文档
• 数据保护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存储桶
• 多线程 - 利用多个线程更快地同步文件
• 智能 - 仅同步新文件或更新文件
• 快速 - 得益于其多线程特性和智能同步算法

意外删除

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

在Ubuntu 14.04 LTS上设置awscli

让我们从安装开始吧awscli.有几种方法可以做到这一点,但是,我发现通过它安装它最简单apt-get.

$ sudo apt-get install awscli

组态

接下来,我们需要awscli使用我们的访问密钥ID和密钥进行配置,您必须通过创建用户并附加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环境中执行命令,并且无法自己找到可执行文件.

接下来,确保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然后按Enter键将文件保存到磁盘.然后nano按Ctrl + X退出.crontab现在将每小时运行同步任务.

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

搞定!您的S3存储桶现在每小时自动同步到您的EC2服务器,您应该很高兴.请注意,随着时间的推移,随着S3存储桶变大,您可能需要增加EC2服务器的EBS卷大小以容纳新文件.您可以按照本指南随时增加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存储桶上使用现成的跨区域复制功能？以下是一些有关该功能的有用文章

• 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 4

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

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

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

   湾 使用数据管道的ShellActivity和"S3distcp"命令来执行从存储桶到另一个(并行)的递归s3文件夹的递归复制.

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

3. 使用冰川备份您的数据(使用它时,你并不需要快速恢复备份到原来的桶(它需要一段时间才能从冰川取回数据作为数据存储在压缩格式),或者当您要保存通过避免在备份时使用另一个s3存储桶来节省一些成本,可以使用要备份的s3存储桶上的生命周期规则轻松设置此选项.

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

Answer 5

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

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

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

Answer 6

虽然这个问题是在不久前发布的，但我认为必须在其他解决方案中提及MFA删除保护。OP正在尝试解决意外删除数据的问题。多因素身份验证（MFA）体现在以下两种不同的情况下-

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

2. 意外删除存储桶本身-设置存储桶策略，以拒绝未经MFA身份验证的删除。

结合跨区域复制和版本控制，可以降低数据丢失的风险并改善恢复方案。

这是有关此主题的博客文章，更详细。