背景
众所周知，mysqlworkbench 导出导入，每个表是一个整句的 insert，所以导致众所周知的，如果你用老版本的数据覆盖新的，新的数据是会被清掉的，binlog 当中，只能看到一打打打句的 insert，很难从 binlog 中恢复。
没错，我就做了这件事情。导入数据的时候选错了选选项卡....丢掉了一部分线上数据
do
首先，看人都推荐 binlog2sql，我就上车了。但是由于服务器羸弱的硬盘性能和菊大的 binlog，还有大 python 八核围观的特性，跑不出来。
此时，能采取的最小损失的方法就是每天早上五点钟的增量备份。终于（？？）能吃到了 Rex 当年种下的 Xtrabackup 树的果子啦~~开心。
每周一次的全量，每天一次的增量。道理我们都懂。但是...问了 Rex 之后发现，我们两个都没用这玩意还原过（难道用过这玩意的都被打死了？我们这是幸存者偏差？）。于是，简单的 lolo 文档和别人的博客，我们就上路啦。
首先呢，第0步，先停掉 mariadb，systemctl stop mysql，用 mysqldump 导出一次完整数据，以防万一。
mysqldump -u<user> -p<passw0rd> --all-databases > /tmp/2018.11.4.sql
最好异地存一下这个大 sql。
第一步，不要 像一些文章说的，直接删除数据库（你们就这么教人 rm -rf /data/mysql 的么？），先把原来的 mysql 数据文件夹改名（此时开始，推荐 sudo su 切换到 root 用户）
move /data/mysql /data/mysql.bak
然后新建一个同名文件
mkdir /data/mysql
/data/mysql 是数据库的数据目录，可以在 /etc/my.cnf 中找到
[mysqld]
datadir = /data/mysql
第二步，到备份的地方看看（一单小可爱们跑了怎么办呢，对吧
因为全量和差量 开始时间不一样，我们的最近一次的全量备份是 2018-10-29_05-00-01
就决定从这个文件开始了
第三步，开始整合增量备份到全量备份。
innobackupex --defaults-file=/etc/my.cnf --user=<user> --password=<passw0rld> --use-memory=8G --apply-log --redo-only /backup/mysql/2018-10-29_05-00-01
参数 --defaults-file，mysql 的配置文件，一定要是第一个参数，user 和 password 不必多说，用 root 就可以，无 root 权限要足够高。
--use-memory 尽量给的大一点，内存拉满，肯定更快
--apply-log --redo-only 指的是基于 /backup/mysql/2018-10-29_05-00-01 准备还原数据
然后 等他结束...
第四步，依次增加增量备份
innobackupex --defaults-file=/etc/my.cnf --user=<user> --password=<passw0rld> --use-memory=8G --apply-log --redo-only /backup/mysql/2018-10-29_05-00-01 --incremental-dir=/backup/mysql/2018-10-29_05-30-01/
innobackupex --defaults-file=/etc/my.cnf --user=<user> --password=<passw0rld> --use-memory=8G --apply-log --redo-only /backup/mysql/2018-10-29_05-00-01 --incremental-dir=/backup/mysql/2018-10-30_05-30-01/
innobackupex --defaults-file=/etc/my.cnf --user=<user> --password=<passw0rld> --use-memory=8G --apply-log --redo-only /backup/mysql/2018-10-29_05-00-01 --incremental-dir=/backup/mysql/2018-10-31_05-30-02/
innobackupex --defaults-file=/etc/my.cnf --user=<user> --password=<passw0rld> --use-memory=8G --apply-log --redo-only /backup/mysql/2018-10-29_05-00-01 --incremental-dir=/backup/mysql/2018-11-01_05-30-01/
innobackupex --defaults-file=/etc/my.cnf --user=<user> --password=<passw0rld> --use-memory=8G --apply-log --redo-only /backup/mysql/2018-10-29_05-00-01 --incremental-dir=/backup/mysql/2018-11-02_05-30-01/
innobackupex --defaults-file=/etc/my.cnf --user=<user> --password=<passw0rld> --use-memory=8G --apply-log --redo-only /backup/mysql/2018-10-29_05-00-01 --incremental-dir=/backup/mysql/2018-11-03_05-30-01/
innobackupex --defaults-file=/etc/my.cnf --user=<user> --password=<passw0rld> --use-memory=8G --apply-log /backup/mysql/2018-10-29_05-00-01 --incremental-dir=/backup/mysql/2018-11-04_05-30-01/
一定要注意 ，最后一个增量数据 去掉 --redo-only
增量全部搞完之后
innobackupex --defaults-file=/etc/my.cnf --user=<user> --password=<passw0rld> --use-memory=8G --apply-log /backup/mysql/2018-10-29_05-00-01
再戳一下全量
第五步，登登，还原全量包
innobackupex --defaults-file=/etc/my.cnf --user=<user> --password=<passw0rld> --use-memory=8G --copy-back /backup/mysql/2018-10-29_05-00-01
又一定要注意 如果你全是innodb，或者说即使不是，也不要使用 --rsync 选项。在 Btrfs 上，可能会导致 inode 无法动态分配导致的报磁盘不足错误。
导入完成之后，systemctl start mysql 就ok啦~~
ending
大家就当无事发生过~
其他
对于 brtfs，dumpe2fs /dev/sda 会得到
dumpe2fs: Bad magic number in super-block while trying to open /dev/sda3
Couldn't find valid filesystem superblock.
emmmmm，讲道理，这就是 brtfs 先进的地方了吧。
在稳健的 centos7 当中，df -i 对于 brtfs，会显示 inode 为 0