Основные стратегии резервного копирования и восстановления MariaDB

Mariabackup - родной инструмент MariaDB для создания горячих физических резервных копий без прерывания операций базы данных. В отличие от логических резервных копий с mysqldump, Mariabackup копирует фактические файлы данных, в то время как ваша база данных продолжает обслуживать запросы. Это делает его предпочтительным методом резервного копирования для производства баз данных MariaDB, где простое время не является вариантом.

В этой статье я покажу вам от основного использования до передовых дополнительных стратегий резервного копирования для операций резервного копирования MariaDB.

Оригинальное название: Mariabackup

Mariabackup - это вилка Percona XtraBackup, специально оптимизированная для MariaDB. Он создает последовательные физические резервные копии, копируя файлы данных InnoDB и захватывая журналы транзакций во время процесса резервного копирования. Затем инструмент использует эти журналы на этапе подготовки, чтобы обеспечить последовательность резервного копирования.

Как работает Mariabackup

Процесс резервного копирования происходит в три отдельных этапа. Во-первых, Mariabackup копирует настольные файлы InnoDB, в то время как база данных работает нормально. На этом этапе копирования он также захватывает все изменения, происходящие в журнале redo. После того, как копия файла завершится, Mariabackup ненадолго приобретает глобальный замок для захвата таблиц, не входящих в InnoDB, и позиции бинарного журнала. Наконец, на этапе подготовки, Mariabackup использует захваченные записи из журнала redo, чтобы сделать резервное копирование последовательным.

Mariabackup против mysqldump

Оба инструмента создают действительные резервные копии, но они обслуживают разные случаи использования.

Особенность	Mariabackup	mysqldump
Тип резервного копирования	Физическая (файловая копия)	Логические (SQL заявления)
Горячая резервная копия	Да	Частичный
Скорость резервного копирования	Быстро	Медленно для больших баз данных
Скорость восстановления	Быстро	Медленный
Дополнительные резервные копии	Да	Нет
Точка восстановления времени	Да	Да
Кросс-версия восстановления	Только одна основная версия	Любая совместимая версия
Размер хранилища	Большие	Меньше

Для баз данных под 10 ГБ mysqldump работает отлично и предлагает лучшую портативность. Для больших баз данных или систем, требующих минимального времени простоя, Mariabackup является лучшим выбором. Многие производственные среды используют оба: Mariabackup для быстрого ежедневного резервного копирования и mysqldump для портативных еженедельных архивов.

Установка Mariabackup

Mariabackup поставляется в комплекте с MariaDB. Если у вас установлен MariaDB, у вас, вероятно, уже есть Mariabackup.

Установка на Debian/Ubuntu

Установить пакет поддержки mariadb:

1
2
sudo apt-get update
sudo apt-get install mariadb-backup

Проверка установки:

1
mariabackup --version

Установка на AlmaLinux/RHEL

Используйте yum или dnf для установки:

1
sudo yum install MariaDB-backup

Или на новых системах:

1
sudo dnf install MariaDB-backup

Совместимость

Версия Mariabackup должна соответствовать MariaDB-серверная версия. Mariabackup от MariaDB 10.6 не может резервировать сервер MariaDB 10.11. Всегда используйте Mariabackup, который поставляется с вашей установкой MariaDB.

Проверь. MariaDB версия:

1
mariadb --version

Проверь. Mariabackup версия:

1
mariabackup --version

Создание первой резервной копии

Основная команда Mariabackup требует целевого каталога, имени пользователя и пароля. Процесс резервного копирования создает полную копию файлов вашей базы данных.

Базовая резервная команда

Создайте полную резервную копию:

1
2
3
4
mariabackup --backup \
  --target-dir=/backup/full-$(date +%Y%m%d) \
  --user=backup_user \
  --password=your_password

--target-dir должен быть пустым каталогом или несуществующим (Mariabackup создает его). Никогда не используйте адресный каталог из предыдущей резервной копии.

Закрытие разрешений пользователя

Создайте выделенного резервного пользователя с минимальными необходимыми привилегиями:

