Percona XtraBackup на Ubuntu 24.04: пошаговая установка

MAATRIX

Если вы делаете бэкап через mysqldump на боевой базе больше пары гигабайт, то знаете эту боль: дамп идёт двадцать минут, а всё это время сервер подвисает на тяжёлых запросах. Percona XtraBackup решает эту задачу иначе — копирует файлы данных напрямую, без блокировки таблиц и без остановки сервиса. Ниже — рабочая установка на Ubuntu 24.04, с полным и инкрементным бэкапом и восстановлением, без прыжков через мануалы на английском.

Чем XtraBackup лучше mysqldump

mysqldump читает данные через SQL-интерфейс и превращает их в текстовый дамп. Для баз в пределах пары гигабайт это нормально, но с ростом объёма всплывают три проблемы:

• Блокировки. Без --single-transaction дамп InnoDB-таблиц может залочить их на время выгрузки; с MyISAM блокировка неизбежна в любом случае.
• Время восстановления. Импорт SQL-дампа обратно — это заново проиграть все INSERT'ы, а не просто скопировать файлы. На базе в 50+ ГБ разница между «скопировать» и «выполнить миллион запросов» — часы.
• Нагрузка на диск и CPU. Дамп сериализует данные в текст, потом сжимает — это ощутимая нагрузка на процессор в момент бэкапа.

XtraBackup работает на физическом уровне: копирует файлы .ibd и журналы InnoDB, попутно отслеживая изменения, которые происходят во время копирования, и досогласовывает их на этапе --prepare. В результате бэкап получается консистентным без остановки записи в базу — это и называется «горячий бэкап» (hot backup). У MariaDB есть форк того же инструмента — mariabackup, с идентичным по духу синтаксисом; в статье покажу оба варианта.

Минус у подхода один: XtraBackup — это бэкап уровня файловой системы, он не годится для выборочного восстановления одной таблицы так же удобно, как SQL-дамп (хотя частичное восстановление возможно через --export). Для полной картины многие держат оба инструмента: XtraBackup — для быстрого горячего бэкапа всей базы, mysqldump — для точечных выгрузок перед миграциями.

Что понадобится и с чего начать

Дальше предполагается чистый сервер на Ubuntu 24.04 LTS (кодовое имя noble) с уже установленным MySQL 8.x, Percona Server 8.x или MariaDB 10.11/11.x. Если сервера с базой ещё нет — сначала разверните MySQL или MariaDB, а уже потом настраивайте бэкап.

Для бэкапа нужен отдельный диск или раздел с запасом свободного места минимум в размер базы данных плюс 20-30% — на время --prepare XtraBackup дописывает журналы транзакций поверх скопированных файлов, и место расходуется заметно. Держать бэкап на том же диске, где лежит /var/lib/mysql, можно, но рискованно: при переполнении диска сломается и база, и бэкап одновременно.

Установка Percona XtraBackup

Пакет XtraBackup ставится из репозитория Percona, версия должна соответствовать версии сервера баз данных: для MySQL 8.0/8.4 и Percona Server ставится ветка percona-xtrabackup-80, для более старых установок с MySQL 5.7 — percona-xtrabackup-24. Уточните нужную ветку в актуальном списке через percona-release list — Percona время от времени добавляет и переименовывает ветки под новые релизы серверов.

# подключаем репозиторий Percona
wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb
sudo dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb
sudo apt update

# смотрим доступные ветки и включаем нужную
sudo percona-release list
sudo percona-release setup pxb-8.0

sudo apt update
sudo apt install -y percona-xtrabackup-80

Проверка, что бинарник встал и видит версию:

xtrabackup --version

Если у вас MariaDB, отдельный репозиторий Percona не нужен — mariabackup идёт в комплекте с сервером MariaDB, ставится одним пакетом:

sudo apt install -y mariadb-backup
mariabackup --version

