我有几个使用 Amazon EC2 的 Web 服务器/DB 服务器设置。我目前正在每天拍摄所有系统和 EBS 驱动器的快照，其中包含我的所有应用程序文件、DB 文件、源代码和 DB 备份。我有一个控制台应用程序，可按计划运行备份创建。我的图像是 EBS 图像。
我正在执行一项任务，该任务将在很多天后删除我的快照。我想我的问题是，我是否应该/也可以安排一个完整的映像/EBS 任务？这样，如果服务器发生故障或损坏，我只需启动最新的映像，然后应用最新的快照即可。
当我制定备份策略时，我正在使用 Jungle Disc 来备份我的数据光盘。
答案1
我的建议：
始终记录和/或编写每个新实例的设置脚本，以便在丢失实例时可以重现软件安装和系统配置。通过启动新实例并按照程序进行测试。如果安装需要很长时间并且您需要快速启动实例，则可以使用自定义私有 AMI，但该 AMI 本身应使用记录和/或脚本程序进行构建。
将重要数据保存在单独的 EBS 卷上，而不是根 EBS 卷上。这样做有很多好处，包括可以更轻松地将数据移植到新实例（例如，基于不同的 AMI），以及更轻松地在其他实例上获取数据的副本（例如，使用快照和新卷）。
创建 EBS 数据卷的定期快照。如果可能/适用，请使用我的ec2 一致快照以提高您拍摄一致文件系统/数据库快照的机会。备份 AWS/EC2 之外的数据，因为您的 AWS 账户本身就是单点故障。
在重要实例上不时创建根 EBS 卷的快照。虽然这可能在实例或 EBS 卷发生故障时有所帮助，但由于上述第 1 点和第 2 点，这部分并不那么重要。我这样做的主要原因是创建快照可以降低根 EBS 卷本身发生故障的风险。
EBS 卷的故障率与自上次 EBS 快照以来该卷上修改的块数直接相关。
答案2
我也应该/可以安排完整的图像/EBS 任务吗？
是的，这是明智的。有一次它救了我，因为内核问题我不得不多次重置，直到启动盘不再可读，我才从最新的快照启动。
如果您感兴趣的话，我编写了一个 Java 类来对所有连接的 EBS 卷进行快照，并在一段时间后删除它们。目前我每周进行一次备份，两周后丢弃第三次备份。
它每次运行只执行一项操作，例如拍摄或删除快照，因为它意味着每小时放入一个 cron 中，以避免在您像我一样拥有许多 EBS 的情况下同时处理数十个快照而导致过载。
答案3
我们使用简单但功能强大的备份策略：基于每天运行两次的 EC2 EBS 实例创建新的 AMI，并删除“旧”AMI。通过 API（CreateImage），您可以设置标志，在创建新 AMI 时不重新启动实例，或者，如果您使用软件 raid – 在 CreateIImage API 调用之前通过 ssh 连接到实例，并在新内核上使用最流行的文件系统上的“fsfreeze”冻结文件系统，或者如果您使用较旧的内核和 xfs，则使用 xfs_freeze。
创建的“备份”AMI 会记住所有连接到原始运行实例 EBS 磁盘的内容（通过指向创建的快照的链接），并且在使用具有多个磁盘的软件 raid 的情况下，只需一个 API 调用或通过 Web 界面即可在任何 AZ 中恢复新实例。