1
2
3
CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'YourStrongPasswordHere';
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'backup_user'@'localhost';
FLUSH PRIVILEGES;

Структура каталога резервного копирования

После успешного резервного копирования ваш целевой каталог содержит:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
/backup/full-20260120/
├── ibdata1
├── ib_logfile0
├── ib_logfile1
├── mysql/
├── performance_schema/
├── your_database/
├── xtrabackup_checkpoints
├── xtrabackup_info
└── xtrabackup_logfile

Файл xtrabackup_checkpoints содержит резервные метаданные, включая диапазон LSN (Log Sequence Number). Эта информация необходима для дополнительных резервных копий.

Подготовка резервных копий для восстановления

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

Подготовка полной резервной копии

Запустите команду подготовки в папке резервного копирования:

1
mariabackup --prepare --target-dir=/backup/full-20260120

Во время подготовки, Mariabackup:

Прочтите захваченные записи журнала redo
Применяет совершенные транзакции к файлам данных
Отзывы к незарегистрированным сделкам
Создает чистые, последовательные файлы данных

Фаза подготовки модифицирует резервный каталог на месте. После подготовки резервная копия готова для восстановления, но больше не может использоваться в качестве базы для дополнительных резервных копий.

Подготовка материалов

Успешная подготовка показывает:

1
2
3
InnoDB: Starting shutdown...
InnoDB: Shutdown completed
completed OK!

Если вы видите ошибки во время подготовки, резервная копия может быть повреждена. Никогда не восстанавливайте из резервной копии, которая терпит неудачу в подготовке.

Восстановление из резервного копирования

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

Полная процедура восстановления

Остановите сервис MariaDB:

1
sudo systemctl stop mariadb

Удалите или переместите существующий каталог данных:

1
2
sudo mv /var/lib/mysql /var/lib/mysql.old
sudo mkdir /var/lib/mysql

Скопируйте резервные файлы в каталог данных:

1
sudo mariabackup --copy-back --target-dir=/backup/full-20260120

Владение:

1
sudo chown -R mysql:mysql /var/lib/mysql

Запустите MariaDB:

1
sudo systemctl start mariadb

Альтернативный вариант возврата

Если вам не нужно сохранять резервную копию, используйте --move-back вместо --copy-back:

1
sudo mariabackup --move-back --target-dir=/backup/full-20260120

Это перемещает файлы вместо копирования, который быстрее и использует меньше дискового пространства. Однако, ваш каталог резервного копирования становится пустым после этой операции.

Проверка восстановления

Подключение к MariaDB и проверьте ваши данные:

1
2
mariadb -u root -p -e "SHOW DATABASES;"
mariadb -u root -p -e "SELECT COUNT(*) FROM your_database.your_table;"

Проверьте журнал ошибок для любых проблем:

1
sudo tail -100 /var/log/mysql/error.log

Дополнительные резервные копии

Дополнительные резервные копии захватывают только изменения с момента последнего резервного копирования, уменьшая время резервного копирования и потребности в хранении. Они работают, записывая LSN в каждой резервной копии и только копируя страницы, измененные после этого LSN.

Создание дополнительной резервной копии

Во-первых, создайте полную резервную копию в качестве базы:

1
2
3
4
mariabackup --backup \
  --target-dir=/backup/base \
  --user=backup_user \
  --password=your_password

Создание первой дополнительной резервной копии:

1
2
3
4
5
mariabackup --backup \
  --target-dir=/backup/inc1 \
  --incremental-basedir=/backup/base \
  --user=backup_user \
  --password=your_password

Создание последующих дополнительных резервных копий на основе предыдущего:

1
2
3
4
5
mariabackup --backup \
  --target-dir=/backup/inc2 \
  --incremental-basedir=/backup/inc1 \
  --user=backup_user \
  --password=your_password

Подготовка дополнительных резервных копий

Дополнительные резервные копии требуют многоступенчатого процесса подготовки. Во-первых, подготовьте базовое резервное копирование с возможностью --apply-log-only:

1
mariabackup --prepare --apply-log-only --target-dir=/backup/base