Дальше в примерах буду использовать xtrabackup, но всё написанное применимо к mariabackup — синтаксис команд практически идентичен, отличаются только имя бинарника и мелкие нюансы совместимости версий.

Пользователь для бэкапа

Заводить бэкап под root — плохая практика: если файл со скриптом бэкапа утечёт, вместе с ним утечёт полный доступ к серверу. Создайте отдельного пользователя MySQL с минимально нужными правами.

Для MySQL 8.x (с ролью BACKUP_ADMIN):

CREATE USER 'xtrabackup'@'localhost' IDENTIFIED BY 'СЛОЖНЫЙ_ПАРОЛЬ';
GRANT BACKUP_ADMIN, PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';
FLUSH PRIVILEGES;

Для MariaDB права чуть проще — BACKUP_ADMIN там не нужен:

CREATE USER 'xtrabackup'@'localhost' IDENTIFIED BY 'СЛОЖНЫЙ_ПАРОЛЬ';
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';
FLUSH PRIVILEGES;

Пароль лучше не держать открытым в командной строке и истории bash — вынесите его в файл конфигурации /etc/mysql/backup.cnf с правами 600:

[client]
user=xtrabackup
password=СЛОЖНЫЙ_ПАРОЛЬ

sudo chmod 600 /etc/mysql/backup.cnf

Первый полный бэкап

Создайте каталог под бэкапы и запустите копирование, указав конфиг с учётными данными:

sudo mkdir -p /backup/mysql/full
sudo xtrabackup --backup \
  --defaults-extra-file=/etc/mysql/backup.cnf \
  --target-dir=/backup/mysql/full

На выходе XtraBackup копирует файлы данных «как есть» и параллельно пишет в лог всё, что менялось в базе в момент копирования. В конце должна появиться строка completed OK! — если её нет, бэкап считается неудачным и доверять ему нельзя.

Скопированные файлы сами по себе ещё не готовы к восстановлению — они находятся в «сыром» состоянии, где часть транзакций зафиксирована, а часть нет. Нужен этап подготовки (prepare), который применяет журналы транзакций и приводит копию в консистентное состояние — ровно то, что при обычном старте MySQL делает InnoDB recovery:

sudo xtrabackup --prepare --target-dir=/backup/mysql/full

Именно на этом шаге расходуется дополнительное место на диске — не экономьте на нём. После успешного --prepare (снова ищите completed OK! в выводе) бэкап готов к восстановлению в любой момент, prepare второй раз запускать не нужно.

Инкрементные бэкапы

Полный бэкап базы в 100+ ГБ каждую ночь — это и время, и нагрузка на диск, и место на хранилище. XtraBackup умеет делать инкрементные копии: только те страницы данных, которые изменились с последнего бэкапа (по LSN — log sequence number InnoDB).

Схема на неделю: воскресенье — полный бэкап без --prepare (готовим позже, после накопления инкрементов), остальные дни — инкременты от предыдущего:

# воскресенье: полный бэкап без prepare
sudo xtrabackup --backup \
  --defaults-extra-file=/etc/mysql/backup.cnf \
  --target-dir=/backup/mysql/full_$(date +%F)

# понедельник: инкремент от воскресного полного
sudo xtrabackup --backup \
  --defaults-extra-file=/etc/mysql/backup.cnf \
  --target-dir=/backup/mysql/inc_$(date +%F) \
  --incremental-basedir=/backup/mysql/full_2026-08-30

# вторник: инкремент от понедельничного инкремента
sudo xtrabackup --backup \
  --defaults-extra-file=/etc/mysql/backup.cnf \
  --target-dir=/backup/mysql/inc_$(date +%F) \
  --incremental-basedir=/backup/mysql/inc_2026-08-31

Собирать цепочку в единый консистентный бэкап нужно перед восстановлением, применяя --prepare последовательно к каждому инкременту поверх полного (сначала --apply-log-only, чтобы не закрывать журнал транзакций раньше времени, и только на последнем шаге — без этого флага):

