Amazon EC2 EBS 备份：AMI 与快照答案

【问题标题】：Amazon EC2 EBS backup: AMI vs SnapshotAmazon EC2 EBS 备份：AMI 与快照
【发布时间】：2012-11-29 20:04:20
【问题描述】：

我正在尝试为我们的服务器创建备份机制，这样如果我的系统崩溃，我应该能够通过运行单个脚本来创建整个系统

通过亚马逊文档，这是我对创建备份和恢复的理解

备份

恢复（一个脚本）

现在我的问题是

【问题讨论】：

【解决方案1】：

由于找不到更好的选择，我坚持最初的方法。

备份：

例如存储，我只保留应用程序（没有数据库），所以不需要保留它的备份。

【讨论】：

【解决方案2】：

EBS 快照是创建备份的绝佳方式。

您可以通过脚本执行 EBS 卷的频繁快照。每周、每天、每小时或您的信用卡允许的频率。唯一的限制是您可以同时执行多少个快照 - 当您达到该限制时，EBS API 将开始返回错误，直到一些正在进行的操作完成。

快照也可以从一个区域复制到另一个区域，以便为灾难性事件提供备份。

当您对 EBS 卷进行快照时，该快照是整个卷的快照。即使它是从 AMI 创建的，您的快照也包含创建卷的新实例所需的一切。你可以很容易地自己尝试一下。

【讨论】：

【解决方案3】：

我建议在 EBS 快照之外使用 Auto Scaling。如果实例因硬件故障而死亡或亚马逊计划停用，Auto Scaling 将自动启动新实例。

但在这种情况下，您必须为您的动态数据设置 NAS。根据服务器负载，正在运行的实例的数量会有所不同，并且您的所有扩展服务器都必须安装在它们之间共享的 NAS 存储。

您的数据库也应该位于单独的服务器或服务器上。或者您可能想使用Amazon RDS，因为它具有出色的自动备份/时间点恢复功能，但您必须为此支付额外费用。

【讨论】：

【解决方案4】：

如果您的实例基于 Linux，则在拍摄快照时无需创建 AMI。您可以在需要恢复时从快照中动态创建 AMI。如果您使该过程自动化，则很容易做到。

【讨论】：

我在尝试恢复时学到的一些东西：记下原始实例的内核 ID。您可能需要使用相同的内核启动未来的 AMI，否则它可能无法启动。其他可能有用的元数据是任何用户数据、安全组、辅助 IP、实例类型和架构。您可以将部分数据存储在快照的描述或标签中。
@MartijnHeemels 唯一的问题是注意内核 ID 是它们在不同区域之间是不一样的 - 所以如果你将快照复制到不同的区域，它会更复杂：/。。跨度>
为什么这是 linux 特有的？ windows不能用同一个进程吗？
@ScottWilleke 显然它并不适用于所有 Linux 风格。 “一些 Linux 发行版，例如 Red Hat Enterprise Linux (RHEL) 和 SUSE Linux Enterprise Server (SLES)，使用与 AMI 关联的 EC2 计费产品代码来验证包更新的订阅状态。从 EBS 快照创建 AMI 不会维护此计费代码以及从此类 AMI 启动的后续实例将无法连接到包更新基础架构。同样，尽管您可以从快照创建 Windows AMI，但您无法从 AMI 成功启动实例。"

【解决方案5】：

1) 是的。快照是备份和恢复 EBS 卷的最佳方式。

2) 取决于，如果您将根卷作为 EBS 支持的 AMI，那么您也可以对它们进行快照并提高可管理性

3) Rsync 和 AMI 是可用于实例存储的选项

【讨论】：