Флаг --apply-log-only предотвращает фазу отката, что сделает резервное копирование непригодным для применения дополнительных изменений.

Применить первую постепенную резервную копию:

1
2
3
mariabackup --prepare --apply-log-only \
  --target-dir=/backup/base \
  --incremental-dir=/backup/inc1

Применить второе дополнительное резервное копирование:

1
2
3
mariabackup --prepare --apply-log-only \
  --target-dir=/backup/base \
  --incremental-dir=/backup/inc2

Для окончательного инкрементного резервного копирования, запустите без --apply-log-only:

1
mariabackup --prepare --target-dir=/backup/base

Эта заключительная подготовка завершает фазу опрокидывания и делает резервное копирование ресторируемым.

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

Общая производственная стратегия сочетает еженедельные полные резервные копии с ежедневными дополнительными резервными копиями:

Воскресенье: Полная резервная копия
Понедельник-Суббота: Дополнительные резервные копии на основе предыдущего дня

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

Поток резервного копирования

Mariabackup поддерживает потоковую резервную копию вывода непосредственно на другой сервер или инструмент сжатия. Это устраняет необходимость временного местного хранения.

Поток в файл

Создайте сжатый архив резервного копирования:

1
2
3
4
mariabackup --backup \
  --stream=xbstream \
  --user=backup_user \
  --password=your_password | gzip > /backup/backup_$(date +%Y%m%d).xbstrea

Поток на удаленный сервер

Отправка резервных копий непосредственно на удаленный сервер через SSH:

1
2
3
4
5
mariabackup --backup \
  --stream=xbstream \
  --user=backup_user \
  --password=your_password | \
  ssh backup-server "cat > /backup/backup_$(date +%Y%m%d).xbstream"

Извлечение потоковых резервных копий

Вычтите архив xbstream перед подготовкой:

1
2
3
mkdir /backup/extracted
cd /backup/extracted
xbstream -x < /backup/backup_20260120.xbstream.gz

Тогда готовьтесь и восстанавливайте, как обычно.

Частичные резервные копии

Mariabackup может резервировать определенные базы данных или таблицы, полезные, когда вам только нужно защитить определенные данные или иметь ограниченное хранение.

Поддержка конкретных баз данных

Используйте параметр --database для резервного копирования выбранных баз данных:

1
2
3
4
5
mariabackup --backup \
  --target-dir=/backup/partial \
  --databases="production inventory" \
  --user=backup_user \
  --password=your_password

Закрытие конкретных таблиц

Резервное копирование отдельных таблиц с параметром --tables:

1
2
3
4
5
mariabackup --backup \
  --target-dir=/backup/tables \
  --tables="production.orders production.customers" \
  --user=backup_user \
  --password=your_password

Частичные ограничения резервного копирования

Частичные резервные копии имеют ограничения:

Невозможно восстановить сервер (требует полной замены каталога данных)
Таблица пространства системы InnoDB (ibdata1) всегда включается
Внешние ключевые отношения могут вызвать проблемы, если исключить соответствующие таблицы

В большинстве случаев полные резервные копии с выборочной реставрацией обеспечивают большую гибкость, чем частичные резервные копии.

Зашифрованные резервные копии

Mariabackup поддерживает шифрование AES для защиты резервных файлов в состоянии покоя. Шифрование происходит во время процесса резервного копирования, поэтому незашифрованные данные никогда не касаются диска.

Создание зашифрованных резервных копий

Создание ключа шифрования:

1
2
openssl rand -base64 32 > /etc/mysql/backup.key
chmod 600 /etc/mysql/backup.key

Создание зашифрованного резервного копирования:

1
2
3
4
5
6
mariabackup --backup \
  --target-dir=/backup/encrypted \
  --encrypt=AES256 \
  --encrypt-key-file=/etc/mysql/backup.key \
  --user=backup_user \
  --password=your_password

Расшифровка резервных копий

Расшифровка перед подготовкой:

1
2
3
mariabackup --decrypt=AES256 \
  --encrypt-key-file=/etc/mysql/backup.key \
  --target-dir=/backup/encrypted

Затем подготовьтесь и восстанавливайте нормально.

