在Xtrabackup的wiki上简单的介绍了一下实现的原理：
首先，在logfile中找到并记录最后一个checkpoint（“last checkpoint LSN”），然后开始从LSN的位置开始拷贝InnoDB的logfile到xtrabackup_logfile；接着，开始拷贝全部的数据文件.ibd；在拷贝全部数据文件结束之后，才停止拷贝logfile。
因为logfile里面记录全部的数据修改情况，所以，即时在备份过程中数据文件被修改过了，恢复时仍然能够通过解析xtrabackup_logfile保持数据的一致。
Tip1：Xtrabackup是一个用于备份InnoDB/XtrDB的工具，真正的在线备份（不影响数据的读写），InnoDB Hot Backup的开源替代品。
Tip2：在使用参数stream=tar备份的时候，你的xtrabackup_logfile可能会临时放在/tmp目录下，如果你备份的时候并发写入较大的话xtrabackup_logfile可能会很大（5G+），很可能会撑满你的/tmp目录，可以通过参数--tmpdir指定目录来解 决这个问题。
备份原理
XtraBackup基于InnoDB的crash-recovery功能。它会复制innodb 的data file，由于不锁表，复制出来的数据是不一致的，在恢复的时候使用crash-recovery，使得数据恢复一致。
InnoDB维护了一个redo log，又称为 transaction log，事务日志，它包含了innodb数据的所有改动情况。当InnoDB启动的时候，它会先去检查data file和transaction log，并且会做二步操作：1.It applies committed transaction log entries to the data files2.it performs an undo operation on any transactions that modified data but did not commit.
XtraBackup在备份的时候， 一页一页地复制innodb的数据，而且不锁定表，与此同时，XtraBackup还有另外一个线程监视着transactions log，一旦log发生变化，就把变化过的log pages复制走。为什么要急着复制走呢？ 前几章的时候就提过这个问题，因为transactions log文件大小有限，写满之后，就会从头再开始写，所以新数据可能会覆盖到旧的数据。
在prepare过程中，XtraBackup使用复制到的transactions log 对备份出来的innodb data file 进行crash recovery。
实现细节
文件权限
xtrabackup以read-write模式打开innodb的数据文件，然后对其进行复制。其实它不会修改此文件。也就是说，运行xtrabackup的用户，必须对innodb的数据文件具有读写权限。
为什么要用rw模式呢？直接read模式不好么？因为xtrabackup采用了其内置的innodb库来打开文件，而innodb库打开文件的时候就是rw的。
Tuning the OS Buffers
因为XtraBackup要从文件系统中复制大量的数据，所以它尽可能地使用posix_fadvise()，来告诉OS不要缓存读取到的数据，从而提升性能。因为这些数据不会重用到了，OS却没有这么聪明。如果要缓存一下的话，几个G的数据，会对OS的虚拟内存造成很大的压力，其它进程，比如mysqld很有可能被swap出去，这样系统就会受到很大影响了。
posix_fadvise(file,0,0, POSIX_FADV_DONTNEED)
而且XtraBackup在读取数据的时候还尽可能地预读：
posix_fadvise(file,0,0, POSIX_FADV_SEQUENTIAL)
复制数据文件
在备份innodb page的过程中，XtraBackup每次读写1MB的数据，1MB/16KB=64个page。这个不可配置。读1MB数据之后，XtraBackup一页一页地遍历这1MB数据，使用innodb的buf_page_is_corrupted()函数检查此页的数据是否正常，如果数据不正常，就重新读取这一页，最多重新读取10次，如果还是失败，备份就失败了，退出。
It skips this check on the doublewrite buffer？？
在复制transactions log的时候，每次读写512KB的数据。同样不可以配置。