备份应用的场景包括：系统崩溃、硬件故障、用户错误、升级MySQL Installation、传输MySQL Installation到另一台机器、设置复制等。
Slave Server备份
在备份Slave 数据库时，应该备份Master info 和 Relay log info repository，如果在备份时，Slave 正在复制 LOAD DATA语句应该备份slave_load_tmpdir 系统变量指定目下的SQL_LOAD*文件。
备份和恢复策略的例子
假设数据存储在InnoDB存储引擎上，支持事务和自动崩溃恢复。也假设在崩溃时，MySQL有负载。如果没有负载，可能恢复是不需要的。
一种情况：操作系统崩溃或电源故障，MySQL Server磁盘上的数据在数据库重启后可用。InnoDB上的数据文件可能由于崩溃而不一致。InnoDB读它的日志发现还未刷新到磁盘上的pending 事务或者 noncommited 事务。InnoDB自动回滚未提交的事务，刷新已提交的事务到数据文件中。
另一种情况：如果是文件系统崩溃或者硬件文件，假设MySQL磁盘数据在重启后不可用。这时就需要使用备份恢复。
建立备份策略
假设现在是周日下午一点，做包含所有InnoDB表的全库备份，比如：
shell> mysqldump --all-databases --master-data --single-transaction > backup_sunday_1_PM.sql
注：在MySQL 8.0 中默认情况下只有mysql schema下的两张日志表使用CSV存储引擎，其他表全部使用InnoDB存储引擎，在做备份时，mysqldump工具只会备份mysql.general_log、mysql_slow_log这两张日志的定义，而不会备份它们的数据。
这里使用--single-transaction，会在备份开始时，获取一个全局读锁（FLUSH TABLES WITH READ LOCK），在获取二进制日志的坐标位置后释放锁。如果在FLUSH语句执行时，有长时间运行的更新，备份操作可能要等它们完成。--single-transaction使用读一致性保证mysqldump看到的数据不会改变。这就需要没有其他语句破环读一致性，比如ALTER TABLE, DROP TABLE, RENAME TABLE,TRUNCATE TABLE等。
相对于连续的全备，一种有效的做法是：先做全备，然后做增量备份。增量备份更小，花时间也更短。但增量备份给恢复带来一些麻烦，比如：恢复是不能单纯的只应用一个全备，还需要应用增量备份。
在使用增量备份时，可以使用mysqldump工具提供的--flush-logs选项。这个选项会在备份时刷新二进制日志，这样mysqldump的备份中就包含刷新的二进制日志之前的所有数据。在做恢复时，在应用完全备后，可以方便的应用全备后生成的二进制日志。通过mysqldump工具的--maser-data可以知道全备之后的增量备份（二进制日志文件名）。
可以优化前面的备份脚本，比如：
shell> mysqldump --single-transaction --flush-logs --master-data=2 --all-databases > backup_sunday_1_PM.sql
假设现在是周一下午一点，做增量备份，比如：
shell> mysql'admin flush-logs
注：经二进制日志拷贝到安全位置。
假设现在是周二下午一点，做增量备份，比如：
shell> mysql'admin flush-logs
注：经二进制日志拷贝到安全位置。
补充：
为节约磁盘空间，在mysqldump全备后可以通过--delete-master-logs 选项删除二进制日志。但是在复制环境中，如果是Master Server，这样做可能对于没有完全接收二进制日志的Slave有影响。如果是在Slave Server端，可以考虑使用该选项。因为现在是在Slave端做的备份，可以修改之前的全备脚本如下：
shell> mysqldump --single-transaction --flush-logs --master-data=2 --all-databases --delete-master-logs > backup_sunday_1_PM.sql
注：mysqldump支持备份例程、事件、触发器，如果需要备份，可以添加--routines、--events 选项。
使用备份进制恢复
假设周三上午八点，发生了灾难性崩溃，需要使用备份进行恢复，首选进行全备恢复，比如：
shell> mysql < backup_sunday_1_PM.sql
现在数据已经恢复到周日下午一点，需要做增量恢复，比如：
shell> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql
现在数据已经恢复到周二下午一点，但是到周三上午八点的数据还是没有恢复。所以MySQL建议：将日志文件放在一个安全的地方，比如RAID地盘 SAN 等，不同于存放数据目录的磁盘。
如果日志文件没有损坏，可以通过继续应用增量备份，将数据恢复到崩溃发生的时间点，比如：
shell> mysqlbinlog gbichot2-bin.000009 | mysql
备份策略总结
在操作系统崩溃或者电源故障的情况下，InnoDB可以自动恢复，但是为了能够睡的更好，可以完成下面的建议：
将日志文件存放在安全的位置，同时与数据目录在不同的磁盘设备上。这样做也可以做到磁盘的负载均衡，提升了性能。
定期做全量备份
定期做增量备份
注：这里做增量备份是每天做的，所有二进制日志文件大小应该要能够容纳至少一天的业务数据。