Ключевое управление

Храните ключи шифрования отдельно от резервных файлов. Если злоумышленник получает доступ к вашим резервным копиям, но не к ключам, ваши данные остаются защищенными. Рассмотрите возможность использования ключевых служб управления, таких как OpenBao - форк Vault с открытой лицензией.

Скрипты автоматизации резервного копирования

Для среды, где вы предпочитаете автоматизацию на основе скриптов, вот готовый к производству сценарий резервного копирования.

Полный сценарий резервного копирования

Создайте /usr/local/bin/mariadb-backup.sh:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
#!/bin/bash
set -euo pipefail

BACKUP_BASE="/backup/mariadb"
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="$BACKUP_BASE/full-$DATE"
LOG_FILE="/var/log/mariadb-backup.log"
RETENTION_DAYS=7

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$LOG_FILE"
}

log "Starting full backup to $BACKUP_DIR"

mariabackup --backup \
  --target-dir="$BACKUP_DIR" \
  --user=backup_user \
  --password="$(cat /etc/mysql/backup.password)" \
  2>> "$LOG_FILE"

log "Preparing backup"

mariabackup --prepare --target-dir="$BACKUP_DIR" 2>> "$LOG_FILE"

log "Backup completed successfully"

# Cleanup old backups
find "$BACKUP_BASE" -maxdepth 1 -type d -name "full-*" -mtime +$RETENTION_DAYS -exec rm -rf {} \;

log "Cleanup completed, removed backups older than $RETENTION_DAYS days"

Сделайте его исполняемым и расписанием с cron:

1
chmod +x /usr/local/bin/mariadb-backup.sh

Добавить в crontab для ежедневных резервных копий 3 утра:

1
0 3 * * * /usr/local/bin/mariadb-backup.sh

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

Создайте /usr/local/bin/mariadb-incremental.sh:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
#!/bin/bash
set -euo pipefail

BACKUP_BASE="/backup/mariadb"
DATE=$(date +%Y%m%d_%H%M%S)
DAY_OF_WEEK=$(date +%u)
LOG_FILE="/var/log/mariadb-backup.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$LOG_FILE"
}

# Sunday (day 7) = full backup, other days = incremental
if [ "$DAY_OF_WEEK" -eq 7 ]; then
    BACKUP_DIR="$BACKUP_BASE/base"
    rm -rf "$BACKUP_DIR"

    log "Starting weekly full backup"

    mariabackup --backup \
      --target-dir="$BACKUP_DIR" \
      --user=backup_user \
      --password="$(cat /etc/mysql/backup.password)" \
      2>> "$LOG_FILE"
