Бэкап базы данных на VPS: автоматизация и проверка

Бэкап, который никто не проверял восстановлением, — это не бэкап. Разберём, как снимать дампы PostgreSQL, MySQL и MongoDB, автоматизировать их по cron с ротацией, выгружать копии за пределы сервера и главное — регулярно проверять восстановление.

Правило 3-2-1 и почему бэкап критичен

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

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

• 3 копии — оригинал плюс два бэкапа.
• 2 носителя — не только диск исходного сервера.
• 1 offsite — хотя бы одна копия вне основной машины.

Дампы для разных СУБД

Логический бэкап — самый переносимый способ. Ниже команды для трёх популярных СУБД. Для PostgreSQL используем формат custom со сжатием.

# PostgreSQL
pg_dump -U appuser -Fc appdb > /var/backups/pg_appdb_$(date +%F).dump

# MySQL / MariaDB (согласованный снимок InnoDB)
mysqldump --single-transaction appdb | gzip > /var/backups/mysql_appdb_$(date +%F).sql.gz

# MongoDB
mongodump --uri="mongodb://appuser:pass@127.0.0.1:27017/appdb" \
  --gzip --archive=/var/backups/mongo_appdb_$(date +%F).gz

Флаг --single-transaction для MySQL и формат -Fc для Postgres дают согласованный снимок без длительных блокировок.

Скрипт бэкапа с ротацией

Соберём это в скрипт, который делает дамп и удаляет копии старше N дней. Иначе бэкапы забьют диск.

#!/bin/bash
# /usr/local/bin/db_backup.sh
set -euo pipefail
BACKUP_DIR=/var/backups/db
RETENTION_DAYS=7
mkdir -p "$BACKUP_DIR"
DATE=$(date +%F_%H%M)

pg_dump -U appuser -Fc appdb > "$BACKUP_DIR/pg_appdb_$DATE.dump"

# удалить дампы старше RETENTION_DAYS
find "$BACKUP_DIR" -name '*.dump' -mtime +$RETENTION_DAYS -delete
echo "backup done: $DATE"

sudo chmod +x /usr/local/bin/db_backup.sh
sudo /usr/local/bin/db_backup.sh   # проверить вручную

Флаг set -euo pipefail заставит скрипт упасть при любой ошибке, а не создать пустой битый дамп молча.

Автоматизация по cron

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

sudo crontab -e
# ежедневно в 03:30
30 3 * * * /usr/local/bin/db_backup.sh >> /var/log/db_backup.log 2>&1

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

sudo crontab -l
tail -n 20 /var/log/db_backup.log

Выгрузка копии за пределы сервера

Локальные дампы не переживут потерю сервера. Отправляйте копию на другую машину или в объектное хранилище. Простейший вариант — rsync/scp по SSH-ключу на резервный хост.

# синхронизация каталога бэкапов на резервный сервер
rsync -az --delete /var/backups/db/ backup@remote-host:/srv/db_backups/

# или в S3-совместимое хранилище через rclone
rclone copy /var/backups/db/ remote_s3:mybucket/db-backups/

Эту команду добавьте в конец скрипта бэкапа — тогда offsite-копия обновляется автоматически после каждого дампа.

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

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

# восстановить в отдельную базу для проверки
createdb -U postgres appdb_restore_test
pg_restore -U postgres -d appdb_restore_test /var/backups/db/pg_appdb_2026-01-01.dump
psql -U postgres -d appdb_restore_test -c "SELECT count(*) FROM users;"

Скорость восстановления напрямую зависит от диска: разворачивание крупного дампа — это интенсивная запись. AMD EPYC + NVMe у MAATRIX сокращают время восстановления, а значит и простой в аварии. Вдобавок MAATRIX делает ежедневные бэкапы на стороне платформы — это дополнительный слой к вашим собственным дампам. Локации UK/США/РФ и оплата картой РФ, СБП, криптой или токеном MAAT удобны для зарубежного резервного хоста.

• Бэкап рядом с базой — потеря сервера уносит и данные, и копии.
• Не проверяли восстановление — узнаете о битом дампе в момент аварии.
• Нет ротации — диск забивается, новые бэкапы падают.

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