我们使用MySQL 5.0版本，大部分表都是InnoDB。我们运行复制到从服务器。我们正在考虑每天备份 MySQL 日志文件。
据我所知，进行增量备份的唯一方法是使用二进制日志。如果您想进行完整备份（InnoDB 热复制），您还有其他选择，但增量意味着您需要记录所做的所有事务。
您需要问自己为什么要备份数据。由于您有一个用于复制的从属设备，我认为备份主要是为了在意外删除的情况下恢复数据？
我可能会每 1 小时轮换一次日志并对其进行备份。这意味着，恢复最多只会保留 1 小时前的数据，并且您可以恢复到自上次完整快照以来的任何时间点。
您可以使用 mysqldump 定期转储模式，每个模式始终使用相同的文件名和路径（即替换最新的）
然后将其与任何支持增量/增量备份的备份工具结合使用，例如 rdiff-backup、duplicity、Duplicati 或 Areca Backup。口是心非文档中的示例：
因为口是心非使用了librsync，所以增量存档是空间 高效并且只记录文件中自此以来发生更改的部分 最后一次备份
这样，您的第一个备份将是第一个完整转储的压缩副本，第二个备份将包含第一个和第二个转储的压缩差异，依此类推。您可以恢复任意时间点的 mysqldump 文件，然后将该文件恢复到 MySQL 中。
距离上次回答已经过去很多时间了，这段时间已经出现了几种实现增量备份的解决方案和工具。
两个主要：
Percona XtraBackup - 是 MySQL 的开源热备份实用程序 - 基于服务器的备份期间不会锁定数据库。它 还允许您创建增量备份。 更多详情这里。
非常简单，看起来像这样：
xtrabackup --backup --target-dir=/data/backups/inc1 --incremental-basedir=/data/backups/base
mysqlbackup--incrementalmysqlbackup --defaults-file=/home/dbadmin/my.cnf --incremental --incremental-base=history:last_backup --backup-dir=/home/dbadmin/temp_dir --backup-image=incremental_image1.bi backup-to-image
这两个实用程序进行物理备份（复制数据库文件），但您仍然可以对 binlog 文件进行逻辑备份。
您可以自己编写脚本，也可以使用 github 上现成的脚本：
还有付费解决方案，事实上，它们是这些工具的漂亮包装：
进行增量备份时的最佳实践是什么？
这一切都取决于您的架构、数据量、您可以接受的最大允许停机时间间隔。最大允许数据丢失间隔。设置备份之前请考虑这些事项。
我只想提一个好的做法，但非常重要，而且经常被遗忘。在另一台不相关的服务器上定期测试并运行恢复脚本。