else
    # Find the most recent backup directory
    LAST_BACKUP=$(ls -td "$BACKUP_BASE"/*/ 2>/dev/null | head -1)
    BACKUP_DIR="$BACKUP_BASE/inc-$DATE"

    log "Starting incremental backup based on $LAST_BACKUP"

    mariabackup --backup \
      --target-dir="$BACKUP_DIR" \
      --incremental-basedir="$LAST_BACKUP" \
      --user=backup_user \
      --password="$(cat /etc/mysql/backup.password)" \
      2>> "$LOG_FILE"
fi

log "Backup completed: $BACKUP_DIR"

Контроль и проверка

Резервные копии бесполезны, если они не восстанавливаются. Регулярная проверка улавливает проблемы до того, как они станут чрезвычайными ситуациями.

Сценарий проверки

Создайте сценарий, который проверяет восстановление на временный экземпляр /usr/local/bin/verify-incremental.sh:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#!/bin/bash
set -euo pipefail

BACKUP_DIR="/backup/mariadb/full-latest"
TEST_DATA_DIR="/tmp/mariadb-test"
TEST_PORT=3307

# Clean up previous test
rm -rf "$TEST_DATA_DIR"
mkdir -p "$TEST_DATA_DIR"

# Copy backup to test directory
mariabackup --copy-back --target-dir="$BACKUP_DIR" --datadir="$TEST_DATA_DIR"

# Fix permissions
chown -R mysql:mysql "$TEST_DATA_DIR"

# Start test instance
mariadbd --datadir="$TEST_DATA_DIR" --port=$TEST_PORT --socket=/tmp/mysql-test.sock &
TEST_PID=$!

sleep 10

# Verify databases exist
mariadb -P $TEST_PORT -S /tmp/mysql-test.sock -e "SHOW DATABASES;"

# Run table checks
mariadb -P $TEST_PORT -S /tmp/mysql-test.sock -e "CHECK TABLE production.orders;"

# Cleanup
kill $TEST_PID
rm -rf "$TEST_DATA_DIR"

echo "Backup verification completed successfully"

Мониторинг резервного здравоохранения

Отслеживать эти метрики для обеспечения надежности резервного копирования:

Продолжительность резервного копирования: Замедленное повышение показателей
Размер резервного копирования: Неожиданные изменения могут сигнализировать о проблемах данных
Последняя успешная резервная копия: Если старше, чем ожидалось
Успех подготовки: Неудачная подготовка означает непригодную резервную копию

Настройте оповещения для резервных сбоев. Пропущенное резервное копирование лучше обнаружить сразу, чем во время кризиса.

Передовая практика

В соответствии с этими практиками обеспечивается надежное, надежное резервное копирование операций.

Правило резервного копирования 3-2-1:

3 копии ваших данных: производственная база данных, локальное резервное копирование и удаленное резервное копирование
2 различных типа носителей: локальное дисковое и облачное хранилище
1 место за пределами участка: различное физическое местоположение от производства

Это защищает от аппаратных сбоев, стихийных бедствий на сайте и атак выкупа.

Регулярное восстановление

Расписание ежемесячных восстановительных испытаний:

Выберите случайную резервную копию с предыдущей недели
Восстановление в тестовой среде
Проверка целостности и полноты данных
Время восстановления документов

Защищайте свои резервные копии

Резервные копии содержат все ваши данные о производстве. Защитите их соответственно:

Зашифровать резервные копии в покое
Ограничение доступа к резервному хранению
Записи доступа к архивам аудита
Храните ключи шифрования отдельно от резервных копий

Завершение

Mariabackup предоставляет быстрые, надежные горячие резервные копии для баз данных MariaDB любого размера. Его способность резервного копирования без блокировки операций делает его необходимым для производственных систем, где время простоя стоит денег. Начните с простых полных резервных копий, добавьте дополнительные резервные копии по мере роста вашей базы данных и внедрить шифрование для чувствительных данных.

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

Вы можете поделиться статьей со своими друзьями в социальных сетях, которым может быть интересна эта статья или просто оставить комментарий ниже. Спасибо.

Оригинальное название: Mariabackup#

Как работает Mariabackup#

Mariabackup против mysqldump#

Установка Mariabackup#

Установка на Debian/Ubuntu#

Установка на AlmaLinux/RHEL#

Совместимость#

Создание первой резервной копии#

Базовая резервная команда#

Закрытие разрешений пользователя#

Подготовка резервных копий для восстановления#

Подготовка полной резервной копии#

Подготовка материалов#

Восстановление из резервного копирования#

Полная процедура восстановления#

Альтернативный вариант возврата#

Проверка восстановления#

Дополнительные резервные копии#

Создание дополнительной резервной копии#

Подготовка дополнительных резервных копий#

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

Поток резервного копирования#

Поток в файл#

Поток на удаленный сервер#

Извлечение потоковых резервных копий#

Частичные резервные копии#

Поддержка конкретных баз данных#

Закрытие конкретных таблиц#

Частичные ограничения резервного копирования#

Зашифрованные резервные копии#

Создание зашифрованных резервных копий#

Расшифровка резервных копий#

Ключевое управление#

Скрипты автоматизации резервного копирования#

Полный сценарий резервного копирования#

Инкрементальный сценарий резервного копирования#

Контроль и проверка#

Сценарий проверки#

Мониторинг резервного здравоохранения#

Передовая практика#

Правило резервного копирования 3-2-1:#

Регулярное восстановление#

Защищайте свои резервные копии#

Завершение#