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

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

Блог MAATRIX · 2026-07-07

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

Содержание

  1. Правило 3-2-1 и почему бэкап критичен
  2. Дампы для разных СУБД
  3. Скрипт бэкапа с ротацией
  4. Автоматизация по cron
  5. Выгрузка копии за пределы сервера
  6. Проверка восстановления и роль хостинга

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

['Диск может выйти из строя, миграция — снести таблицу, злоумышленник — зашифровать данные. Без бэкапа любой из этих сценариев означает потерю проекта. Классический ориентир — правило 3-2-1: три копии данных, на двух разных носителях, одна — вне основного сервера.', 'Для VPS это значит: рабочая база, локальные дампы на сервере и как минимум одна копия в другом месте (другой сервер, объектное хранилище, ваш компьютер). Копия рядом с базой не спасёт, если сервер целиком станет недоступен.', '
  • 3 копии — оригинал плюс два бэкапа.
  • 2 носителя — не только диск исходного сервера.
  • 1 offsite — хотя бы одна копия вне основной машины.
']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS для базы данных

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

['Логический бэкап — самый переносимый способ. Ниже команды для трёх популярных СУБД. Для PostgreSQL используем формат custom со сжатием.', '
# PostgreSQL\npg_dump -U appuser -Fc appdb > /var/backups/pg_appdb_$(date +%F).dump\n\n# MySQL / MariaDB (согласованный снимок InnoDB)\nmysqldump --single-transaction appdb | gzip > /var/backups/mysql_appdb_$(date +%F).sql.gz\n\n# MongoDB\nmongodump --uri="mongodb://appuser:pass@127.0.0.1:27017/appdb" \\\n  --gzip --archive=/var/backups/mongo_appdb_$(date +%F).gz
', 'Флаг --single-transaction для MySQL и формат -Fc для Postgres дают согласованный снимок без длительных блокировок.']

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

['Соберём это в скрипт, который делает дамп и удаляет копии старше N дней. Иначе бэкапы забьют диск.', '
#!/bin/bash\n# /usr/local/bin/db_backup.sh\nset -euo pipefail\nBACKUP_DIR=/var/backups/db\nRETENTION_DAYS=7\nmkdir -p "$BACKUP_DIR"\nDATE=$(date +%F_%H%M)\n\npg_dump -U appuser -Fc appdb > "$BACKUP_DIR/pg_appdb_$DATE.dump"\n\n# удалить дампы старше RETENTION_DAYS\nfind "$BACKUP_DIR" -name \'*.dump\' -mtime +$RETENTION_DAYS -delete\necho "backup done: $DATE"
', '
sudo chmod +x /usr/local/bin/db_backup.sh\nsudo /usr/local/bin/db_backup.sh   # проверить вручную
', 'Флаг set -euo pipefail заставит скрипт упасть при любой ошибке, а не создать пустой битый дамп молча.']

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

['Добавляем задачу в crontab, чтобы бэкап шёл сам каждую ночь. Логи пишем в файл — так вы заметите, если бэкап перестал отрабатывать.', '
sudo crontab -e\n# ежедневно в 03:30\n30 3 * * * /usr/local/bin/db_backup.sh >> /var/log/db_backup.log 2>&1
', 'Проверить, что задача на месте, и посмотреть последние запуски:', '
sudo crontab -l\ntail -n 20 /var/log/db_backup.log
']

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

['Локальные дампы не переживут потерю сервера. Отправляйте копию на другую машину или в объектное хранилище. Простейший вариант — rsync/scp по SSH-ключу на резервный хост.', '
# синхронизация каталога бэкапов на резервный сервер\nrsync -az --delete /var/backups/db/ backup@remote-host:/srv/db_backups/\n\n# или в S3-совместимое хранилище через rclone\nrclone copy /var/backups/db/ remote_s3:mybucket/db-backups/
', 'Эту команду добавьте в конец скрипта бэкапа — тогда offsite-копия обновляется автоматически после каждого дампа.']

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

['Бэкап без теста восстановления — иллюзия безопасности. Раз в период разворачивайте дамп в тестовую базу и убеждайтесь, что данные целы.', '
# восстановить в отдельную базу для проверки\ncreatedb -U postgres appdb_restore_test\npg_restore -U postgres -d appdb_restore_test /var/backups/db/pg_appdb_2026-01-01.dump\npsql -U postgres -d appdb_restore_test -c "SELECT count(*) FROM users;"
', 'Скорость восстановления напрямую зависит от диска: разворачивание крупного дампа — это интенсивная запись. AMD EPYC + NVMe у MAATRIX сокращают время восстановления, а значит и простой в аварии. Вдобавок MAATRIX делает ежедневные бэкапы на стороне платформы — это дополнительный слой к вашим собственным дампам. Локации UK/США и оплата картой РФ, СБП, криптой или токеном MAAT удобны для зарубежного резервного хоста.', '
  • Бэкап рядом с базой — потеря сервера уносит и данные, и копии.
  • Не проверяли восстановление — узнаете о битом дампе в момент аварии.
  • Нет ротации — диск забивается, новые бэкапы падают.
']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS для базы данных

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

Как часто делать бэкап базы?

Зависит от допустимой потери данных (RPO). Для большинства проектов — ежедневно, для активно меняющихся данных добавляют почасовые дампы или непрерывный WAL-архив для PITR.

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

Логический (дамп) переносим между версиями и прост в проверке. Физический быстрее восстанавливается на больших базах и нужен для point-in-time recovery. Часто используют оба.

Зачем проверять восстановление, если дамп создаётся без ошибок?

Успешное создание не гарантирует восстановимость: битые данные, несовместимость версий, забытые расширения всплывают только при реальном restore. Тест — единственная гарантия.

Читайте также