Резервное копирование облачного приложения: план и проверка восстановления

Резервная копия облачного приложения складывается из пяти вещей: кода, конфигурации, базы данных, файлов на томах и секретов. На DADA Cloud код и конфигурация лежат в git, образы прошлых выкаток позволяют вернуться без пересборки, а базы PostgreSQL копируются по расписанию и хранятся 14 дней. В консоли расписания копий томов нет, и точки восстановления на произвольный момент у баз нет: эту часть вы закрываете своей рутиной, она описана в шаге 3.

Шаг 1 - Решите, что копировать и сколько можно потерять

Начните с таблицы: где живёт каждая часть приложения и кто её копирует.

Теперь два числа. RPO (recovery point objective) отвечает на вопрос, сколько данных вы готовы потерять: это время между последней копией и сбоем. RTO (recovery time objective) отвечает на вопрос, сколько вы готовы ждать, пока всё снова заработает. У магазина, где каждый час приносит заказы, RPO может быть час. У внутреннего сервиса сутки терпимы.

В PostgreSQL восстановление на произвольный момент строится на непрерывном архиве журнала (WAL), оно описано в документации PostgreSQL. На DADA Cloud такого режима нет, восстановление идёт из дампа. Поэтому ваш RPO для базы равен интервалу между дампами: при почасовом расписании до часа, при суточном до суток.

Шаг 2 - Включите то, что даёт платформа

Git. Конфигурация приложения хранится в git, и любая её версия остаётся в истории. Прошлую версию настроек можно найти в истории коммитов.

Образы. Каждая выкатка сохраняется как неизменяемый образ. На вкладке выкатов приложения кнопка Rollback разворачивает прошлую версию без новой сборки. Откат возвращает код, данные базы он не меняет. Подробности про выкатки в документации.

База данных. Расписание копий выбирается в форме базы: раз в час, в сутки или в неделю. Копии хранятся как файлы pg_dump в объектном хранилище платформы ровно 14 дней, и этот срок не зависит от выбранного расписания. Выполняются они по одной за раз на всю платформу, так что точное время дампа не гарантировано. В консоли доступны три действия:

• создать копию сейчас, например перед рискованной миграцией;
• восстановить базу из готовой копии: это перезапишет текущее содержимое этой базы;
• скачать дамп по ссылке, которая действует 5 минут.

Эти действия есть только в консоли, MCP-инструментов для них нет. Про сами базы: облачные базы данных и страница баз.

Шаг 3 - Добавьте собственную рутину

Две вещи платформа не закрывает: вторую копию базы вне платформы и копии томов.

Дамп базы по расписанию. Возьмите строку подключения в консоли (её показ записывается в аудит) и положите в секреты вашего планировщика. Затем запускайте дамп на своём сервере или в CI:

pg_dump --format=custom --no-owner --file="app-$(date +%F).dump" "$DATABASE_URL"

Версия pg_dump должна быть не старше сервера: на 10 ноября 2026 это PostgreSQL 17.5, и более старый клиент откажется снимать дамп. Результат шифруйте и отправляйте в своё хранилище, лучше у другого провайдера, а срок хранения задавайте сами: платформа держит свои копии только 14 дней. Заранее проверьте, что подключение с вашего сервера проходит: из разных стран мы доступ к базе не проверяли.

Тома. В консоли расписания снимков томов нет. Для каждого тома в консоли есть экспорт в архив tar.gz по ссылке на 15 минут, там же файловый браузер. Делайте экспорт по календарю, например раз в неделю, а если автоматизируете его через API, сначала убедитесь на своём токене, что вызов экспорта доступен. Надёжнее вообще не хранить единственную копию пользовательских файлов на томе: пишите их сразу во внешнее объектное хранилище.

Секреты. listEnvVars маскирует секретные значения, поэтому переменные платформы копией секрета не считаются. Держите оригиналы в своём менеджере секретов.

Код. Добавьте второй git-remote у другого сервиса и обновляйте его автоматически.

Шаг 4 - Запишите порядок восстановления

Составьте короткую инструкцию, которую сможет выполнить дежурный в три часа ночи.

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

Шаг 5 - Проверьте восстановление

Копия, которую никогда не разворачивали, остаётся гипотезой. Проверяйте на отдельной базе, никогда на рабочей: восстановление из консоли перезапишет её.

1. Скачайте дамп из консоли или возьмите свой из хранилища.
2. Поднимите чистый PostgreSQL: docker run -d -e POSTGRES_PASSWORD=test -p 55432:5432 postgres:17.
3. Определите формат командой pg_restore --list файл. Если команда не читает файл, это обычный SQL, загружайте его через psql -f. Иначе используйте pg_restore --no-owner --dbname=....
4. Сравните число строк в основных таблицах и запустите приложение против восстановленной копии.
5. Запишите, сколько всё это заняло: это ваш реальный RTO.

Повторяйте проверку после каждой крупной смены схемы и хотя бы раз в квартал. Вместе с проверкой попробуйте и откат релиза, порядок развёртывания описан в руководстве как развернуть веб-приложение.

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

Что такое RPO и RTO простыми словами?

RPO показывает, за какой период вы можете потерять данные, а RTO показывает, сколько приложение может быть недоступно после сбоя. Первое определяется частотой копий, второе временем восстановления, которое вы измеряете пробным запуском.

Можно ли восстановить базу на конкретный момент времени?

Нет. Восстановление на произвольный момент на DADA Cloud недоступно: база восстанавливается из дампа целиком. Чтобы потерять меньше данных, выбирайте почасовое расписание и снимайте копию вручную перед рискованными изменениями.

Сколько хранятся копии базы?

14 дней. Этот срок один для всех копий и не зависит от выбранного расписания. Если нужен более долгий архив, складывайте свои дампы в собственное хранилище.

Делает ли платформа снимки томов?

В консоли расписания нет. Для тома есть экспорт в tar.gz по запросу. Периодичность и хранение копий определяете вы.

Что произойдёт с данными при удалении базы?

Удаление выполняется через консоль или API. Мы не обещаем ни сохранности данных после него, ни их уничтожения, поэтому перед удалением скачайте дамп.

Как часто проверять восстановление?

После каждой существенной смены схемы и не реже раза в квартал. Проверка нужна, чтобы знать реальный RTO и убедиться, что дамп читается.

Источники

• PostgreSQL: резервное копирование
• PostgreSQL: непрерывное архивирование и восстановление на момент времени
• Документация: сборки и выкатки