Как установить и настроить бэкап MySQL на VPS

MAATRIX

Бэкап MySQL на VPS — это не разовая команда, а выстроенный процесс: регулярные копии, хранение отдельно от базы, проверка восстановления и, где нужно, возможность откатиться на конкретный момент. База без бэкапа рано или поздно превращается в потерю данных — от случайного DROP TABLE до отказа диска. Ниже — рабочий путь настройки надёжного резервного копирования MySQL: логические и физические бэкапы, автоматизация, хранение вне сервера и восстановление на точку во времени.

Логический или физический бэкап

Есть два принципиально разных подхода, и выбор зависит от размера базы. Логический бэкап через mysqldump выгружает данные в виде SQL-команд: он универсален, читаем, легко переносится между версиями и серверами, но медленно восстанавливается на больших объёмах. Для баз до нескольких десятков гигабайт это идеальный вариант.

Физический бэкап через Percona XtraBackup копирует сами файлы данных «на горячую», без остановки базы. Он быстро снимается и быстро восстанавливается даже на терабайтных базах, но привязан к версии и формату хранения. Для крупных нагруженных баз это правильный выбор. Практическое правило: пока mysqldump укладывается в приемлемое время бэкапа и восстановления — используйте его, он проще. Когда база вырастает и дамп занимает часы — переходите на XtraBackup.

Локация базы и бэкапа тоже важна. Держите копии не только на том же VPS: для российских проектов удобно хранить основную базу на RU-сервере, а копии выгружать на отдельное хранилище или второй сервер. Так вы защищены и от отказа диска, и от потери всего сервера целиком.

Логический бэкап через mysqldump

Базовая команда снимает согласованную копию без блокировки таблиц InnoDB — сайт продолжает работать во время бэкапа:

mysqldump -u root --single-transaction --routines --triggers --events appdb > /var/backups/appdb_$(date +%F).sql

Разберём флаги. --single-transaction открывает одну транзакцию и снимает согласованный снимок для InnoDB без блокировок. --routines, --triggers и --events включают в дамп хранимые процедуры, триггеры и события, о которых часто забывают, — без них восстановленная база окажется неполной. Для экономии места сразу сжимайте дамп на лету:

mysqldump -u root --single-transaction --routines --triggers appdb | gzip > /var/backups/appdb_$(date +%F).sql.gz

Сжатие уменьшает размер в разы и экономит место и трафик при переносе копий. Восстановление из сжатого дампа делается так же просто: gunzip < файл.sql.gz | mysql -u root appdb. Если баз несколько, добавьте --all-databases, но тогда в дамп попадут и системные таблицы — учитывайте это при восстановлении.

Автоматизация через cron

Ручной бэкап бесполезен: рано или поздно вы забудете его сделать именно перед сбоем. Автоматизируйте. Создайте скрипт, который снимает дамп, сжимает его и удаляет копии старше нужного срока:

#!/bin/bash
BACKUP_DIR=/var/backups/mysql
mkdir -p $BACKUP_DIR
mysqldump -u root --single-transaction --routines --triggers appdb | \
  gzip > $BACKUP_DIR/appdb_$(date +\%F_\%H%M).sql.gz
find $BACKUP_DIR -name "appdb_*.sql.gz" -mtime +14 -delete

Сохраните его, дайте права на выполнение и добавьте в cron, например ежедневно в 3 часа ночи:

0 3 * * * /usr/local/bin/mysql_backup.sh

Строка find ... -mtime +14 -delete держит копии за две недели и удаляет старые, чтобы диск не переполнялся. Настройте глубину хранения под свои задачи: для критичных данных имеет смысл держать ежедневные копии за две недели плюс еженедельные за пару месяцев. Пароль root лучше не хранить в скрипте открытым — используйте файл ~/.my.cnf с правами 600, где указаны логин и пароль, тогда mysqldump возьмёт их автоматически.

Хранение копий вне сервера

Бэкап, лежащий на том же диске, что и база, — это иллюзия защиты. При отказе диска или потере сервера пропадёт и база, и копии. Правило «3-2-1» простое: минимум три копии, на двух разных носителях, одна из них — вне сервера. Настройте выгрузку дампов на отдельное хранилище: второй VPS, объектное хранилище или удалённый сервер по SSH:

scp $BACKUP_DIR/appdb_$(date +%F)*.sql.gz backup@10.0.0.30:/backups/

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

Восстановление на точку во времени

Обычный дамп восстанавливает состояние на момент снятия. Но что, если ошибочный DELETE случился через шесть часов после ночного бэкапа? Здесь спасают бинарные логи (binlog), которые записывают все изменения. Включите их в конфиге MySQL:

[mysqld]
log_bin = /var/lib/mysql/mysql-bin
binlog_expire_logs_seconds = 1209600

Теперь у вас есть непрерывная запись изменений. Восстановление на точку во времени идёт в два шага: сначала разворачиваете последний полный дамп, затем «докатываете» бинлоги до нужного момента, останавливаясь прямо перед ошибочной командой:

mysqlbinlog --stop-datetime="2026-08-24 14:29:00" mysql-bin.000042 | mysql -u root appdb

Это позволяет вернуть базу в состояние за секунду до аварии, а не откатываться на всю ночь назад. Настройте автоматическую очистку бинлогов через binlog_expire_logs_seconds, чтобы они не забили диск, и следите за их объёмом.

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

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

gunzip < appdb_latest.sql.gz | mysql -u root test_restore
mysql -u root test_restore -e "SHOW TABLES; SELECT COUNT(*) FROM users;"

Такая проверка выявляет проблемы заранее: неполный дамп, битый архив, забытые процедуры. Лучше найти изъян на учениях, чем в момент реальной аварии. Хорошая практика — не просто развернуть дамп, а сверить контрольные показатели: число строк в ключевых таблицах, суммарный размер базы, наличие всех процедур и триггеров. Тогда вы убеждаетесь не только в том, что дамп технически разворачивается, но и в том, что он содержит все данные. Отдельно измеряйте время восстановления: если развернуть базу из дампа занимает четыре часа, это и есть ваше реальное время простоя при аварии, и его стоит знать заранее, а не выяснять в критический момент. Когда это время становится неприемлемым, пора переходить с логического бэкапа на физический через XtraBackup. Чтобы всё это работало, нужен сервер с местом под копии и, желательно, второй VPS под резервное хранилище. В MAATRIX можно арендовать серверы под MySQL и бэкапы в России, США или Великобритании и оплатить картой РФ, по СБП, криптой или токеном MAAT — иностранная карта не нужна.

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