一、LVM快照写时复制的特性（copy-on-write，COW）
写时复制快照在快照时间点之后，没有物理数据复制发生，仅仅复制了原始数据物理位置的元数据。因此，快照创建非常快，可以瞬间完成。然后，快照副本跟踪原始卷的数据变化（即原始卷写操作），一旦原始卷数据块发生写操作，则先将原始卷数据块读出并写入快照卷，然后用新数据块覆盖原始卷。这样我们访问快照卷上的数据仍旧是写操作前的，可以保证我们备份数据的一致性。它是一个接近于热备的工具
1、逻辑卷快照事实上是一个逻辑卷，仅仅是做为原卷的另外一个访问路径
2、刚刚创建快照卷时，快照卷中是没有任何数据的，所有的数据都指向了原卷中的那个数据块；所以，访问的数据都来自于原卷
3、一旦原卷中的数据需要修改了，某一数据在修改之前，要先把文件复制到快照卷中。所以，以后再通过快照卷访问数据时，都是一部份来自快照卷，一部分来自原卷；修改的数据来自于快照卷，未修改的数据来自于原卷
二、LVM快照的前提
1、事务日志跟数据文件必须在同一个卷上（否则做快照将无法保证时间点的一致）
2、创建快照之前，要请求MySQL的全局锁，在快照创建完之后释放锁
3、请示全局锁之后，做一次日志滚动，方便以后做即时点恢复；做二进制日志文件及位置标记（需手动进行）
三、LVM备份说明
基于LVM做备份，只需要备份数据目录就可以了
说明：
1、数据库的数据目录在/mydata/data下
2、二进制日志文件在/mydata/binlogs下
3、/mydata目录是逻辑卷，/dev/myvg/mydata挂载到了/mydata下
小前提：
1、考虑到数据是动态增长的，所以安装mysql时，将其安装到了逻辑卷中
2、保证物理卷中还有足够的空间来创建一个快照卷
四、LVM备份实现
1、保证有足够的卷组空间来创建快照卷
2、创建一个备份保存目录
|
1
|
[root@nmshuishui ~]
# mkdir /backups
|
3、请求全局锁，防止创建快照过程中有数据写入；并滚动日志
|
1
2
|
MariaDB [(none)]> flush tables with
read
lock;
MariaDB [(none)]> flush logs;
|
4、做二进制日志文件及位置标记
|
1
2
3
4
5
|
[root@nmshuishui ~]
# mysql -e 'show master status' > /backups/binlog.pos
[root@nmshuishui ~]
#
[root@nmshuishui ~]
# cat /backups/binlog.pos
File Position Binlog_Do_DB Binlog_Ignore_DB
mysql-bin.000002 351
|
5、对原卷创建快照卷（仅仅复制了元数据，因此创建过程非常快）
|
1
2
3
|
[root@nmshuishui ~]
# lvcreate -L 100M -s -n mydata-snap -p r /dev/myvg/mydata
Rounding up size to full physical extent 112.00 MiB
Logical volume
"mydata-snap"
created
|
6、释放全局锁
|
1
|
MariaDB [(none)]> unlock tables;
|
7、挂载快照并备份
|
1
2
3
4
5
|
[root@nmshuishui ~]
# mount /dev/myvg/mydata-snap /mnt/ -o ro //挂载为只读
[root@nmshuishui ~]
# cd /mnt/ //进入挂载目录
[root@nmshuishui mnt]
# ls //可以查看到备份前的数据，这也证明了快照卷本身并不是一个备份，只是访问原卷数据的另一个通道
binlogs data lost+found
[root@nmshuishui mnt]
# cp /mnt/data/ /backups/data-20140416 -a //归档备份
|
8、备份完成，卸载并删除快照
|
1
2
3
4
|
[root@nmshuishui ~]
# umount /mnt/
[root@nmshuishui ~]
# lvremove /dev/myvg/mydata-snap //删除快照，节省空间
Do you really want to remove active logical volume mydata-snap? [y
/n
]: y
Logical volume
"mydata-snap"
successfully removed
|
到这里基于快照的数据库备份就已经完成了
五、LVM的即时点恢复
1、说明
1）要做即时点恢复就必须得有二进制日志
2）模拟：操作失误把数据目录删了
3）这也是为什么要把二进制日志和数据目录分开放的原因，多一份小心，多一份安全
4）保证二进制日志没有被删除
5）恢复数据及做快照后以后的数据
2、步骤
1）新创建一个数据库（在做完快照备份后，又执行了数据操作）
2）删除数据目录
这里模拟时没有删除二进制日志，如果你删的比较彻底，把二进制日志也删了，那可就麻烦大了，就无法做即时点还原了，也只能去找数据恢复公司了。所以，当初装数据库的时候，为了安全考虑，并没有把二进制日志放到数据目录中，而是放到了同一个卷组中的另一个位置：/mydata/binlogs，多一份考虑，多一份安全保证
|
1
|
[root@shuishui ~]
# rm -rf /mydata/data/*
|
3）恢复
上面显示的太吓人了，所以数据都没有了，幸好我们做了备份，下面就恢复数据吧
4）查看数据是否恢复
5）即时点恢复
基于LVM-snapshort的完全备份，现在数据是恢复到了我们做快照那一刻的数据，可是我们之后的操作呢？还是没有，那就只能使用二进制日志做即时点还原了
当初在做快照时，我们保存下来了二进制日志文件及二进制标记，现在就可以派上用场了
进入二进制目录看下我们的二进制日志文件
mysql-bin.000002：是我们创建快照时那一刻的二进制日志文件
mysql-bin.000003：在创建快照前，我们滚动了一下日志，所以快照后的所有操作应该都是记录在这个二进制日志文件中的
mysql-bin.000004：这是我们在第4）步恢复数据时，重启服务生成的新滚动日志
根据上面条件判断，我们在创建完快照后，新建了一个hlbrc数据库，那么这个操作应该是保存在mysql-bin.000003中的
|
1
|
[root@nmshuishui binlogs]
# mysqlbinlog /mydata/binlogs/mysql-bin.000003
|
既然知道之后的操作在什么位置了，那就可以使用二进制日志做即时点还原了
|
1
|
[root@nmshuishui binlogs]
# mysqlbinlog /mydata/binlogs/mysql-bin.000003 | mysql //直接导出给mysql
|
再来查看一下，我们的即时点还原是否成功
六、总结
数据终于成功恢复了，当我们利用完全备份+增量备份或者完全备份+二进制文件备份进行了一次恢复，在恢复后就应尽早再做一次完整备份，免得万一下次数据出问题，恢复起来更麻烦
