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

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

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

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

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

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

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

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

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

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

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

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

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