Amazon EC2 备份策略

Question

我有几个使用 Amazon EC2 的 Web 服务器/数据库服务器设置。我目前正在拍摄我所有系统和 EBS 驱动器的每日快照，其中包含我的所有应用程序文件、数据库文件、源代码和数据库备份。我有一个按计划运行备份创建的控制台应用程序。我的图像是 EBS 图像。

我正在执行一项任务，该任务将在这么多天后删除我的快照。我想我的问题是，我也应该/可以安排一个完整的图像/EBS 任务吗？这样，如果服务器出现故障或损坏，我可以启动最新的图像，然后应用最新的快照。

在我制定备份策略时，我使用 Jungle Disc 来备份我的数据光盘。

Answer 1

我的建议：

始终对每个新实例的设置进行记录和/或编写脚本，以便您可以在丢失实例时重现软件安装和系统配置。通过启动一个新实例并按照过程进行测试。如果安装需要很长时间并且您需要快速启动实例，您可以使用自定义的私有 AMI，但该 AMI 本身应该使用记录和/或脚本化的过程构建。
将您的重要数据保存在单独的 EBS 卷上，而不是保存在根 EBS 卷上。这有很多好处，包括可以更轻松地将数据移植到新实例（例如，基于不同的 AMI），以及更轻松地获取其他实例上的数据副本（例如，使用快照和新卷）。
创建 EBS 数据卷的常规快照。如果可能/适用，请使用我的ec2-consistent-snapshot 之类的工具来提高您拍摄一致文件系统/数据库快照的机会。备份 AWS/EC2 之外的数据，因为您的 AWS 账户本身就是一个单点故障。
不时在重要实例上创建根 EBS 卷的快照。尽管这可能会在发生实例或 EBS 卷故障时为您提供帮助，但由于上述 #1 和 #2，该部分并不那么重要。我这样做的主要原因是创建快照可以降低根 EBS 卷本身发生故障的风险。

EBS 卷的故障率与自上次 EBS 快照以来该卷上修改的块数直接相关。

Answer 2

我是否也应该/可以安排完整的图像/EBS 任务？

是的，这是可取的。有一次它救了我，因为由于内核问题我不得不重置很多次，直到启动盘不再可读，我只是从最新的快照启动。

如果您有兴趣，我编写了一个 Java 类来对所有连接的 EBS 卷进行快照，并在一段时间后删除它们。目前，我每周进行一次备份，并在两周后丢弃第三次备份。

它每次运行只执行一个操作，例如拍摄或删除快照，因为它应该每小时放入一个 cron 中，以避免在您像我一样拥有许多 EBS 的情况下同时处理数十个快照而过载。