作为备份策略的可行性将是xen domU的定期LVM快照吗? 赞成,反对,任何陷阱?
对我来说,这似乎是一个快速,无脑的恢复的完美解决scheme。 任何调查都可以在domU成功运行而不中断的情况下在逻辑卷上进行。
编辑:
这是我现在在做完整系统备份的地方。
现在我需要自动化这个。
LVM快照旨在以冻结状态捕获文件系统。 它们本身并不意味着是一个备份。 但是,它们对于获取一致的备份映像非常有用,因为在备份过程中冻结的映像不能也不会更改。 因此,尽pipe您不会直接使用它们来进行长期备份,但在您决定使用的任何备份过程中,这些备份将非常有用。
有几个步骤来实现快照。 首先是必须分配一个新的逻辑卷。 本卷的目的是提供一个logging文件系统增量(变化)的区域。 这允许原始卷继续运行,而不会中断任何现有的读/写访问。 缺点是快照区域的大小是有限的,这意味着在一个忙于写入的系统上,它可以很快填满。 对于有大量写入活动的卷,您将需要增加快照的大小,以留出足够的空间logging所有更改。 如果您的快照溢出(填满),则快照将暂停并被标记为不可用。 如果发生这种情况,您将需要释放快照,以便将原始卷恢复到在线状态。 发行完成后,您将能够以读/写的方式重新挂载卷,并使其上的文件系统可用。
发生的第二件事是LVM现在“交换”了这些卷的真正目的。 你会认为新分配的快照将是寻找文件系统的任何改变的地方,毕竟这是所有写入的地方,对吧? 不,这是相反的。 文件系统被安装到LVM卷名 ,因此从系统其余部分下面交换名称将是一个禁止(因为快照使用不同的名称)。 因此,这里的解决scheme很简单:当您访问原始卷名称时,它将继续引用您执行快照的卷的实时 (读/写)版本。 您创build的快照卷将引用您要备份的卷的冻结 (只读)版本。 一开始有点混乱,但是它会有道理的。
所有这一切发生在不到2秒的时间内。 系统的其他部分甚至没有注意到。 当然,除非在溢出之前不要释放快照。
在某个时候,你会想释放你的快照来回收它占据的空间。 发布完成后,快照卷将被释放回卷中,并保留原始卷。
我不build议把这作为一个长期的备份策略。 您仍然在可能出现故障的同一物理驱动器上托pipe数据,而从发生故障的驱动器恢复文件系统根本不是备份。
所以,简而言之:
LVM快照非常适合在不脱机的情况下备份服务器。 如上所述,LVM快照几乎是即时副本。 您可以使用lvcreate
命令创build它们,就像创buildLV本身一样,只需要给它--snapshot
选项和原始LV而不是VG。 例如:
lvcreate -L <LV size> -s -n <snapshot name> /dev/<VG name>/<LV name>
这将使用指定的快照名称创build给定LV的快照,然后您可以挂载并使用此快照LV执行备份,而无需担心正在使用的文件。 如果您正在尝试备份活动的数据库服务器,这特别有用。
完成快照备份后,您可以删除它,以减less其他I / O开销或其他性能问题,如其他人提到的那样:
lvremove /dev/<VG name>/<snapshot name>
虽然LVM快照在生成诸如数据库之类的系统的可靠备份方面具有无法估量的价值,并且您通常希望closures以进行备份以避免文件争用,但是作为快速恢复的长期操作并不理想。
海事组织不是一个好主意。
快照以写入时复制的方式实现,因此您可以将每个写入操作转换为读取操作并进行两次写入(您要更新的块首先从主卷读取并存储在快照卷中,然后再放入新数据它的地方),所以你会看到一些性能下降,如果大量的写作在虚拟机上很常见。
另外,IIRC,如果快照卷满了,它会被毫不客气地丢弃。 这对于备份目的不好! 因此,如果您尝试将其作为备份方法,请确保将快照卷大到足以处理在快照的有用生命周期内发生的所有更改。 当然,如果您知道并监视了大小问题,并且性能问题对您来说不是问题,那么您build议的操作可能会对您已有的其他备份过程有所帮助。
LVM快照作为备份过程的一部分非常有用(拍摄快照,将快照备份到其他位置以确保备份一致,而不必禁用对“真实”卷的更新,之后放弃快照),识别其他内容,但不是作为自己的备份工具。
在创build快照之前,您需要确保磁盘上的数据处于一致状态。 例如,mysql可能会将数据caching在内存中,需要将其强制转移到磁盘,方法是转储数据库或将其closures。 有关详情,请参阅应用程序手册。
在智能外观之下,LVM实际上只是一个设备映射技巧。 用lvcreate创build一个快照只不过是一些dmsetup的东西。 包装器从一个旧卷(原始lv)和一个新卷(copy-on-write卷)中创build一个新设备(快照卷)。 与此同时,原来的LV被重命名为-real(见下面,这是dmsetup ls –tree的输出)。 这个真正的LV被映射到快照卷和原始卷,所以它可以在两个地方使用。 写入时复制卷作为叠加到真实LV的function。 -snap LV显示了写入时复制音量和真实音量的组合。 这确实造成了一些性能开销。
Volume00-snap (253:11) |-Volume00-snap-cow (253:13) | `- (104:2) `-Volume00-LogVol01-real (253:12) `- (104:2) Volume00-LogVol01 (253:5) `-Volume00-LogVol01-real (253:12) `- (104:2)
删除快照时,再次进行一些重命名和映射。 之后,情况将再次如此
Volume00-LogVol01 (253:5) `- (104:2)
至于在多大程度上,这是一个很好的备份方法:如果考虑到这一点,(1)不会对虚拟机内存产生帮助,(2)造成性能损失,(3)您需要在其他地方存储快照的图像。
VMware VCB也可以和快照一起工作,虽然不是LVM。
即使快照没有任何性能影响,您也必须理解:快照不再是复制到同一磁盘上的另一个文件夹的备份。
如果磁盘刹车,您的数据和备份丢失。 即使将快照区域分配给VG中的另一个PE,也只包含自快照以来修改的数据。
备份意味着至less将一个副本作为一个完全独立的驱动器作为最低要求。
我使用这样的设置为vmware服务器机器和mysql数据库的快照。 到目前为止工作良好。 有几个恢复 – 都没有问题。 有一点需要考虑 – 使用快照lvm运行I / O操作会显着提高性能。 看这里 。 忽略他们谈论mysql的事实,I / O操作是I / O操作…不pipelvm上有什么样的数据。
我只使用lvm快照将DomU Lv另一个复制到单独的Vg中,其中每个Domain都有三个备份“节点”供处置。
之后,快照被销毁,备份的Lv保持到下一轮。 如果我有一个恢复,我只需要从备份Vg中select一个源Lv,并将其复制到域Lv。
偶尔,备份的Lv会被转储到另一台服务器上的映像文件中。
所有这些都是通过脚本实现的,每两天备份一次,每周一次。
我甚至有一个“恐慌”的模式,在这个领域,Lv将被恢复,但是从快照中运行,并且每2小时重置一次,以便在严重黑客的情况下保持在线上网,直到可以组织适当的防御。
什么成了“恐慌模式”的防线理念?