Как установить и настроить резервное копирование БД на VPS

MAATRIX

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

Стратегия 3-2-1: основа надёжности

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

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

Определите два ключевых параметра. RPO — сколько данных вы готовы потерять (час, сутки): он задаёт частоту бэкапов. RTO — сколько времени готовы восстанавливаться: он влияет на выбор между логическим и физическим бэкапом. Эти два числа определяют всю стратегию, и лучше осознать их заранее, чем выяснять в час аварии. Например, интернет-магазину, где заказы приходят каждую минуту, суточный RPO не подходит — потеря целого дня заказов недопустима, и нужны либо частые копии, либо непрерывный журнал изменений. А блогу или справочному сайту, где данные меняются раз в неделю, ежедневного бэкапа с запасом хватает. Не бывает универсально правильной частоты: она выводится из ценности данных и скорости их изменения. Отдельно продумайте бэкап перед рискованными операциями — обновлением версии СУБД, крупной миграцией схемы, массовым удалением: разовая ручная копия прямо перед таким действием много раз спасала проекты от необратимых последствий.

Логический бэкап для разных СУБД

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

pg_dump -Fc appdb > /var/backups/appdb_$(date +%F).dump

MySQL или MariaDB:

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

MongoDB:

mongodump --db appdb --archive=/var/backups/appdb_$(date +%F).archive --gzip

Общий принцип у всех один: снимать согласованную копию, не блокируя базу (-Fc и сжатый формат у PostgreSQL, --single-transaction у MySQL, --gzip у MongoDB), и сразу сжимать результат для экономии места. Логический бэкап универсален, читаем и переносится между версиями, но на больших базах медленно восстанавливается. Пока время снятия и восстановления вас устраивает — это правильный выбор.

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

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

#!/bin/bash
set -euo pipefail
BDIR=/var/backups/db
mkdir -p $BDIR
FILE=$BDIR/appdb_$(date +%F_%H%M).dump
pg_dump -Fc appdb > $FILE
scp $FILE backup@10.0.0.30:/backups/
find $BDIR -name "appdb_*.dump" -mtime +14 -delete

Строка set -euo pipefail заставляет скрипт остановиться при любой ошибке, а не молча продолжить с битым бэкапом — это критично. Добавьте задачу в cron, например ежедневно ночью:

0 3 * * * /usr/local/bin/db_backup.sh >> /var/log/db_backup.log 2>&1

Логируйте вывод, чтобы видеть историю и ловить сбои. Настройте глубину хранения под свой RPO: для важных данных держите ежедневные копии за две недели плюс еженедельные за пару месяцев. Ротация через find -mtime не даёт копиям забить диск.

Хранение вне сервера и шифрование

Удалённая копия — сердце стратегии 3-2-1. Варианты разные: второй VPS, объектное хранилище, удалённый сервер по SSH. Ключевое требование — копия должна быть физически отдельно от основного сервера, желательно в другой локации или у другого провайдера. Передачу удобно делать по SSH через scp или rsync, который копирует только изменения и экономит трафик.

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

pg_dump -Fc appdb | gpg --symmetric --cipher-algo AES256 -o /var/backups/appdb.dump.gpg

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

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

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

Заодно замеряйте время восстановления — это и есть ваш реальный RTO, время простоя при аварии. Если развернуть базу занимает четыре часа, вы должны знать это заранее, а не узнавать под давлением. Когда время становится неприемлемым, переходите на физический бэкап или добавляйте реплику как горячий резерв. Учения на тестовом восстановлении превращают бэкап из формальности в реальную страховку. Чтобы всё это работало, удобно иметь второй сервер под удалённые копии. В MAATRIX можно арендовать VPS под базы и резервное хранилище в России, США или Великобритании и оплатить картой РФ, по СБП, криптой или токеном MAAT — иностранная карта не нужна.

Автоматический контроль и оповещения

Бэкап, который молча падает, хуже отсутствия бэкапа — он создаёт ложное чувство защищённости. Настройте контроль: скрипт должен сообщать об успехе и особенно о провале. Простейший вариант — оповещение в мессенджер или на почту при ошибке, а также проверка, что итоговый файл не пустой и не подозрительно мал. Мониторьте свободное место на диске с бэкапами заранее, чтобы копирование не сорвалось из-за переполнения. Эти простые меры отличают настоящую систему резервного копирования от набора команд, которые однажды перестали работать, а никто не заметил.

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