欢迎进入Linux社区论坛，与200万技术人员互动交流 >>进入
这两天看了有关LVM快照(snapshot)的一些资料，加上pczou的一些指导，对snapshot有一些理解，记录如下，和大家共享：
Logical Volume Manager (LVM)提供了对任意一个Logical Volume(LV)做“快照”(snapshot)的功能，以此来获得一个分区的状态一致性备份。
在某一个状态下做备份的时候，可能有应用正在访问某一个文件或者数据库，这就是使得备份的时候文件处于一个状态，而备份完后，文件却处于另外一个状态，从而造成备份的非一致性，这种状态恢复数据库数据几乎不会成功。
状态的解决办法是将其分区挂载为只读，然后通过数据库的表级别锁定(table-level write locks)甚至停止数据库来备份数据。所有这些方法无意严重影响了服务的可用性。使用LVM snapshot既可以获得一致性备份，又不会影响服务器的可用性。
要提醒一点是，snapshot这种方法仅对LVM有效，对于非LVM文件系统无效。
snapshot的实现有多种方式(参考文章最后的连接)，这里说说LVM中snapshot的“写时复制”(copy on write) 的实现方法。
当一个snapshot创建的时候，仅拷贝原始卷里数据的元数据(meta-data)。创建的时候，并不会有数据的物理拷贝，因此snapshot的创建几乎是实时的，当原始卷上有写操作执行时，snapshot跟踪原始卷块的改变，这个时候原始卷上将要改变的数据在改变之前被拷贝到snapshot预留的空间里，因此这个原理的实现叫做写时复制(copy-on-write)。
在写操作写入块之前，CoW讲原始数据移动到 snapshot空间里，这样就保证了所有的数据在snapshot创建时保持一致。而对于snapshot的读操作，如果是读取数据块是没有修改过的，那么会将读操作直接重定向到原始卷上，如果是要读取已经修改过的块，那么就读取拷贝到snapshot中的块。
这样，通常的文件I/0流程有一个改变，那就是在文件系统和设备驱动之间增加了一个cow层，变成了下面这个样子：
file I/0 ―> filesystem ― >CoW ?> block I /O
下面的图也许可以比较容易了解CoW的原理：
采取CoW实现方式时，snapshot的大小并不需要和原始卷一样大，其大小仅仅只需要考虑两个方面：从shapshot创建到释放这段时间内，估计块的改变量有多大;数据更新的频率。一旦 snapshot的空间记录满了原始卷块变换的信息，那么这个snapshot立刻被释放，从而无法使用，从而导致这个snapshot无效。所以，非常重要的一点，一定要在snapshot的生命周期里，做完你需要做得事情。当然，如果你的snapshot大小和原始卷一样大，甚至还要大，那它的寿命就是“与天齐寿”了。
[1][2][3][4][5]
旅行是一种病，当你把身边的人都传染了，
