如何备份aws ec2实例/临时存储？

Question

我的数据库保存在/ mnt，使用ec2实例附带的临时存储。要使用ec2 api工具进行备份，我们需要一个卷标识，但在aws控制台中，我只能找到8gb根存储的卷标识。

如果想要临时存储的备份，我该怎么办？有备份实例存储的替代方法吗？

Answer 1

首先，您应该永远不要在Amazon EC2中存储任何具有持久价值的内容，除非您确切知道自己在做什么，并准备始终有时间点备份等 - 您的问题似乎表示您可能误解了短暂存储的概念，Amazon EC2 Instance Storage和Amazon EBS之间的差异以及对数据安全和备份要求的重大影响：

短暂存储将在停止/启动周期中丢失而通常可以消失，因此您绝对不希望在那里放置任何持久值，即< strong>只将临时数据放在那里，你可以轻易丢失或重建，比如交换文件或计算过程中使用的严格临时数据。当然，您可能会在那里存储大量索引，但必须准备好在因任何原因（实例重新启动，硬件故障，......）清除存储后重建这些索引。

• 这是Eric Hammond在You Should Use EBS Boot Instances on Amazon EC2中出色地总结的众多原因之一，其中概述了两个存储概念的历史和差异，并评估了短暂存储的少数剩余可能的好处（主要是丰富和免费）

问题/解决方案

这些解释应阐明您无法使用仅适用于EBS卷（即EBS快照）的机制备份临时存储卷的原因。因此，您可以通过您选择的常规操作系统级备份工具备份前者，Duplicity是一个受欢迎的选择，可选择促进Amazon S3，例如我对Easiest to use backup software for live linux server的回答。

Answer 2

短暂存储或实例存储，就像一个/ tmp文件夹，其内容在重新启动后消失。当然，短暂的驱动器内容不会在软重启时被破坏，但是它们应该被视为，因为您无法实际控制或预测实例何时决定死亡。

已经指出了这一点。

我想指出的是，如果您正确地创建和配置AMI，您仍然可以使用短暂存储来大幅提高（读取）吞吐量，只要您还将EBS驱动器保留在实际存储中

我目前使用的是带有bcache的Linux（Ubuntu Tahr）实例。这主要是因为bcache内核支持相对较新（IIRC，第一个bcache是​​3.10），你肯定想要尽可能最新的内核。此外，Tahr是Ubuntu的下一个LTS版本，当我的项目接近发布时它是最终的;）

Bcache的默认配置允许您从短暂存储的读取速度中受益，同时为您提供EBS的持久性：它需要一个快速缓存设备（临时SSD）并使用它加速慢速设备（EBS），通过缓存设备写入（即同时写入短暂缓存和EBS）。

这意味着如果实例崩溃或以其他方式停止，您仍然可以直接挂载EBS卷而不使用缓存，并像访问仅使用EBS卷一样访问所有数据。您还可以重新配置现在已擦除的短暂设备，并将它们重新配置为EBS的缓存，以恢复快速读取和搜索。

我的特殊设置是两个EBS设备，使用mdadm +两个短暂的SSD设备以条纹模式进行突袭，也以相同的方式进行搜索。然后我用bcache配置它们，使用短暂的数组作为缓存，将EBS数组作为“备份”设备。 EBS驱动器可以是任何大小，您可以随时扩展它们（EC2有点棘手，因为您必须创建当前EBS卷的快照，然后根据该快照创建新的更大的 - 您无法调整大小现有的EBS卷。）

当然，您必须创建一个在启动时在您的实例内运行的脚本，以配置临时存储并将其作为缓存设备附加到EBS支持的备份设备上。我鼓励您继续阅读mdadm和bcache。

为了记录，使用Cassandra压力工具进行测试，我得到了更好读取性能，其中EBS卷与短暂驱动器相比，而不仅仅是剥离短暂驱动器。这是因为bcache中使用的算法非常聪明。

将短暂的驱动器用作缓存还可以减少网络流量，并且具有成本效益，因为它可以减少EBS上的I / O，从而减少您的月费。

另请注意bcache提供的不同类型的缓存：

1. 回写：使用SSD作为读/写设备，只有在需要从缓存中逐出页面时才写入备份设备。这对于EC2临时设置非常有用，因为它会使您的备份设备在崩溃或停止时无用。
2. 直写：所有写入都同时包含缓存和备份。这可确保备份设备始终与高速缓存设备保持同步，并且始终可以在没有高速缓存设备的情况下使用它。适用于EC2。
3. 写入：所有写入都直接进入备份设备，并且在将来某个时间对该数据发生读取请求之前，不会将其写入缓存设备。只有读取缓存在缓存设备上。这与直写一样安全，如果您知道在不久的将来不可能读取您的写入，则非常有用。这样可以避免使用经常未请求的数据填充缓存设备，从而为 请求的数据提供更多空间。一些示例可以是文件上载服务器，您可以编写大量日志记录数据的系统等。如果您知道整个数据集明显大于短暂存储大小，那么这很可能是最有效的大量使用案例中的选项。

Answer 3

如果您能够配置软件RAID镜像，则可以将EBS支持的磁盘附加到实例，配置镜像，然后等待复制完成。在我创建了实例后，我已成功使用此方法将“短暂”数据移动到EBS中（我不想关闭并重新启动）。

获得EBS数据后，请使用EBS图像进行备份。

当您在不同的相同实例上运行多个数据副本时，此方法特别有效，但您只需将其中一个持久保存到EBS（在我的情况下，使用Couchbase服务器，CB数据在短暂驱动器上，但我有一个镜像到EBS的实例，这样我的集群上的所有数据都以EBS结尾。）

Answer 4

任何文件级备份解决方案（不基于EBS快照）都可以备份临时存储。也就是说，您应该考虑何时使用临时存储，并且有充分的理由将其用于持久数据。 对于某些应用程序，如Cassandra，这是推荐的配置。在这种情况下，您的备份解决方案主要将数据从临时存储转储到将要快照或直接转发到S3的EBS卷。在某些情况下，您可以定义复制并确保临时设备中的所有数据也复制到EBS卷。