# шаг 1: подготовка полного бэкапа (без закрытия журнала)
sudo xtrabackup --prepare --apply-log-only --target-dir=/backup/mysql/full_2026-08-30

# шаг 2: накатываем первый инкремент
sudo xtrabackup --prepare --apply-log-only \
  --target-dir=/backup/mysql/full_2026-08-30 \
  --incremental-dir=/backup/mysql/inc_2026-08-31

# шаг 3 (последний инкремент в цепочке — без --apply-log-only)
sudo xtrabackup --prepare \
  --target-dir=/backup/mysql/full_2026-08-30 \
  --incremental-dir=/backup/mysql/inc_2026-09-01

Для баз, где данные меняются постепенно (логи, метрики, счётчики), инкременты экономят реально много места и времени бэкапа. Для баз с активным изменением большой доли строк каждый день (например, частым UPDATE по всей таблице) экономия скромнее — тут стоит замерить на своих данных, а не полагаться на общие цифры.

Восстановление из бэкапа

Восстановление — это остановка MySQL, замена каталога данных содержимым подготовленного бэкапа и запуск заново. Делать это стоит либо на отдельном сервере для проверки бэкапа, либо на проде — только когда база уже не в рабочем состоянии.

sudo systemctl stop mysql

# сохраняем старые данные на случай, если что-то пойдёт не так
sudo mv /var/lib/mysql /var/lib/mysql_broken_$(date +%F)
sudo mkdir /var/lib/mysql

sudo xtrabackup --copy-back --target-dir=/backup/mysql/full_2026-08-30

sudo chown -R mysql:mysql /var/lib/mysql
sudo systemctl start mysql

--copy-back копирует файлы, --move-back — переносит (быстрее, но исходный бэкап при этом исчезает — используйте только когда у вас есть его копия в другом месте). После старта проверьте логи journalctl -u mysql -n 100 на предмет ошибок и зайдите в консоль убедиться, что таблицы и строки на месте.

Обязательно тестируйте восстановление заранее, а не в момент инцидента. Бэкап, который ни разу не восстанавливали, с практической точки зрения не отличается от отсутствия бэкапа — узнать, что архив битый или неполный, лучше на тестовом сервере в спокойной обстановке, чем в 3 часа ночи во время инцидента.

Автоматизация и хранение

Ручные бэкапы работают до первого пропущенного дня. Оформите скрипт и повесьте его на cron с ротацией и переносом копий на другой сервер — если бэкап лежит на том же физическом диске, что и база, при отказе диска вы теряете и то, и другое одновременно.

#!/bin/bash
# /usr/local/bin/xtrabackup-daily.sh
set -e

DATE=$(date +%F)
BACKUP_DIR=/backup/mysql/full_$DATE
RETENTION_DAYS=14

xtrabackup --backup \
  --defaults-extra-file=/etc/mysql/backup.cnf \
  --target-dir=$BACKUP_DIR

xtrabackup --prepare --target-dir=$BACKUP_DIR

# синхронизация на другой сервер/S3-совместимое хранилище
rsync -az --delete $BACKUP_DIR/ backup-storage:/backup/mysql/full_$DATE/

# чистка старых локальных копий
find /backup/mysql -maxdepth 1 -type d -mtime +$RETENTION_DAYS -exec rm -rf {} \;

# каждый день в 2:30 ночи
30 2 * * * /usr/local/bin/xtrabackup-daily.sh >> /var/log/xtrabackup.log 2>&1

Держите как минимум одну копию вне сервера с базой — на отдельном хранилище или на другой площадке. Если у вас уже настроен внешний бэкап-сервер под другие задачи, посмотрите заодно частые причины отказа бэкапов MySQL — там разбор ситуаций, когда бэкап вроде бы отработал, а восстановиться из него не получается.

Частые вопросы