基于LVM的数据库备份和恢复

一、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、创建一个备份保存目录

[root@nmshuishui ~]# mkdir /backups

   3、请求全局锁，防止创建快照过程中有数据写入；并滚动日志

MariaDB [(none)]> flush tables with read lock;
MariaDB [(none)]> flush logs;

   4、做二进制日志文件及位置标记

[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、对原卷创建快照卷（仅仅复制了元数据，因此创建过程非常快）

[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、释放全局锁

MariaDB [(none)]> unlock tables;

   7、挂载快照并备份

[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、备份完成，卸载并删除快照

[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，多一份考虑，多一份安全保证

[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中的

[root@nmshuishui binlogs]# mysqlbinlog /mydata/binlogs/mysql-bin.000003

   既然知道之后的操作在什么位置了，那就可以使用二进制日志做即时点还原了

[root@nmshuishui binlogs]# mysqlbinlog /mydata/binlogs/mysql-bin.000003 | mysql        //直接导出给mysql

   再来查看一下，我们的即时点还原是否成功

六、总结

   数据终于成功恢复了，当我们利用完全备份+增量备份或者完全备份+二进制文件备份进行了一次恢复，在恢复后就应尽早再做一次完整备份，免得万一下次数据出问题，恢复起来更麻烦

---