Мы используем MySQL версии 5.0, а большинство таблиц - InnoDB. Мы запускаем репликацию на подчиненный сервер. Мы думаем о поддержке файлов журнала MySQL на ежедневной основе.
AFAIK единственный способ делать инкрементные резервные копии - использовать двоичный журнал. У вас есть другие варианты, если вы хотите делать полные резервные копии (InnoDB hotcopy), но инкрементный означает, что вам нужно регистрировать все сделанные транзакции.
Вам нужно спросить себя, почему вы создаете резервные копии данных. Поскольку у вас есть подчиненное устройство для репликации, я предполагаю, что резервная копия предназначена для восстановления данных в случае случайного удаления?
Я бы, вероятно, вращал журналы каждые 1 час и делал резервную копию. Значение, восстановление будет оставить данные не более 1 часа, и вы можете восстановить их в любой момент времени с момента последнего полного моментального снимка.
Вы можете регулярно выгружать свои схемы с помощью mysqldump, используя всегда одно и то же имя файла и путь для каждой схемы (т.е. заменяя последнюю)
Затем объедините это с любым средством резервного копирования, которое поддерживает инкрементное/дельта-резервное копирование, например rdiff-backup, duplicity, Duplicati или Areca Backup. Пример из документов двойственности:
Поскольку двуличность использует librsync, инкрементные архивы являются пробелами эффективно и только записывать части файлов, которые изменились с тех пор последняя резервная копия
Таким образом, ваша первая резервная копия будет сжатой копией 1-го полного дампа, а вторая будет содержать сжатые отличия от 1-го и 2-го дампов и так далее. Вы можете восстановить файл mysqldump любого момента времени, а затем восстановить этот файл в MySQL.