一家小型创业公司正在EC2网络上运营他们的业务,并向我询问有关备份选项的一些建议.他们目前是自筹资金,并且在可行的情况下尽其所能地节省成本.如果不深入研究他们系统的配置,我将以Web服务器为例;它是一个带有数据库的简单Web服务器.问题是他们不希望服务器被拆除.
一直在进行设置的人认为他们应该只是定期转储数据库并将其存储在S3上,或创建脚本,以便在需要时通过备份包含配置信息的选择文件夹在Amazon上重建新服务器.他建议创建服务器的快照会很浪费,因为它们需要占用大量磁盘空间,而且大数据转储之间会有数据丢失,因此快照会很快过时.
我的想法是拍摄VM的快照,然后定期转储数据库并存储在S3中.如果他们丢失了EC2实例或者像更新一样使其无法使用,他们可以使用快照使用最新的数据库转储相对快速地备份服务器,而不是从头开始从完全构建新实例新的AMI.
我的理解是,拍摄EC2实例(或EBS商店)的快照将需要停机时间,这是他们犹豫不决的事情.我还读过你应该让服务器关闭,以便在拍摄快照时保持文件系统的一致性.由于它们在平衡器后面没有集群,因此限制了涉及快照的选项.
编写服务器的脚本,除非我不知道特定于亚马逊的东西,否则将涉及创建一个可以在EC2上部署具有相关角色的新服务器的Chef或Puppet服务器.目前,创业公司没有资金来保持这种服务器的优势,而且他们现在并不需要部署那么多服务器.
理想情况下,他们将有资金在虚拟平衡器或亚马逊的平衡器服务后面创建多个服务器,然后逐个删除服务器以执行更新或快照.现在我对进行更新的想法感到紧张,因为如果你正在进行数据库的转储,那么如果系统更新改变了应用程序所依赖的库并且服务出现故障,这将无济于事.
我还认为另一个选择是运行一个创建EBS卷的脚本,安装它,并在服务器上运行类似rsync的东西,将大部分文件系统信息捕获到EBS卷,然后压缩并将内容复制到S3,断开卷并销毁它以节省存储成本,然后进行数据库转储以捕获在其他方面不一致的飞行中数据.对于他们的一些服务器,随着数据库需求的增长,很可能需要保存到临时EBS卷.
正在创建VMWare沙箱,以便在将更新应用到Amazon上的生产系统之前,可以在可以预先测试更新的环境中重新创建其网络系统.我希望这可以最大限度地减少系统更新将杀死他们的应用程序的可能性.
所以…考虑到运行一台服务器的限制,系统上有数据库和应用服务器,希望尽可能接近没有停机时间(限制快照的使用并使备份过程尽可能“热”)(在没有关闭服务器的情况下实时创建),我是否在错误的轨道上建议安排时间在其工作状态下创建EC2实例的快照,并从那里进行数据库转储以复制到S3？是否有更好的策略如果快照会造成停机,那么在创建服务器的实时备份时？
解决方法
有点关于EBS
EBS卷和快照在块级别运行 – 其结果是允许在实例运行时拍摄快照,即使EBS卷正在使用中也是如此.但是,只有实际位于磁盘上的数据(即不在文件高速缓存中)才会包含在快照中.后一个原因产生了一致快照的想法.
>推荐的方法是分离卷,快照它并重新连接它 – 通常不实用.
>下一个最佳选项包括将写缓存刷新到磁盘,冻结文件系统以及拍摄快照
这里有一个有趣的观点是,在上述两种情况下,您都不需要等待快照完成重新挂接/解冻并继续写入磁盘 – 一旦启动快照,您的数据将与该时间点保持一致.通常,这只需要几秒钟,在此期间您的磁盘被写入锁定.此外,由于大多数数据库以合理的方式在磁盘上构建其文件 – 插入很可能对现有块具有最小的影响 – 这最小化了添加到快照的数据.
考虑备份的重点
EBS卷已在可用区内复制 – 因此内置了一定程度的冗余.如果您的实例终止,您只需将EBS卷附加到新实例,并且(在您通过缺乏一致性后)恢复您的位置离开了.在许多方面,这使得EBS卷很像一个不一致的快照,前提是您可以访问它.也就是说,大多数EC2用户可能会回想起2011年初EBS卷的级联故障 – 多天无法访问卷,一些用户也丢失了数据.
RAID1
如果您正在尝试防止EBS磁盘发生故障(确实发生了这种情况),您可以考虑使用RAID1设置.由于EBS卷是块设备,因此您可以轻松使用mdadm将其设置为所需的配置.如果您的某个EBS卷未按规范执行,则很容易手动将其失败(稍后将其替换为另一个EBS卷).当然,这有缺点 – 每次写入的时间增加,对可变性能的敏感性增加,I / O成本增加一倍(monetariliy,而不是性能),没有真正的保护来防止更广泛的AWS故障(去年常见的问题是无法分离处于锁定状态的EBS卷,当然还有磁盘失败时的不一致状态.
S3FS
某些应用程序(绝对不适用于数据库)的选项是将S3安装为本地文件系统(例如,通过s3fs).这很慢,缺少文件系统可能期望的某些功能,并且可能无法按预期运行(最终的一致性).也就是说,出于简单的目的,例如在各实例之间提供上传的文件,它可能有价值.显然,它不适用于任何需要良好读/写性能的东西.
MySQL bin-log
MysqL特有的另一个选项可能是使用bin-log.您可以设置第二个EBS卷来存储bin-log(以最小化添加的写入对数据库的影响),并将其与您采用的任何数据库转储结合使用.您甚至可以使用s3fs执行此操作,如果性能可以容忍,这实际上可能具有优点(虽然rsync可能比直接尝试使用s3fs更好,但您肯定想要压缩你可以做的事情).
但是,我们再一次回到目的的想法.考虑一下上述建议会发生什么：
> EBS卷无法访问：
> RAID1 – 没用,因为你无法获取数据
> bin-log – 没用,除非你将它导出到S3 – 如果你这样做可能会延迟
>实例意外终止：
> RAID1 – 您的磁盘可用但不一致,您的数据库可能会自行恢复不一致
> bin-log – 您的数据应该是可访问的,尽管您可能需要查看最后几个事件
>有人以root身份运行DROP DATABASE：
> RAID1 – 您有两个不存在的数据库的完美副本
> bin-log – 你应该能够在命令之前重放事件,所以你应该没问题
实际上,RAID1几乎没用,而bin-log需要太长时间 – 在某些情况下这两者都有其优点,但远非想法备份.
快照
重要的是要注意快照是差异的,并且只存储包含数据(并且被压缩)的实际块.与EBS卷不同,如果您的容量为20GB,但只使用1GB,则仍需为“预配置”存储(20GB)付费.使用快照,您只需为使用的内容付费.如果快照之间没有数据变化,则(理论上)不收费. (对PUTS / GETS和已用存储器收取快照费用).
顺便说一句,我强烈建议您的应用程序数据(包括数据库)不要存储在根卷上(您可能已经设置过).其中一个优点是,希望您的根卷看到的变化最小 – 这意味着它的快照可以减少频率(或者将进行最小的更改),从而降低成本和易用性.
同样值得一提的是,您可以随时删除旧快照 – 即使它们是差异的,它们也不会影响其他快照.也就是说,在没有仍然引用该块的快照之前,不会放弃分配给快照的每个块.
定期转储的问题首先是转储之间的时间(可能通过使用MysqL的bin-log解决)以及恢复的难度.导入大型转储并从bin-log重放所有事件需要时间.此外,创建转储并非没有性能影响.可以说,这样的转储可能需要比快照更多的存储空间.仅为数据库和快照设置EBS卷,这在大多数方面都是可取的(也就是说,拍摄快照确实会对性能产生影响).
快照和EBS卷的优点在于它们可以在其他实例上使用.如果您的实例无法启动,您可以将根卷连接到另一个实例以诊断并修复问题 – 或者只是将数据从其中复制 – 并且可以仅在几分钟的停机时间内切换根卷(停止实例,分离根卷,附加新的根卷,启动实例).同样的想法适用于将您的数据放在第二个EBS卷上.基本上,您只需从自定义AMI中启动一个新实例,并将当前的EBS卷附加到它 – 它有助于最大限度地减少停机时间.
(人们可以提出这个论点(我可能不会建议)你可以在同一台服务器(主从)上使用两个EBS卷设置两个MysqL副本,然后关闭你的奴隶来拍摄它的快照EBS数量 – 它将是一致的,没有停机时间 – 但性能成本可能不值得).
AWS确实具有自动扩展功能 – 可以维持一定数量的实例(即使该数量为1) – 但是您可以从快照部署 – 所以如果您的快照没用,那么前提是没有多大用处.
另外几点 – 您可以从单个快照部署任意数量的实例(与EBS卷不同,EBS卷只能在任何给定时间附加到单个实例).此外,EBS卷仅限于在可用区内使用,而快照可在区域内使用.
理想情况下,使用快照,如果您的服务器出现故障,您可以使用上一个快照启动一个新的快照 – 特别是如果您将根卷与数据分开,那么错误的更新应该会导致最短的停机时间(因为您只需要传输包含数据的EBS卷 – 并对其进行快照以保留可能因不一致而损坏的任何内容.
作为旁注,亚马逊表示自上次快照以来,EBS卷的失败率随着它们的数据量的变化而增加.
最后的建议
>使用快照 – 它们很棒 – 它们比停止时间更能减少停机时间
>单独的数据和根卷,甚至可能将数据库放在自己的卷上,如有必要,还可以在更新之前创建快照
>使用bin-log保持尽可能“热” – 将此(压缩)上传到S3
>确保实际从实例中获取数据(即使EBS卷上的数据完好无损,卷本身可能暂时无法访问).
推荐阅读：
> Amazon’s page on EBS
> EBS FAQs
(我相信我写的太多了,但说不够 – 但希望你能找到值得一读的东西).
