我正在寻找一些建议或最佳实践来备份S3存储桶。
从S3备份数据的目的是为了防止由于以下原因造成的数据丢失：
经过调查后，我看到以下选项：
我应该选择什么选项？仅在S3上存储数据有多安全？想听听您的意见。
一些有用的链接：
Answers:
最初发布在我的博客上：http : //eladnava.com/backing-up-your-amazon-s3-buckets-to-ec2/
这可以通过利用多个命令行实用程序轻松实现，这些实用程序可以将远程S3存储桶同步到本地文件系统。
s3cmd
最初s3cmd看起来非常有前途。但是，在我巨大的S3存储桶上试用后，它无法缩放，并出现错误Segmentation fault。不过，它在小水桶上确实工作良好。由于它不适用于大型水桶，因此我开始寻找替代方法。
s4cmd
的更新，多线程替代品s3cmd。看起来更加有希望，但是，我注意到它一直在重新下载本地文件系统上已经存在的文件。这不是我从sync命令期望的行为。它应该检查远程文件是否已经在本地存在（哈希/文件大小检查会很整洁），并在同一目标目录上的下一次同步中跳过它。我打开了一个问题（bloomreach / s4cmd /＃46）报告了这种奇怪的行为。同时，我开始寻找另一种选择。
awscli
然后我发现awscli。这是Amazon的官方命令行界面，用于与其不同的云服务（包括S3）进行交互。
它提供了一个有用的同步命令，可以快速轻松地将远程存储桶文件下载到本地文件系统。
$ aws s3 sync s3：//您的存储桶名称/ home / ubuntu / s3 /您的存储桶名称/
方便地，sync如果源文件夹（S3存储桶）中缺少文件，该命令将不会删除目标文件夹（本地文件系统）中的文件，反之亦然。这是备份S3的理想选择-如果文件从存储桶中删除，则重新同步它不会在本地删除它们。而且，如果您删除本地文件，则也不会从源存储桶中删除该文件。
让我们从安装开始awscli。有几种方法可以做到这一点，但是，我发现最容易通过安装它apt-get。
$ sudo apt-get install awscli
接下来，我们需要通过创建用户并附加AmazonS3ReadOnlyAccess策略awscli，使用您必须从IAM获取的访问密钥ID和秘密密钥进行配置。这也将阻止您或获得这些凭据访问权限的任何人删除您的S3文件。确保输入您的S3区域，例如。us-east-1
$ aws配置
让我们准备本地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作业，以使存储桶的本地副本保持最新。
继续在中创建sync.sh文件/home/ubuntu/s3：
$ nano /home/ubuntu/s3/sync.sh
将以下代码复制并粘贴到sync.sh：
＃！/ bin / sh
＃回显当前日期和时间
回声'-----------------------------'
日期
回声'-----------------------------'
回声''
＃回声脚本初始化
echo'正在同步远程S3存储桶...'
＃实际运行sync命令（将{BUCKET_NAME}替换为您的S3存储桶名称）
/ usr / bin / aws s3 sync s3：// {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /
＃回声脚本完成
回显“同步完成”
确保在脚本中两次用您的S3存储桶名称替换{BUCKET_NAME}。
专家提示：您应该使用
/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通过编写命令来告诉我们运行脚本的频率以及脚本在本地文件系统上的位置。该命令的格式如下：
mh dom mon dow命令
以下命令配置crontab为sync.sh每小时运行一次脚本（通过minute：0和hour：*参数指定），并使其通过管道将脚本的输出传递到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的容量。
awscli支持在aws s3 sync命令中自动同步此内容。看来您可能必须手动执行此操作。
考虑到相关链接（该链接解释为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，其他存储桶甚至任何其他服务器（恕我直言，这是一个糟糕的选择，请不要理会）。
您可以使用以下方法备份S3数据
使用AWS datapipeline安排备份过程，可以通过以下两种方式完成：
一种。使用datapipeline的copyActivity，可以使用它从一个s3存储桶复制到另一个s3存储桶。
b。使用ShellActivity of datapipeline和“ S3distcp”命令将递归s3文件夹的递归副本从存储桶复制到另一个（并行）。
在S3存储桶中使用版本控制来维护不同版本的数据
使用冰川来备份数据（当您不需要将备份快速恢复到原始存储桶时（由于数据以压缩格式存储，这需要一些时间从冰川中取回数据），请使用冰川）通过避免使用另一个s3存储桶来进行备份以节省一些费用），可以使用要备份的s3存储桶上的生命周期规则轻松设置此选项。
如果您不小心删除了原始的s3存储桶，则选项1可以为您提供更高的安全性，另一个好处是，您可以将备份存储在另一个s3存储桶的按日期排序的文件夹中，这样您就可以知道特定日期的数据，并且可以恢复特定日期的备份。这完全取决于您的用例。
如何在S3存储桶本身上使用随时可用的跨区域复制功能？这是有关此功能的一些有用的文章
您可能会认为，现在将有一种更简单的方法来仅将某种增量备份保存在差异区域中。
以上所有建议并非真正简单或优雅的解决方案。我真的不认为冰川是一种选择，因为我认为更多的是存档解决方案，而不是备份解决方案。当我考虑备份时，我认为来自初级开发人员的灾难恢复将递归删除存储桶，或者可能是应用程序中的漏洞利用或bug从s3中删除了东西。
对我来说，最好的解决方案是只将一个存储桶每天一次和每周一次备份到另一个区域的脚本，这样，如果发生可怕的事情，您可以只切换区域。我没有这样的设置，我调查了还没做完，因为这样做会花费一些精力，这就是为什么我希望可以使用一些库存解决方案。