База данных — это состояние, которое нельзя восстановить переустановкой пакета. При этом резервная копия MySQL или MariaDB часто делается «на всякий случай» скриптом из интернета, который никто не проверял на восстановлении. Ниже — два рабочих подхода: логический дамп через mysqldump для небольших и средних баз и физическое копирование через Percona XtraBackup для больших инсталляций. С командами, проверкой целостности и разбором типичных ошибок.

Что именно нужно сохранять

Кроме пользовательских таблиц есть системные привилегии, определения процедур и триггеров, события планировщика и конфигурация сервера. Если дампите только схему приложения, после восстановления придётся вручную создавать пользователей и выдавать права. Отдельно храните my.cnf и список установленных плагинов. И помните: копия на том же диске — не резервная копия, а второй экземпляр данных.

mysql --version
mysqldump --version
mysql -e "SELECT VERSION(), @@datadir, @@log_bin\G"
df -h /var/lib/mysql

mysqldump: логический дамп

mysqldump читает таблицы и превращает их в SQL-текст. Для InnoDB ключ —single-transaction даёт согласованный снимок без блокировки записи: транзакция видит данные на момент старта. Без него дамп большой базы может быть несогласованным. Для MyISAM такого механизма нет, и таблицы придётся блокировать.

mysqldump --single-transaction --quick --routines --triggers --events \
  --set-gtid-purged=OFF --default-character-set=utf8mb4 \
  --databases appdb | gzip > /backup/appdb-$(date +%F).sql.gz

Разберём флаги. —quick отдаёт строки построчно и не держит всю таблицу в памяти. —routines и —triggers включают процедуры и триггеры, —events — события. —set-gtid-purged=OFF убирает из дампа информацию GTID, которая при восстановлении на другой сервер вызовет конфликт. —databases добавляет CREATE DATABASE и USE, что удобно для полного восстановления.

Для всех баз сразу используйте —all-databases, но тогда в дамп попадут системные таблицы mysql, и восстановление потребует аккуратности с правами. Пароль не передавайте в командной строке: он останется в history и в списке процессов. Используйте файл конфигурации с правами 600 или login-path.

install -m 600 /dev/null /root/.my.cnf
printf '[client]\nuser=backup\npassword=Секрет\n' > /root/.my.cnf
mysql --defaults-extra-file=/root/.my.cnf -e "SHOW DATABASES"
mysqldump --defaults-extra-file=/root/.my.cnf --all-databases | gzip > /backup/all-$(date +%F).sql.gz

Проверка дампа обязательна. Пустой файл, обрезанный gzip или дамп без таблиц — распространённый результат. Смотрите размер, код возврата и наличие финальной строки. Полезно сразу развернуть копию на тестовом инстансе.

ls -lh /backup/appdb-*.sql.gz
gzip -t /backup/appdb-$(date +%F).sql.gz && echo OK
zcat /backup/appdb-$(date +%F).sql.gz | tail -3
mysql --defaults-extra-file=/root/.my.cnf appdb_test < /backup/appdb-test.sql

Восстановление логического дампа

Восстановление выполняйте на сервер той же мажорной версии. Отключите на время импорта binary log, иначе каждая вставка попадёт в журнал и раздует его. Для InnoDB имеет смысл увеличить innodb_buffer_pool_size и отключить fsync, но только на время импорта и только на тестовом сервере. На боевом такие изменения могут стоить данных при сбое питания.

mysql --defaults-extra-file=/root/.my.cnf -e "SET GLOBAL sql_log_bin=0"
zcat /backup/appdb-2026-11-01.sql.gz | mysql --defaults-extra-file=/root/.my.cnf
mysql --defaults-extra-file=/root/.my.cnf -e "SET GLOBAL sql_log_bin=1"
mysql --defaults-extra-file=/root/.my.cnf appdb -e "CHECK TABLE users"

Перед импортом убедитесь, что на диске достаточно места: сжатый дамп занимает меньше, чем развёрнутые таблицы и индексы. Для MariaDB синтаксис и утилиты совместимы, но есть отличия в GTID и в формате дампа. Не переносите дамп MariaDB в MySQL и наоборот без проверки: типы, collation и системные таблицы могут не совпасть.

XtraBackup: физическое копирование

Для баз от сотен гигабайт логический дамп становится медленным, а восстановление — долгим. Percona XtraBackup копирует файлы данных, не блокируя запись, и умеет инкрементальные копии. Важно: для MariaDB используйте mariadb-backup, для MySQL 8.0 — XtraBackup 8.0, для 8.4 — соответствующую ветку 8.4. Совместимость версий здесь строгая, а не «примерно».

xtrabackup --backup --user=backup --password=Секрет \
  --target-dir=/backup/full-2026-11-01
xtrabackup --prepare --target-dir=/backup/full-2026-11-01
xtrabackup --copy-back --target-dir=/backup/full-2026-11-01
chown -R mysql:mysql /var/lib/mysql

Ключевой этап — prepare: он применяет журнал и приводит файлы к согласованному состоянию. Без него копия не запустится. Для инкрементальной цепочки prepare выполняется иначе: сначала базовый каталог с —apply-log-only, затем каждый инкремент по порядку.

xtrabackup --backup --incremental-basedir=/backup/full-2026-11-01 \
  --target-dir=/backup/inc-2026-11-02
xtrabackup --prepare --apply-log-only --target-dir=/backup/full-2026-11-01
xtrabackup --prepare --target-dir=/backup/full-2026-11-01
xtrabackup --version

Для восстановления нужен пустой каталог данных и остановленный сервер. XtraBackup не перезаписывает непустой datadir, и это защита от случайной потери. После копирования выставите владельца, запустите mysqld и проверьте error log. Если сервер не стартует, чаще всего виноваты несовпадение версии, незавершённый prepare или неверные права.

Точка восстановления и автоматизация

Полная копия раз в сутки означает потерю до суток данных. Binary log позволяет откатить состояние на конкретную секунду: восстановите полный дамп, затем примените журналы до нужной позиции. Включайте log_bin, храните журналы не на том же томе и настройте срок хранения через binlog_expire_logs_seconds.

mysqlbinlog --start-datetime='2026-11-01 10:00:00' \
  --stop-datetime='2026-11-01 10:30:00' /var/log/mysql/binlog.000042 | mysql
mysql -e "SHOW BINARY LOGS"
mysql -e "PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY"
mysql -e "SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'"

Автоматизацию удобно делать systemd-таймером: он даёт журнал запусков и не зависит от почты. Скрипт должен возвращать ненулевой код при любой ошибке, проверять итоговый файл и удалять старые копии по retention. Обязательный элемент — регулярное тестовое восстановление, иначе вы проверяете только то, что скрипт отработал.

Чек-лист

  • Копия лежит на другом носителе или в другом месте.
  • Дамп содержит процедуры, триггеры, события и права доступа.
  • Пароль не виден в ps и history.
  • Файл проверен на целостность и развёрнут на тестовом сервере.
  • Версии сервера и утилиты совпадают.
  • Настроены retention и мониторинг сбоев.
  • Есть процедура восстановления на точку во времени.

Итог

mysqldump остаётся простым и предсказуемым инструментом для баз до нескольких десятков гигабайт: он переносим, читаем и не требует специальных версий. XtraBackup выигрывает на больших объёмах и даёт быстрый откат, но требует строгого соответствия версий и обязательного prepare. В любом случае ценность имеет не факт создания файла, а проверенное восстановление и понятный регламент.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте