Резервное копирование базы OpenShip: облако или своё

Если у вас нет выделенного ответственного за резервирование и восстановление, выбирайте управляемую схему; самостоятельный вариант оставляйте командам с готовой процедурой и регулярными учениями.

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

Эта статья рассчитана на три группы:

• на разработчиков, которые переводят прототип AI SaaS в рабочую среду;
• на небольшие команды, хранящие сессии Agent, пользовательские файлы и бизнес-состояние;
• на технических руководителей, сравнивающих управляемую базу данных с собственным сервером и собственной ответственностью за восстановление.

Сначала определите, что именно вы обязаны восстановить

Ошибка большинства расчётов — считать резервной копией только дамп PostgreSQL. Для AI SaaS этого недостаточно. Рабочее состояние обычно состоит из нескольких независимых частей:

1. основная база PostgreSQL с пользователями, оплатами, настройками и журналами;
2. Redis, если в нём хранятся очереди, временные задания, блокировки или состояние диалога;
3. объектное хранилище с загруженными файлами, результатами генерации и вложениями;
4. состояние Agent: активные задачи, промежуточные результаты, идентификаторы сессий;
5. внешняя очередь заданий, если она не восстанавливается из основной базы;
6. секреты, ключи шифрования, переменные окружения и конфигурация приложения;
7. DNS, домены, правила доступа и параметры подключения.

Официальное описание OpenShip разделяет несколько уровней хранения: в самостоятельной установке данные экземпляра могут находиться во встроенном PGlite либо в отдельном сервере PostgreSQL, если задан DATABASE_URL. Проекты, развёртывания, домены, переменные окружения и журналы относятся к базе самого экземпляра OpenShip, а не только к базе вашего приложения. Это означает, что при аварии нужно отдельно оценивать восстановление приложения и восстановление управляющего экземпляра. Документация OpenShip о владении данными

Если вы восстановили основную базу, но не вернули пользовательские файлы или ключи шифрования, приложение формально запустится, но бизнес-сценарий будет повреждён. Поэтому сначала составьте карту состояния, а уже затем выбирайте режим резервирования.

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

Первый этап: отделите обещания OpenShip от вашей зоны ответственности

OpenShip поддерживает три формы размещения приложения: локальную, на собственном сервере и в OpenShip Cloud. В самостоятельном варианте приложение запускается на вашей машине или сервере, а подключение к серверу выполняется по SSH. В облачном варианте вычисления, маршрутизация, HTTPS и эксплуатация передаются облачной стороне. Описание моделей запуска OpenShip

Для резервного копирования важен не сам факт размещения приложения, а место, где находится источник данных:

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

На странице тарифов OpenShip сейчас указано, что облачный план ещё не запущен в полном режиме: платежи и регистрация планов приостановлены, а цены Cloud не объявлены. Там же заявлены ежедневные резервные копии и восстановление на определённый момент времени как функции будущего облачного предложения. Эти пункты нельзя превращать в обещание доступности конкретного тарифа, срока хранения или гарантированного времени восстановления. Актуальная страница планов OpenShip

Следовательно, в расчёте на 2026 год нельзя подставлять вымышленную цену OpenShip Cloud. До объявления коммерческих условий используйте переменные:

Полная стоимость = подписка
+ хранилище резервных копий
+ передача данных
+ дополнительная реплика
+ тестовая среда восстановления
+ часы инженера
+ стоимость простоя
+ ожидаемая стоимость неудачного восстановления

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

Второй этап: посчитайте не тариф, а труд команды

Самостоятельное резервирование выглядит дешёвым, пока вы учитываете только дисковое место. На практике в расчёт входят минимум пять постоянных задач:

• написание и обновление скрипта;
• выдача и ротация ключей доступа к отдельному хранилищу;
• контроль свободного места и удаление копий по политике хранения;
• уведомления о пропущенных и неполных заданиях;
• восстановление после изменения версии PostgreSQL, Redis, контейнера или схемы данных.

Для PostgreSQL официальный механизм pg_dump создаёт логический дамп, который обычно можно загрузить в более новую версию PostgreSQL; это удобнее для миграции между машинами, но не заменяет полноценную стратегию непрерывного архивирования и не включает внешние файлы приложения. Руководство PostgreSQL по SQL-дампам

Для Redis ситуация иная. RDB — снимок состояния на определённый момент, а AOF записывает операции изменения. При использовании только снимков вы принимаете риск потери изменений между последним снимком и сбоем; при AOF увеличиваются требования к диску и проверке процедуры восстановления. Официальное описание постоянного хранения Redis

Добавьте к формуле простой расчёт:

Стоимость самоуправления за месяц =
часы обслуживания × внутренняя ставка
+ хранилище
+ передача
+ тестовая инфраструктура
+ ожидаемые аварийные работы

Если вы проверяете резервные копии только после сбоя, самостоятельная схема уже не является дешёвой. Вы просто переносите оплату из строки «подписка» в строку «непредсказуемая работа ночью».

Третий этап: сравните варианты по ответственности

Не принимайте наличие кнопки «backup» за готовую систему аварийного восстановления. В официальной архитектуре OpenShip резервные копии относятся к данным управляющего API, а самостоятельная установка требует отдельной проверки того, где находится база и как она переносится. В документации также описан экспорт всего экземпляра в JSON-файл; в него входят таблицы, а секреты могут быть упакованы отдельно под пароль. Лимит импорта, указанный в документации, составляет 500 МБ. Описание экспорта и импорта OpenShip

