Большинство стратегий резервного копирования начинаются с полного резервного копирования сервера 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 «Создание сжатого резервного копирования».