Amazon EC2备份策略

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

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

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

我的建议：

1. 始终记录和/或脚本化每个新实例的设置，以便在丢失实例的情况下可以重现软件安装和系统配置。通过启动新实例并按照以下步骤进行测试。如果安装需要很长时间，并且需要快速启动实例，则可以使用自定义的专用AMI，但是AMI本身应该使用记录和/或编写脚本的过程来构建。

2. 将重要数据保留在单独的EBS卷上，而不是在根EBS卷上。这具有许多好处，包括使您更容易将数据移植到新实例（例如，基于不同的AMI），以及使在其他实例上获取数据的副本（例如，使用快照和新卷）更加容易。

3. 创建EBS数据卷的常规快照。如果可能/适用，请使用ec2-consistent-snapshot之类的工具来提高对一致的文件系统/数据库进行快照的机会。由于您的AWS账户本身就是一个单点故障，因此需要在AWS / EC2之外备份数据。

4. 在重要实例上不时创建根EBS卷的快照。尽管这可能在实例或EBS卷失败的情况下为您提供帮助，但是由于上面的＃1和＃2，该部分并不是很关键。我这样做的主要原因是创建快照可以减少根EBS卷本身发生故障的风险。

自上次EBS快照以来，EBS卷的失败率与该卷上已修改的块数直接相关。

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

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

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

https://github.com/stivlo/obliquid-cp/blob/master/src/main/java/org/obliquid/sherd/runner/RequestSnapshots.java

它每次运行仅执行一项操作，例如拍摄或删除快照，因为它打算每小时放置一次cron，以避免在您拥有多个EBS的情况下同时加载数十个快照。

我们使用简单但功能强大的备份策略：在一天运行两次EC2 EBS实例的基础上创建新的AMI，然后删除“旧” AMI。通过API（CreateImage），您可以将标志设置为在创建新的AMI时不重新启动实例，或者，如果您使用软件RAID – ssh调用CreateIImage API之前的实例，并在新内核的大多数流行文件系统上使用“ fsfreeze”冻结文件系统，或者在使用xfs_freeze时冻结文件系统您使用较旧的内核和xfs。

创建的“备份” AMI会记住所有连接到原始正在运行的实例EBS磁盘的信息（通过链接到创建的快照），并且如果对多个磁盘使用软件RAID，则只需一个API调用或通过Web即可在任何可用区中还原新实例。 -接口。