Существует несколько способов использования инкрементных резервных копий для восстановления базы данных в разных сценариях. Предпочтительный метод заключается в первоначальном восстановлении полной резервной копии и обновлении ее до момента создания полной резервной копии с помощью команды copy-back-and-apply-log (см. Пример 5.1, «Восстановление базы данных», чтобы узнать, как это сделать), а затем повторно используйте copy-back-and-apply-log, чтобы восстановить образ инкрементной резервной копии поверх только что восстановленной полной резервной копии:

mysqlbackup --defaults-file=<my.cnf> -uroot --backup-image=<inc_image_name> \
  --backup-dir=<incBackupTmpDir> --datadir=<restoreDir> --incremental \
  copy-back-and-apply-log

В этом примере образ инкрементной резервной копии с именем <inc_image_name> восстанавливается в <restoreDir> на сервере (где полная резервная копия, на основе которой был создан образ инкрементной резервной копии, уже восстановлена). Опция --backup-dir используется для указания временной директории, в которую сохраняются временные выходные данные, файлы состояния и метаданные резервной копии. Повторите этот шаг с другими образами инкрементных резервных копий, которые у вас есть, пока данные не будут восстановлены до желаемого момента времени.

Расширенное: Восстановление каталога инкрементной резервной копии

Инкрементные резервные копии каталога можно восстановить в серии команд copy-back-and-apply-log, как показано выше для резервных копий отдельных файлов. В качестве альтернативы, в любое время после создания инкрементной резервной копии и до восстановления данных, вы можете обновить полную резервную копию до момента создания инкрементной резервной копии. Сначала примените любые изменения, произошедшие во время создания резервной копии:

$ mysqlbackup --backup-dir=/full-backup/2010-12-08_17-14-11 apply-log
..many lines of output...
101208 17:15:10  mysqlbackup: Full backup prepared for recovery successfully!

101208 17:15:10 mysqlbackup: mysqlbackup completed OK!

Затем мы применяем изменения из инкрементной резервной копии с помощью команды apply-incremental-backup:

$ mysqlbackup --incremental-backup-dir=/incr-backup/2010-12-08_17-14-48
  --backup-dir=/full-backup/2010-12-08_17-14-11 apply-incremental-backup
...many lines of output...
101208 17:15:12 mysqlbackup: mysqlbackup completed OK!

Теперь файлы данных в каталоге полной резервной копии полностью обновлены до момента создания последней инкрементной резервной копии. Вы можете продолжать обновлять их с помощью дополнительных инкрементных резервных копий, чтобы они были готовы к восстановлению в любое время.

Восстановление бинарного журнала и журнала репликации

Когда инкрементная резервная копия восстанавливается с помощью команды copy-back-and-apply-log или apply-incremental-backup, бинарный журнал (а также журнал репликации в случае сервера-реплики), если он включен в инкрементную резервную копию, по умолчанию также восстанавливается на целевой сервер. Это поведение по умолчанию отменяется, когда используется либо (1) опция --skip-binlog (или опция --skip-relaylog для журнала репликации) с командой восстановления, либо (2) если в полной резервной копии, на основе которой была создана инкрементная резервная копия, или в любой предыдущей инкрементной резервной копии между полной резервной копией и этой инкрементной резервной копией отсутствует бинарный журнал (или журнал репликации) (в обоих случаях, для MySQL Enterprise Backup 4.1.5 и более поздних версий, mysqlbackup переименовывает любые файлы бинарного журнала (но не журнала репликации) и их индексные файлы, которые уже были восстановлены на сервер, добавив расширение .old к их именам файлов).

Для версии 4.1.2 и более поздних версий: Путь к бинарному журналу (или журналу репликации) после восстановления инкрементной резервной копии по умолчанию совпадает с путем к журналу на сервере, с которого была сделана инкрементная резервная копия, или с путем, указанным с помощью опции --log-bin (или --relay-log) во время восстановления инкрементной резервной копии.

Для версии 4.1.1 и более ранних версий: Путь к бинарному журналу (или журналу репликации) после восстановления инкрементной резервной копии — это каталог данных восстановленного сервера.

См. Раздел 4.3.3, «Создание дифференциальной или инкрементной резервной копии» и Раздел 16.7, «Параметры инкрементной резервной копии», для получения дополнительной информации об инкрементных резервных копиях.