Xtrabackup为什么不需要备份binlog文件？

Xtrabackup 的恢复模式属于 OS Crash recovery，服务异常重启会做以下事情：(binlog有记录就提交，无记录就回滚)
binlog有记录，redolog状态commit：正常完成的事务，不需要恢复；
binlog有记录，redolog状态prepare：在binlog写完提交事务之前的crash，恢复操作：提交事务。（因为之前没有提交）
binlog无记录，redolog状态prepare：在binlog写完之前的crash，恢复操作：回滚事务（因为crash时并没有成功写入数据库）


一般情况下 autocommit 参数为1，也就是自动提交。binlog 日志中会自动为事务执行begin;commit

二阶段提交：为了保证redo log和binlog 的逻辑一致性。前者是存储引擎层的，后者是OS层的。

binlog提交将提交分为了3个阶段，FLUSH阶段，SYNC阶段和COMMIT阶段。
FLUSH 阶段:将binlog buffer到I/O cache和通知dump线程dump binlog。伴随redo的操作是innodb的prepare将事务状态设为TRX_PREPARED，并将redo log刷磁盘。
SYNC阶段： 将一组binlog 落盘(sync动作，最耗时，假设sync_binlog为1)。存储引擎层prepare都执行成功之后将SQL语句写到binlog。(没有prepare成功的就回滚不记录binlog)
COMMIT阶段：逐一进行innodb commit。清除undo信息，刷redo日志，将事务设为TRX_NOT_STARTED状态。(binlog 已经在SYNC阶段落盘了，所以SYNC阶段之前的Crash recovery时需要回滚，之后的提交。而备份工具的FTWRL 锁如果是排他的，如果获取成功，就说明此刻COMMIT阶段阶段已经完成了)

redo日志是从备份开始一致持续复制，最后一次复制是在FTWRL 之后，此时由show master status获取binlog一致性位点。所以我们可以理解为获取FTWRL的时间点就是可恢复的截止时间点。