Большинство стратегий резервного копирования начинаются с полного резервного копирования сервера MySQL, из которого можно восстановить все базы данных и таблицы. После создания резервной копии вы можете выполнять инкрементные резервные копии (которые меньше и быстрее) для следующих нескольких задач резервного копирования. Затем вы периодически создаете полное резервное копирование, чтобы начать цикл заново.

Примеры команд для создания полного резервного копирования см. в разделе 4.2.2 «Создание резервной копии всего экземпляра MySQL».

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

Параметры в командной строке или в файле конфигурации?

Для ясности, примеры в этом руководстве часто показывают некоторые параметры командной строки, используемые с командами mysqlbackup. Для удобства и согласованности вы можете включить те параметры, которые остаются неизменными для большинства задач резервного копирования, в раздел [mysqlbackup] файла конфигурации MySQL, который вы предоставляете команде mysqlbackup. mysqlbackup также использует параметры из раздела [mysqld], если они там присутствуют. Размещение параметров в файле конфигурации может упростить администрирование резервного копирования: например, размещение информации о порте в файле конфигурации позволит избежать необходимости редактирования скриптов резервного копирования каждый раз, когда экземпляр базы данных переключается на другой порт. Подробности об использовании файлов конфигурации см. в главе 17 «Файлы конфигурации и параметры».

Использование одного каталога резервного копирования или подкаталогов с отметкой времени?

Для удобства параметр --with-timestamp создает уникальные подкаталоги в каталоге резервного копирования для хранения данных резервной копии (постоянных или временных) и метаданных. Подкаталоги с отметкой времени упрощают установление периодов хранения, позволяя легко удалять и архивировать данные резервной копии, срок действия которых истек.

Если вы используете один каталог резервного копирования (то есть, если вы опустите параметр --with-timestamp), укажите новое уникальное имя каталога для каждой задачи резервного копирования.

Для инкрементных резервных копий, использующих параметр --incremental-base для указания каталога с предыдущей резервной копией, для предсказуемости имен каталогов, вы можете предпочесть не использовать параметр --with-timestamp и вместо этого сгенерировать последовательность имен каталогов с помощью вашего скрипта резервного копирования.

Всегда полное резервное копирование или полное резервное копирование плюс инкрементные резервные копии?

Если объем данных InnoDB невелик или база данных очень загружена, так что высокий процент данных изменяется между резервными копиями, возможно, вам следует каждый раз выполнять полное резервное копирование. Однако вы обычно можете сэкономить время и место на диске, выполняя периодические полные резервные копии, а затем несколько инкрементных резервных копий между ними, как описано в разделе 4.3.3 «Создание дифференциального или инкрементного резервного копирования».

Использовать сжатие или нет?

Создание сжатого резервного копирования может значительно сэкономить дисковое пространство и уменьшить использование ввода-вывода. А с методом сжатия LZ4 накладные расходы на обработку сжатия довольно низкие. В случаях, когда резервные копии базы данных перемещаются с более быстрого дискового устройства, где находятся активные файлы базы данных, на, возможно, более медленное хранилище, сжатие часто значительно уменьшит общее время резервного копирования. Это также может привести к сокращению времени восстановления. В общем, мы рекомендуем сжатие LZ4 вместо отсутствия сжатия для большинства пользователей, так как резервные копии, основанные на LZ4, часто завершаются за более короткий период времени. Однако протестируйте MySQL Enterprise Backup в вашей среде, чтобы определить наиболее эффективный подход. Дополнительные обсуждения сжатых резервных копий см. в разделе 4.3.4 «Создание сжатой резервной копии».