1、增量备份：
增量数据是从上次全量备份之后，更新的新数据，对于mysql来说，binlog日志就是mysql的增量数据；
（1）按天进行备份：
|
周一00点全量备份 |
周二00点全量备份 |
...... |
|
01.sql.gz |
02.sql.gz |
...... |
|
周一增量备份 |
周二增量备份 |
...... |
|
mysql-bin.000001 mysql-bin.000002 mysql-bin.000003 mysql-bin.index |
mysql-bin.000004 mysql-bin.000005 mysql-bin.000006 mysql-bin.index |
...... |
1）优点：恢复时间短，维护成本低；
2）缺点：占用空间多，占用系统资源多，经常锁表影响用户的体验；
（2）按周进行备份：
|
周六00全量备份 |
||
|
01.sql.gz |
01.sql.gz |
01.sql.gz |
|
周一增量备份 |
周二增量备份 |
周三增量备份 |
|
mysql-bin.000001 mysql-bin.000002 mysql-bin.000003 mysql-bin.index |
mysql-bin.000004 mysql-bin.000005 mysql-bin.000006 mysql-bin.index |
mysql-bin.000007 mysql-bin.000008 mysql-bin.000009 mysql-bin.index |
1）优点：节省备份时间，减小本分压力；
2）缺点：增量的binlog文件副本太多，还原会比较的麻烦；
（3）企业场景全量和增量的频率是怎么做的：
1）中小公司，全量一般是一天一次，业务流量低谷时执行全被，备份时会锁表；
2）大公司周备，每周六00点一次全量备份，下周日到周六前都是增量；
3）如何增量：
使用rsync+inotify(rsync+sersync)把所有的binlog备份到远程服务器上；
（4）企业的备份什么时候会派上用场：
1）迁移或者升级数据库时；
2）增加从从库的时候；
3）人为的ddl，dml语句,主从库都没有办法了，因为所有的库都会还行，此时需要备份；
4）跨机房灾备，需要备份到异地；
（5）小结：
我们在生产工作中一般常用一主多从数据库架构，常见的备份方案是在某一个不对外服务的从库上
开启binlog，然后实施定时全备和实时增量备份，保存的周期大于备份的周期；
2、增量恢复：
利用二进制日志和全备进行的恢复过程，被称为增量恢复：
（1）主库或者从库宕机(硬件损坏)是否需要增量恢复：
不需要增量恢复；
主库宕机，只需要把其中一个同步最快的从库切换为主库即可；
从库宕机，直接不用就好了；
（2）人为操作数据库sql语句破坏主库是否需要增量恢复：
需要增量恢复；
在数据库主库内部命令行误操作，会导致所有的数据库(包括主从库)数据的丢失。
列如：在主库执行了‘drop database test;‘这样的删除语句，这时所有的从库也
会执行这哥‘drop database test;‘语句，从而导致所有数据库上的test库数据丢失。
（3）只有一个主库是否需要进行增量恢复：
如果公司只有一个主库的情况，首先应该做定一天一次的全量备份及时时的增量
备份。
（4）小结：
1）一般由人为或程序逻辑的方式在数据库执行的sql语句等误操作，才需要增量恢复，因为
此时所有的从库也执行了误操作语句；
2）增量恢复的条件是：存在一份全备加上全备之后的时刻到出现问题的所有增量binlog文件备份；
3）恢复时建议对外停止更新；
4）恢复全量备份，然后把增量日志中有问题的sql语句删除，恢复到数据库；
5）增量恢复的核心思想：
流程制度控制，如果不做，就会面临数据和服务出现故障；
业务需求容忍度，可量化的目标，根据需求选择停库或锁表或者容忍丢失部分数据；
3、备份注意：
备份保存的周期要大于备份的周期；
原文地址：https://www.cnblogs.com/LiuChang-blog/p/12315808.html