查询EBS备份实例+备份S3 +快照

Question

我花了几天的时间在亚马逊上建立了两个Windows服务器，一个域控制器和一个远程桌面服务服务器，但有几个问题我找不到详细的或任何答案：

1)当你有一个EBS支持的实例时，我假设这意味着所有的文件(操作系统/应用程序/页面文件)等都存储在EBS上？在数据中心中，假设我有50 OS的操作系统文件/应用程序数据等，这些文件/应用程序数据是否全部存储在一个SAN类型的设备上？如果设备爆炸，或者说特定的数据中心被摧毁，会发生什么？数据在别处吗？你的整个EBS音量消失的概率是多少？

2)据我所知，您可以通过快照将EBS实例备份到S3。我假设你可以选择快照的频率(比如每天？)。在我上面的场景中，如果我有50 In的文件，并且一天一次快照。在7天内，我的S3存储是350 50，还是我在一周内所做的50 50以上的增量更改？

3)我记得在某处读到过实例必须离线到快照。如果是这样，它是通过关闭来宾操作系统、拍摄快照然后重新启动来执行此操作，还是只是分离数据，阻止您在拍摄快照时进行连接，然后将其恢复到拍摄快照之前的确切时刻。

4)我理解每月支付每am空间的概念，但我如何关注每100万I/O请求0.11美元。当我运行windows服务器时，它是如何工作的？我不知道一台服务器向其磁盘发出了多少I/O请求。我假设整个VM的很多内容都存储在EBS卷上。在标准的EBS上运行服务器会从根本上减慢它的速度吗？

5)人们是否将快照用作S3的主要备份?人们是否正在运行其他类型的数据备份？

对于新手提出的问题，我深表歉意--如果任何人能给我提供部分答案、答案或建议，我将不胜感激。提前感谢！

Answer 1

1)亚马逊在这一点上是模糊的。他们说，数据是在其所属的可用区内复制的，如果自上次快照以来更改的数据少于20 it，则每年的故障率约为0.1-0.4%

2)快照以手动方式触发，并以增量方式完成

3)取决于您的文件系统。例如，在具有xfs卷的linux计算机上，您可以冻结对该卷的IO，执行快照(只需一秒钟左右)，然后解冻。如果您在没有执行类似操作的情况下拍摄快照，您将面临数据处于不一致状态的风险。这将取决于您的文件系统

4)我所有的实例都在EBS上运行。您可能不希望将页面文件放在EBS上，因此使用实例存储会更有意义。您使用的IO数量将非常依赖于工作负载。IO计数在很大程度上取决于您的工作负载-例如，应用程序服务器的IOPs要比数据库服务器少得多。如果您运行的是特别繁重的IO操作，那么您不太可能每月使用超过几美元的每个卷

5)就我个人而言，我不关心安装的软件/配置(我有AMI和所有的设置，所以我可以在几分钟内恢复)，我只关心数据。我分别备份这些数据(S3和Glacier)。部分原因是我被EBS大约一年前的一个bug咬到了，他们丢失了一些快照

正如Fantius所评论的那样，你也可以使用多种策略。例如，在我运行的mongodb服务器上，启动卷很小(并且从来没有快照或备份，因为它可以从AMI自动恢复)，具有包含实际mongodb数据的单独数据卷。mongodb卷是快照，并在S3上存储转储。快照是创建备份的有效方法(因为您只存储增量更改)，但是您不能将它们传输到您的EC2区域之外，而S3上的tarball可以很容易地复制到任何地方。