lvm实现快速备份文件及数据库，lvm快照原理

我的应用场景~

讲解下我的应用吧，公司几个文件库，前段时间不知道被什么人给失误删除了，当时的 备份用的是rysnc的方式，结果源端的文件库被删除了后，另一端也没有了~  很让人恼火，因为文件库有200g左右   没法用tar 或者是 cp 目录的方式。。。。

还有就是公司的那帮人动不动就误删文件，搞的文件库时不时的缺失文件。

后来想到了用vmware做一个备份服务器，写个bat 每天会定时的快照的备份，这样的话就算是被删除了，也能找回前一天的~     但是这个方案用了几天  被上面的否决了 。。。 说是用实体好点~   哎~  ~ 

这样的话    我就想到了和vmware快照类似的概念的lvm快照~   

还挺用的~~~~

写时复制（copy-on-write，COW）

 

       写时复制快照在快照时间点之后，没有物理数据复制发生，仅仅复制了原始数据物理位置的元数据。因此，快照创建非常快，可以瞬间完成。然后，快照副本跟踪原始卷的数据变化（即原始卷写操作），一旦原始卷数据块发生写操作，则先将原始卷数据块读出并写入快照卷，然后用新数据块覆盖原始卷。这样我们访问快照卷上的数据仍旧是写操作前的，可以保证我们备份数据的一致性。

原理图：

 

 snapshot的原理

我们知道，LVM snapshot的原理是当一个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

 

 

快照卷是基于原卷的，如果你把原卷删除，快照卷也就没用了，

如果只是删除原卷的数据，快照卷是有效的。

创建lvm分区~~~~

创建pv，并查看pv

创建vg

创建lvm分区

查看下~

格式化

 

 

 

 写的有点乱~    有些路径大家请参考实际的环境~

下面是简单的过程，其实用dd也行，用tar打包也行，用dump的0级备份也都是可以的，主要的目的是备份快照。。。

如果是数据库的话需要先锁住表在创建快照并备份。以mysql为例：

#mysql –uroot –pmysql

mysql> flush tables with read lock;

mysql>flush logs;

mysql>system lvcreate –L 592M -s -n dbbackup /dev/rui/databases

mysql>show master status；

mysql>unlock tables；

mysql>quit

开始备份。

4.删除快照

备份结束后删除快照

# umount /mnt/rui/dbbackup

# lvremove /dev/ruidbbackup

 

用法~

 

 

###############################################################

 

 网上的一个测试，我的结果和他的类似.......

未做snapshot前的测试结果: time dd if=/dev/zero of=file.l bs=4k count=1000000 1000000+0 records in 1000000+0 records out 4096000000 bytes (4.1 GB) copied, 47.5652 s, 86.1 MB/s real    0m47.567s user    0m0.308s sys    0m12.073s 做了snapshot之后的测试结果: time dd if=/dev/zero of=file.l bs=4k count=1000000 1000000+0 records in 1000000+0 records out 4096000000 bytes (4.1 GB) copied, 722.703 s, 5.7 MB/s real    12m2.705s user    0m0.252s sys    0m14.653s

 

按理说，建立snapshot之后，中间是多了一层，但是也没有双重写入，为什么性能会相差几倍甚至十几倍呢？这是我百思不得其解的。询问了一些朋 友，也没有发现有这样的情况，不过其他人却是没有使用RAID1这种IO性能比较低的架构。另外在我使用EMC的存储作为磁盘来做LVM的情况下，有无 snapshot的IO性能只相差了20%左右。所以我断定，可能是因为磁盘和RAID1的性能太差导致做了LVM snapshot之后，在低性能的情况下过早出现IO的瓶颈导致的

######################################################################