基于快照的 S3 存储桶备份解决方案 [关闭]答案

【问题标题】：Snapshot based S3 bucket backup solution [closed]基于快照的 S3 存储桶备份解决方案 [关闭]
【发布时间】：2020-08-17 09:11:31
【问题描述】：

我正在尝试为我的 AWS S3 存储桶中的一些重要数据构建备份系统。我探索的选项之一是可以将单个对象恢复到早期状态的版本控制。这在意外删除的情况下肯定会有所帮助。

但这里的问题是由于引入了一些错误的代码或类似的东西而发生数据损坏的情况，为了将系统恢复到较早的状态，除了需要适当的基于快照的备份解决方案之外版本控制。这在整个存储桶被意外删除，或者版本控制被关闭并且一些数据后来被删除的情况下也有帮助。

我正在考虑的当前选项是使用 EC2 实例每天或以预定义的时间间隔将数据复制到本地驱动器（使用 aws s3 sync 或 aws s3 cp），然后将其在特定日期文件夹下上传到另一个 S3桶。我正在考虑维护一个生命周期规则以在一周后使备份过期。不过我认为这不是很有效，因为随着应用程序的流量增加，这些存储桶可以容纳大约 100GB 的数据。

如果这是正确的继续方式，或者是否有一些 S3 或 AWS 功能可用于简化此操作，我希望有人可能已经做过类似的事情进行验证。

【问题讨论】：

您可以使用 S3 复制将对象复制到同一区域内或跨区域内的另一个存储桶中。
通过复制，我认为数据损坏也会被实时复制。
我认为您的问题更多是检测损坏而不是从那里恢复。越早检测到损坏，恢复解决方案就越快速、轻松和简单。只需尝试实施一种快速的方法来检测数据何时损坏，并且使用 S3 版本控制您可以返回到最早的稳定版本。您是否希望随着时间的推移在存储桶中拥有相同的文件？因为如果不是这样，那么版本控制可能不是最好的。您保留随时间变化的事物的版本，但不保留按时间创建和删除的事物的版本。
我不认为检测损坏是识别所有可能的用例并实施的那么简单。这可能只是代码中未经测试的场景，可能会弄乱数据。但即便如此，有一个防御策略是好的，尽管在需要时对关键数据进行昂贵的处理。

标签： amazon-web-services amazon-s3 amazon-ec2

【解决方案1】：

传统上，备份用于存储设备损坏的情况。但是，Amazon S3 会自动将数据复制到多个存储设备，因此需要注意耐用性。

对于数据损坏（例如应用程序破坏文件的内容），Versioning 是最佳选择，因为无论对象是否被更新（覆盖），S3 都会保留对象的先前版本。 Object Lifecycle Management 可用于在一定数量的版本或给定时间段后删除版本。

如果您担心版本控制可能被关闭（暂停）或整个存储桶被意外删除，您可以使用S3 replication 复制存储桶的内容到另一个桶。另一个存储桶甚至可以位于不同的区域或不同的 AWS 账户，这意味着主账户中的任何人都无权删除辅助（复制）账户中的数据。这是确保关键业务数据不丢失的常见做法。

如果您希望能够将多个对象恢复到某个时间点（“将系统恢复到较早的状态”），您可以使用支持 S3 的传统备份软件。例如，MSP Backup (formerly CloudBerry Lab) 的备份软件可以在 S3 存储桶和本地存储之间（或仅在 S3 内）移动数据，并具有正常的时间点恢复功能。

【讨论】：

感谢您的回复。如果我不能随意使用外部应用程序，您认为我建议的方式（使用 EC2）也可以吗？
就个人而言，这听起来不是一个聪明的主意。您将构建一个功能不如 S3 自身提供的解决方案。如果您的主要要求是“在特定时间点恢复所有对象”，您可以编写几行 Python 来遍历 S3 对象，查看每个版本化文件的日期，然后恢复那些特定版本。比在耐用性较低的存储介质（Amazon EBS，与 Amazon S3 相比）中制作更多数据副本要容易得多，需要更多的运营开销。
另外如果bucket包含数百万的数据，你还会推荐这个吗？如果我只恢复每个对象的最新版本，我最好使用 AWS Glue 之类的管道来定期存储备份。
AWS Glue 非常适合处理和转换数据流。我认为它不适用于管理数据备份。如果有的话，存储桶中的对象越多，使用版本控制的理由就越多，因为与必须定期备份这么多文件相比，在给定的时间段内，一小部分文件会发生变化。
这取决于您实际想要实现的目标。我怀疑您是否会想要删除这么多对象只是为了回到代表某个时间点的状态。这意味着您正在删除可能无法再次取回的数据。一个选项可能是能够在该时间点将特定对象“回滚”到所需版本，或者您可能希望在另一个存储桶中填充该时间点的所有对象。如果这是您绝对想要的功能，我建议您花几美元购买一个了解如何执行此操作的备份系统应用程序。