对我来说,这似乎是快速,无脑恢复的完美解决方案.任何调查都可以在破坏的逻辑卷上进行,domU成功运行而不会中断.
编辑:
在进行完整系统备份时,这就是我现在所处的位置.
> domU磁盘的lvm快照
>一个新的逻辑卷,其大小等于快照大小.
> dd if = / dev / snapshot of = / dev / new_lv
>使用lvremove处理快照
>使用kpartx / mount / ls进行可选验证
现在我需要自动化这个.
解决方法
实现快照有几个步骤.首先是必须分配新的逻辑卷.本卷的目的是提供一个记录文件系统增量(更改)的区域.这允许原始卷继续运行而不会中断任何现有的读/写访问.这样做的缺点是快照区域的大小有限,这意味着在写入繁忙的系统上,它可以很快填满.对于具有重要写入活动的卷,您需要增加快照的大小,以便为所有更改记录足够的空间.如果快照溢出(填满),快照将暂停并标记为不可用.如果发生这种情况,您将需要发布快照,以便可以将原始卷重新联机.一旦发布完成,您就可以将卷重新安装为读/写,并使其上的文件系统可用.
第二件事就是LVM现在“交换”了相关卷的真正用途.您会认为新分配的快照将是查找文件系统任何更改的地方,毕竟,它是所有写入的所在,对吧?不,这是相反的方式.文件系统安装到LVM卷名称,因此从系统其余部分下面交换名称将是禁止(因为快照使用不同的名称).因此,此处的解决方案很简单:当您访问原始卷名时,它将继续引用您执行快照的卷的实时(读/写)版本.您创建的快照卷将引用要备份的卷的冻结(只读)版本.起初有点混乱,但它会有意义.
所有这些都在不到2秒的时间内发生.系统的其余部分甚至没有注意到.当然,除非您在快照溢出之前不释放快照…
在某些时候,您将要释放快照以回收它占用的空间.发布完成后,快照卷将释放回卷中,原始卷将保留.
我不建议将此作为长期备份策略.您仍然在可能发生故障的同一物理驱动器上托管数据,并且从失败的驱动器恢复文件系统根本就没有备份.
所以,简而言之:
>快照适用于协助备份>快照本身不是一种备份形式>快照不会永远持续下去>完整快照不是一件好事>需要在某些时候发布快照> LVM是你的朋友,如果你明智地使用它.