Возможно, это:
$ cd /mnt/external_drive && split /path/to/original/bigfile.tar
Можно моделировать инкрементное резервное копирование путем включения и затем резервного копирования двоичных журналов. См. http://dev.mysql.com/doc/refman/5.1/en/backup-methods.html при "Создании Возрастающих Резервных копий путем Включения Двоичного Журнала".
Xtrabackup контроля (Percona), если Вы используете InnoDB. Это может сделать incrementals.
http://www.percona.com/docs/wiki/percona-xtrabackup:xtrabackup:incremental?rev=1289183209
Удачи
Я использую бинлоги, но они не являются окончательным решением, и я также склонен полагаться на снимки состояния.
Для этого есть две основные причины:
В последнее время у меня было большое количество снимков, которые не были ни сжатыми, ни дифференциальными. Я экспериментировал с diff и обнаружил, что даже с такими параметрами, как отсутствие контекста, полученные различия были больше.
Не пробуя все альтернативы, лучшее, что я нашел, - это rdiff. Это уменьшило их размер примерно до 5% для меня, а при последующем сжатии с помощью xz в зону 1%.
Хотя файлы подписи rdiff не сжимаются должным образом, поскольку они представляют собой коллекции хэшей (такие же, как случайные данные), сжатие они друг против друга должны дать хорошие результаты.
Многим людям не понадобится такое решение, так как в большинстве случаев в случае сбоя им нужно будет сохранить базу данных с самым последним изображением и как можно быстрее обновить ее. .
Однако, если у вас сложная система, которая требует большого количества учетных данных, аудита, отладки и т. Д. (Более важные вещи, чем блог), тогда эффективное хранение снимков становится важным.
Проверить скрипт https://sourceforge.net/projects/mysqlincrementalbackup/ . Решение для инкрементного резервного копирования для MyISAM и Innodb.