1.备份计划
视库的大小来定，一般来说100G内的库，可以考虑使用mysqldump来做，因为mysqldump更加轻巧灵活，备份时间选在业务低峰期，可以每天进行都进行全量备份(mysqldump备份出来的文件比较小，压缩之后更小)。100G以上的库，可以考虑用xtranbackup来做，备份速度明显要比mysqldump要快。一般是选择一周一个全备，其余每天进行增量备份，备份时间为业务低峰期。
2.备份恢复时间
物理备份恢复快，逻辑备份恢复慢
这里跟机器，尤其是硬盘的速率有关系，以下列举几个仅供参考
20G的2分钟（mysqldump）
80G的30分钟(mysqldump)
111G的30分钟（mysqldump)
288G的3小时（xtra)
3T的4小时（xtra)
逻辑导入时间一般是备份时间的5倍以上
3.mysqldump和xtrabackup实现原理
mysqldump
mysqldump属于逻辑备份。加入--single-transaction选项可以进行一致性备份。后台进程会先设置session的事务隔离级别为RR(SETSESSIONTRANSACTIONISOLATIONLEVELREPEATABLEREAD)，之后显式开启一个事务(STARTTRANSACTION/*!40100WITHCONSISTENTSNAPSHOT*/)，这样就保证了该事务里读到的数据都是事务事务时候的快照。之后再把表的数据读取出来。如果加上--master-data=1的话，在刚开始的时候还会加一个数据库的读锁(FLUSHTABLESWITHREADLOCK),等开启事务后，再记录下数据库此时binlog的位置(showmasterstatus)，马上解锁，再读取表的数据。等所有的数据都已经导完，就可以结束事务
Xtrabackup
xtrabackup属于物理备份，直接拷贝表空间文件，同时不断扫描产生的redo日志并保存下来。最后完成innodb的备份后，会做一个flush engine logs的操作(老版本在有bug，在5.6上不做此操作会丢数据)，确保所有的redolog都已经落盘(涉及到事务的两阶段提交概念，因为xtrabackup并不拷贝binlog，所以必须保证所有的redo log都落盘，否则可能会丢最后一组提交事务的数据)。这个时间点就是innodb完成备份的时间点，数据文件虽然不是一致性的，但是有这段时间的redo就可以让数据文件达到一致性(恢复的时候做的事情)。然后还需要flushtableswithreadlock，把myisam等其他引擎的表给备份出来，备份完后解锁。这样就做到了完美的热备。