Этот экспорт полезен как миграционный и аварийный слой, но не должен автоматически считаться полной копией производственной базы приложения. Отдельно проверяйте дампы PostgreSQL, данные Redis, объектное хранилище и секреты.

Четвёртый этап: примените решение к вашему этапу развития

Личный прототип

Для прототипа допустима упрощённая стратегия, если данные можно заново сгенерировать и в базе нет настоящих пользовательских сведений. Но «прототип» не означает «без резервной копии».

Минимальный набор:

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

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

Независимый разработчик

Для одного разработчика главный вопрос — не цена хранилища, а возможность регулярно выполнять обслуживание. Если вы не можете выделить время на проверку задания, очистку старых копий и восстановление, самостоятельный скрипт создаёт ложное чувство безопасности.

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

Небольшая команда

У команды появляется другая проблема — права и ответственность. Определите:

• кто может создать резервную копию;
• кто может скачать её;
• кто имеет доступ к ключу шифрования;
• кто инициирует восстановление;
• кто подтверждает, что приложение снова работает;
• кто получает уведомление при ошибке.

OpenShip указывает на ролевую модель, секреты и журналы действий в составе платформы, но конкретные права для резервирования нужно проверять в вашей версии и выбранной форме размещения. Обзор архитектуры и управляющего API OpenShip

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

Работающий AI SaaS

Для постоянно работающего сервиса начинайте с двух целей:

• RPO — сколько последних изменений вы готовы потерять;
• RTO — сколько времени допускается до восстановления сервиса.

Не подставляйте в эти поля произвольные значения. Для чата с повторяемыми Agent-задачами и для платёжного сервиса последствия потери одинакового объёма данных будут разными.

Затем разложите восстановление по слоям:

1. запустить базу;
2. восстановить схему и данные;
3. вернуть Redis или очередь;
4. подключить объектное хранилище;
5. восстановить секреты;
6. запустить контейнер приложения;
7. проверить авторизацию, создание задания, загрузку файла и повторное подключение Agent.

Даже если OpenShip Cloud заявляет ежедневные резервные копии и восстановление на момент времени, это не отвечает автоматически на вопрос о ваших файлах, внешних очередях и пользовательских ключах. Описание заявленных возможностей OpenShip Cloud

Пятый этап: учтите срок хранения и чувствительность данных

Срок хранения не выбирают по привычке. Сначала ответьте, как долго ошибка может оставаться незамеченной. Если пользователь удалил данные, а команда обнаружила это через несколько дней, копии младше этого периода не помогут.

Для каждой категории установите собственные правила:

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

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

Опытный ориентир: копия в том же сервере не является полноценной защитой от потери сервера. Для аварийного восстановления нужна отдельная зона хранения и независимый путь доступа к ней.

Шестой этап: проведите восстановление до покупки или запуска

Перед переходом на управляемую схему или перед запуском самостоятельного узла выполните последовательную проверку:

• [ ] Зафиксируйте список восстанавливаемых компонентов: база, Redis, файлы, Agent, очередь, секреты и конфигурация.
• [ ] Запишите допустимую потерю данных и максимальное время простоя.
• [ ] Создайте копию в отдельное хранилище, не совпадающее с основным сервером.
• [ ] Проверьте права чтения, записи и удаления старых копий.
• [ ] Сымитируйте недоступность основного сервера.
• [ ] Разверните чистую среду с совместимой версией базы.
• [ ] Восстановите PostgreSQL и проверьте ключевые таблицы.
• [ ] Восстановите Redis или очередь, если они входят в обязательный путь.
• [ ] Верните файлы и проверьте ссылки из базы.
• [ ] Подключите секреты и запустите приложение.
• [ ] Выполните реальный сценарий: вход пользователя, создание Agent-задачи, загрузка файла и чтение результата.
• [ ] Зафиксируйте время начала, время готовности и все ручные действия.
• [ ] Назначьте владельца следующего повторного учения.

NIST рассматривает планирование непрерывности как сочетание процедур, технических мер и проверки восстановления, а не только как создание копий. Поэтому статус «задание завершено» должен быть лишь первым сигналом. Доказательством служит работающая изолированная система с проверенным приложением. Материалы NIST по планированию непрерывности

Какой вариант выбрать в 2026 году

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

Выбирайте самостоятельный вариант, если у вас есть:

• отдельное хранилище;
• опыт работы с PostgreSQL и Redis;
• мониторинг не только приложения, но и резервных заданий;
• документированная процедура восстановления;
• регулярные тесты на чистой инфраструктуре;
• возможность быстро выдать доступ ответственному инженеру.

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

Для AI SaaS особенно опасен подход «восстановим только основную базу». Без файлов, Agent-состояния, очереди и ключей приложение может открыться, но не сможет продолжить работу пользователя.

Итог для вашего решения

Если сравнивать только стоимость подписки, самостоятельный OpenShip почти всегда выглядит привлекательнее. Но такой расчёт игнорирует хранение, копирование между узлами, контроль заданий, обновления, права, ночные инциденты и цену простоя. Управляемый вариант стоит рассматривать как покупку готового процесса, а не только дискового пространства.

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

Для временной тестовой среды, миграционного стенда или разработки компонентов AI SaaS вам может понадобиться отдельная машина, которую не жалко использовать для повторных восстановлений. В таком случае можно оценить аренду Mac mini для тестовой инфраструктуры или выбрать Mac mini в США для удалённой работы команды. Это не заменяет резервную копию, но позволяет отделить экспериментальную среду от рабочего узла и не превращать основной сервер в единственное место для проверки аварийного сценария.

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