Резервное копирование VPS: схема, инструменты и проверка восстановления
Резервная копия ценна только тогда, когда из неё можно восстановить работающий сервис за приемлемое время. Простого архива на том же диске недостаточно: нужно определить допустимую потерю данных, хранить независимые версии, шифровать их и регулярно проводить учебное восстановление.
Начните с RPO и RTO
RPO показывает, какой объём последних данных допустимо потерять. Если интернет-магазин может потерять не более 15 минут заказов, ежедневный архив не соответствует задаче. RTO определяет допустимое время восстановления: блог можно возвращать несколько часов, а платёжный API, возможно, должен подняться за десятки минут. Эти два числа задают расписание, технологию и бюджет.
Запишите цели отдельно для базы данных, пользовательских файлов, конфигурации и исходного кода. Код обычно уже находится в Git, однако секреты, загруженные изображения и состояние базы требуют собственной защиты. Чем меньше RPO и RTO, тем дороже решение: возрастает частота копирования, объём хранения, требования к сети и автоматизации восстановления.
| Тип проекта | Пример RPO | Пример RTO | Подход |
|---|---|---|---|
| Личный блог | 24 часа | 4–8 часов | Ежедневный архив и недельные версии |
| Корпоративный сайт | 4 часа | 1–2 часа | Частые копии базы, автоматическое развёртывание |
| Интернет-магазин | 15–60 минут | 30–60 минут | Журнал базы, объектное хранилище, проверенный runbook |
| Внутренняя тестовая среда | 1–7 дней | 1 день | Код и инфраструктура как код, минимум состояния |
Значения в таблице — ориентир, а не стандарт. Владелец данных должен принять последствия потери и простоя. Если вы не можете назвать RPO и RTO, резервирование почти наверняка настроено случайно.
Что именно нужно сохранять
Полный образ диска удобен для быстрого возврата машины, но плохо заменяет прикладные копии. Он может содержать повреждённую базу, уже скомпрометированный код или устаревшие секреты. Надёжная схема сочетает несколько уровней.
- База данных: логический дамп или физическая копия, созданная согласованным способом.
- Пользовательские файлы: загрузки, документы, медиа и генерируемые артефакты, которые нельзя заново получить из кода.
- Конфигурация: настройки веб-сервера, systemd, firewall, cron, контейнеров и DNS; секреты хранятся отдельно.
- Код и миграции: репозиторий, зафиксированные версии зависимостей и воспроизводимая сборка.
- Ключи восстановления: инструкция, доступ к хранилищу и ключ расшифровки, недоступные только с потерянного VPS.
Не копируйте без разбора кэш, временные файлы, логи отладки и каталоги зависимостей, которые надёжно пересоздаются. Это сокращает окно копирования и стоимость хранения. Но документируйте исключения: одна неверная маска может незаметно убрать из архива каталог с пользовательскими данными.
Правило 3-2-1 и защита от потери аккаунта
Классическое правило 3-2-1 означает три экземпляра данных, два разных типа хранения и одну копию вне основной площадки. Для VPS это может быть рабочий диск, версия в объектном хранилище другого аккаунта и периодическая копия у независимого провайдера. Важна не буквальная технология, а отсутствие единой точки отказа.
Снимок у хостера удобен перед обновлением, но не защищает от блокировки аккаунта, ошибки сотрудника, удаления проекта или сбоя одной панели управления. Синхронизация каталога тоже не всегда является резервной копией: шифровальщик или ошибочное удаление быстро попадёт на зеркало. Нужны неизменяемые либо версионируемые копии с периодом удержания.
Хранилище резервных копий должно использовать отдельные учётные данные. Рабочий сервер получает право добавлять новые объекты, но по возможности не может удалять старые версии или менять политику удержания. Административный ключ хранится вне VPS и защищается многофакторной аутентификацией.
Как корректно копировать базу данных
Архивирование каталога работающей базы файловой утилитой может получить несогласованный набор страниц: часть записей уже обновлена, часть ещё нет. Используйте штатный инструмент СУБД. Для PostgreSQL это логический дамп через pg_dump либо физическое резервирование с журналами WAL; для MySQL — mysqldump с транзакционным режимом или специализированный физический инструмент. Выбор зависит от размера и требуемого RPO.
Логический дамп проще перенести между версиями и проверить выборочно, но на большой базе он создаётся и восстанавливается долго. Физическая копия быстрее возвращает крупный кластер, зато теснее связана с версией сервера. Для малых проектов разумно делать ежедневный логический дамп и более частую защиту критических таблиц или журналов транзакций.
Сам файл дампа тоже нужно проверить: ненулевой размер ещё не означает корректность. Анализируйте код завершения команды, сохраняйте stderr, проверяйте структуру архива и периодически разворачивайте его в отдельную базу. После восстановления выполните прикладные запросы: количество пользователей, последние заказы, ссылки на загруженные файлы и запуск миграций.
Какие инструменты выбрать
| Подход | Подходит | Ограничение |
|---|---|---|
| Снимок провайдера | Быстрый откат перед изменением | Зависит от того же аккаунта и площадки |
| Restic или Borg | Шифрованные инкрементальные копии файлов | Нужны настройка политики и тест восстановления |
| Rclone | Передача в разные облачные хранилища | Синхронизация без версий может повторить удаление |
| Штатный дамп СУБД | Переносимая копия базы | На больших данных может работать долго |
| Инфраструктура как код | Быстрое создание чистого сервера | Не сохраняет пользовательское состояние |
Выбирайте инструмент, который выдаёт ненулевой код при ошибке, поддерживает шифрование, дедупликацию, политику удаления старых версий и проверку целостности. Не пишите собственный формат архива без необходимости. Чем стандартнее процедура, тем легче её передать другому администратору в аварийной ситуации.
Шифрование защищает копию у стороннего провайдера, но создаёт новую ответственность: без ключа восстановление невозможно. Храните ключ и инструкцию минимум в двух контролируемых местах. Не размещайте единственный пароль в файле на том же VPS. Передавайте данные по защищённому каналу и ограничивайте журналирование команд, чтобы секрет не оказался в истории.
Расписание, удержание и стоимость
Типовая политика «7 дневных, 4 недельных, 12 месячных» понятна, но подходит не всем. Часто изменяющаяся база требует коротких частых точек, а юридические документы — долгого хранения. Определите срок для каждого набора и проверьте требования к персональным данным: резервная копия также содержит персональные данные и должна удаляться по правилам.
Следите не только за размером исходных данных, но и за количеством версий, исходящим трафиком при восстановлении и запросами к объектному хранилищу. Дедупликация и сжатие снижают расходы, однако медиафайлы часто уже сжаты. Проведите пробное полное восстановление и посчитайте его время: дешёвое холодное хранение может иметь задержку выдачи, несовместимую с вашим RTO.
Проверка восстановления: главный тест
Создайте чистый VPS, получите конфигурацию из репозитория, установите зафиксированные версии ПО, восстановите базу и файлы, затем направьте тестовый домен. Не используйте скрытые знания работающего сервера. Если в инструкции сказано «взять конфиг оттуда», план уже зависит от узла, который может быть потерян.
- Зафиксируйте время начала и выберите конкретную точку восстановления.
- Разверните систему без доступа к боевому серверу.
- Расшифруйте архив отдельным ключом и проверьте контрольные суммы.
- Восстановите базу штатным инструментом, затем пользовательские файлы.
- Запустите миграции и smoke-тесты: вход, чтение и запись, фоновые задачи.
- Сверьте последние ожидаемые данные и измерьте фактические RPO и RTO.
- Запишите все ручные действия и обновите runbook.
Автоматическая проверка полезна между учениями: отслеживайте возраст последней успешной копии, размер, количество файлов и результат встроенной команды проверки репозитория. Уведомление «cron запустился» недостаточно — задача могла завершиться до загрузки архива.
Ошибки, которые обнаруживаются слишком поздно
- Копия хранится на том же диске. Она исчезает при удалении VPS или отказе файловой системы.
- Сохраняется только база. После восстановления отсутствуют пользовательские файлы, сертификаты или конфигурация.
- Архив никогда не разворачивали. Ошибка формата, ключа или версии становится известна во время аварии.
- Нет уведомлений. Задание не работает месяцами из-за заполненного диска или отозванного ключа.
- В копии есть секреты без шифрования. Утечка хранилища превращается в компрометацию всех сервисов.
- Нет политики удаления. Хранилище бесконтрольно растёт либо старые персональные данные сохраняются дольше необходимого.
Частые вопросы
Снимок VPS — это резервная копия?
Это полезная точка быстрого отката, но только один слой. Добавьте независимую копию базы и файлов в другом аккаунте или у другого провайдера.
Нужно ли останавливать сайт?
Обычно нет. Штатные инструменты баз данных создают согласованные копии во время работы. Для файлов приложения учитывайте операции записи и порядок копирования.
Как часто проверять восстановление?
После изменения схемы, инструмента или инфраструктуры и регулярно по календарю. Для малого проекта разумный минимум — раз в квартал, для критичного сервиса — чаще.
Где хранить ключ шифрования?
В менеджере секретов или защищённом корпоративном хранилище минимум с одной независимой аварийной копией. Не только на сервере и не рядом с зашифрованным архивом.
Полезно рядом: полная настройка безопасности VPS, расчёт ресурсов и выбор тарифа по трафику.