Бэкап VPS, который переживёт падение провайдера: схема 3-2-1, Restic, rclone и проверка восстановления

Утром VPS перестал отвечать. Панель провайдера тоже недоступна. Снапшот можно открыть только там, а ночной архив лежит в /backup на том же сервере. Формально копии создавались, но восстановить проект негде и не из чего.

Надёжность бэкапа измеряется не числом архивов, а ответом на один вопрос: получится ли поднять сайт на чистом VPS у другой компании, не имея доступа к старому серверу и кабинету его провайдера?

Как выглядит схема 3-2-1 для VPS

Правило 3-2-1 означает три экземпляра данных, два типа хранилища и одну копию за пределами основной площадки. Для сайта или SaaS-сервиса схема может выглядеть так:

• основные данные находятся на VPS;
• быстрый снапшот хранится у VPS-провайдера и помогает откатиться после неудачного обновления;
• зашифрованный репозиторий Restic размещён у независимого поставщика объектного или файлового хранилища.

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

Restic отвечает за бэкап, rclone — за доступ к хранилищу

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

Минимальная инициализация репозитория выглядит так:

install -d -m 700 /etc/restic
export RCLONE_CONFIG='/etc/restic/rclone.conf'

rclone config
rclone lsd offsite:

openssl rand -base64 48 > /etc/restic/repository-password
chmod 600 /etc/restic/rclone.conf /etc/restic/repository-password

export RESTIC_REPOSITORY='rclone:offsite:backups/vps-01'
export RESTIC_PASSWORD_FILE='/etc/restic/repository-password'

restic init

Здесь offsite — имя удалённого подключения из конфигурации rclone. Restic сам запускает rclone для обмена данными, поэтому открывать отдельный сетевой сервис не требуется. Такой формат репозитория описан в официальной документации Restic.

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

Не следует заменять Restic командой rclone sync. Синхронизация делает назначение похожим на источник и может перенести ошибочное удаление или повреждение. Версионные снимки Restic сохраняют предыдущие состояния. Для второй независимой копии безопаснее использовать отдельный репозиторий и restic copy, а не синхронизировать его рабочие файлы вслепую.

Что сохранять кроме каталога сайта

Бэкапа /var/www недостаточно. Нужны пользовательские загрузки, конфигурация веб-сервера, .env, Docker Compose, unit-файлы systemd, задания cron, правила firewall, список пакетов и порядок запуска. DNS-записи и доступ к регистратору тоже должны быть доступны без старого VPS.

Отдельная задача — база данных. Простое копирование файлов работающей MySQL или PostgreSQL не гарантирует согласованное состояние. Нужен штатный дамп СУБД, остановка приложения на время копирования либо корректно подготовленный файловый снапшот.

Restic умеет получать дамп прямо из команды и учитывать код её завершения:

restic backup 
  --stdin-filename production.sql 
  --stdin-from-command -- 
  mysqldump --defaults-extra-file=/root/.my.cnf 
  --single-transaction --quick production

restic backup /etc /home /srv /var/www --tag automated

Так безопаснее, чем обычный конвейер mysqldump | restic backup --stdin: при неудачном дампе нельзя получать пустой файл под видом успешной копии. Механизм --stdin-from-command разбирается в документации Restic.

Расписание, хранение и контроль

Сначала определяют RPO — сколько данных допустимо потерять, и RTO — сколько времени бизнес может ждать восстановления. Для сайта-визитки может хватить ночной копии, а магазину с заказами потребуется более частый дамп базы.

Restic не содержит встроенного планировщика, поэтому бэкап запускают через systemd timer или cron. Задачи не должны пересекаться, а мониторинг обязан замечать не только ошибку, но и отсутствие запуска. Код возврата Restic 3 означает неполный снимок из-за непрочитанных файлов — считать его успехом нельзя.

Политику хранения сначала проверяют без удаления:

restic forget --keep-daily 7 --keep-weekly 5 
  --keep-monthly 12 --keep-yearly 3 --dry-run

# После проверки, отдельной еженедельной задачей:
restic forget --keep-daily 7 --keep-weekly 5 
  --keep-monthly 12 --keep-yearly 3 --prune

restic check

prune может долго блокировать удалённый репозиторий и создавать заметный трафик, поэтому запускать его после каждого бэкапа не нужно. Перед первым удалением снимков обязателен --dry-run. Подробности работы политик хранения есть в руководстве Restic.

Для защиты от взломанного VPS одной шифрации недостаточно: она скрывает содержимое, но не мешает удалить копии. Нужны отдельные учётные данные, ограничение прав на удаление, versioning или object lock на стороне хранилища и, в идеале, вторая копия, недоступная с рабочего сервера.

Если основной VPS размещён в QCKL, внешний Restic-репозиторий всё равно следует держать у независимого поставщика хранилища. Это не недоверие к площадке, а нормальное разделение рисков: рабочий сервер и аварийная копия не должны зависеть от одного кабинета, платёжного профиля и инфраструктуры.

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

Команда restic snapshots подтверждает наличие снимков, restic check проверяет структуру репозитория, а restic check --read-data читает и криптографически проверяет все сохранённые данные. Для большого хранилища полную проверку можно разбить на последовательные части: --read-data-subset=1/5, затем 2/5 и так далее. При этом следует учитывать время и стоимость исходящего трафика. Режимы проверки описаны в документации Restic.

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

restic snapshots --host vps-01
restic ls SNAPSHOT_ID
restic restore SNAPSHOT_ID --target /mnt/restore-test

Лучше указывать конкретный SNAPSHOT_ID, а восстанавливать сначала в пустой каталог, не поверх рабочего проекта. Затем нужно импортировать базу, установить зависимости, поднять веб-сервер и проверить авторизацию, формы, пользовательские файлы, фоновые задания и отправку почты. Время от создания нового VPS до первого успешного запроса и будет реальным RTO.

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