亚马逊 EBS 快照的困惑答案

【问题标题】：Confusion over EBS Snapshots in Amazon亚马逊 EBS 快照的困惑
【发布时间】：2013-10-30 08:08:07
【问题描述】：

我对快照如何用作备份有点困惑。我目前正在运行一个脚本，该脚本每晚对我们的 mongo 数据和日志进行快照。但是我看到的信息说快照是增量的，这让我很困惑。它们是增量的吗？如果是这样，哪个是基础，我将如何重置基础？我宁愿每次都拍一张完整的快照。

另外，有人知道自动过期旧快照的方法吗？他们只是不断积累。

【问题讨论】：

建议转移到 dba.stackexchange.com，因为这更像是基础设施而不是编程。
我认为 dba.se 不是正确的站点，因为这似乎与实际数据库无关，而是与 ec2 和 ebs 快照有关。

标签： mongodb amazon-web-services snapshot

【解决方案1】：

每个 EBS 快照都是一个独立的快照，如果将其还原到新卷上，将为您提供一个与快照时存在的卷相同的卷。

但是，快照存储在 S3 中，并且它们的存储方式（以及您为它们的存储付费的方式）是增量的。

Amazon EBS 快照是增量备份，这意味着只会保存设备上自上次快照以来发生更改的块。如果您的设备具有 100 GB 的数据，但自上次快照以来仅更改了 5 GB 的数据，则只有 5 GB 的额外快照数据将存储回 Amazon S3。即使快照是增量保存的，当您删除快照时，只会删除任何其他快照不需要的数据。因此，无论之前删除了哪些快照，所有活动快照都将包含恢复卷所需的所有信息。此外，所有快照的卷恢复时间都相同，提供完整备份的恢复时间和增量备份的空间节省。

^{——http://aws.amazon.com/ebs/}

因此，在幕后，此快照仅包含从先前快照更改的块...但恢复快照并不意味着您必须将增量部分重新组合在一起。 EBS 会在幕后自动为您完成。

假设您有一个 100 GB 的 EBS 卷，快照 A、B 和 C 按此顺序拍摄，并且没有该卷的其他快照。

快照 A 的大小为 100GB（可能更小，因为您从未写入过的空间可能会从快照中删除）。

如果 20GB 发生变化，那么您拍摄快照 B，该快照的大小将是 20GB，但如果您恢复它，生成的卷将包含完整的 100GB，因为它具有指向快照 A 中未更改数据的指针。

然后又更改了 10GB，您拍摄了快照 C。那将是一个 10GB 的快照，其中指向 B 的指针用于先前的数据，而指向 A 的指针则用于其余数据。同样，恢复这个会在您拍摄快照 C 时获得完整卷。

现在，如果您删除快照 B，则在快照 B 中更改但随后在快照 C 中未更改的块将前滚到快照 C，以便您仍然可以在快照 C 处恢复整个卷，并且快照 C 将是 30 GB 的快照。

这是一种过度简化，因为很可能一些相同的块会从 A -> B 和 B -> C 发生变化，使得 C 的最终版本略小于 30 GB，但它确实传达了总体思路。每个快照都独立用于恢复目的，但 EBS 的内部工作仅存储与先前快照的差异，并且您只需为快照包含的数据量支付存储费用。不幸的是，目前无法通过 API 找出每个快照的实际大小，因为这些信息没有公开……它们始终显示为与卷相同的大小。

无法自动清除快照。对于我的系统，我编写了一个每天运行一次的脚本，根据卷的标签查找要快照的卷。然后它会根据我的保留策略考虑哪些卷有足够的快照，并删除任何其他快照——但它只会删除它自己创建的快照，这同样基于快照脚本应用于它创建的快照的标签.

【讨论】：

谢谢。听起来像黑魔法，幕后发生的事情。如果亚马逊为 EBS 建立一个备份设施，就像他们对 RDS 所做的那样，那将是非常好的。然后我将对此进行一些实验。再次感谢您非常彻底的回复。
您还可以查看 Eric Hammond 的 ec2-consistent-snapshot utility。它会在您拍摄快照时冻结您的文件系统，这“应该”为您提供最可靠的快照。与往常一样，请记住，除非您确实使用备份策略成功地进行了测试恢复，否则您实际上并没有备份策略。 :)
啊，是的，我以前见过。结果很糟糕。在我们走得更远之前，将测试整个事情，包括删除快照。再次感谢。
这最终工作正常，至少在测试中。我删除了旧快照，但仍然能够从最近的快照中恢复。如果我将日志移到别处或分片，就不会像销售一样工作。这不是简单的事情。