Обновления, резервное копирование и восстановление

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

До выбора частоты копирования и окна обновления определите целевую точку восстановления — допустимую потерю данных — и целевое время восстановления. Критерий успеха — проверенное восстановление, а не просто наличие архивных файлов.

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

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

Создавайте резервные копии следующих компонентов:

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

Проверка восстановления должна подтвердить вход, расшифровку, повторное подключение нод, авторизацию Relay, работу Routes и сертификатов, привязки управляемых баз данных и непрерывность аудита. Резервная копия, которую ни разу не восстанавливали, не является планом восстановления.

Планируемые встроенные функции

Подключения к внешним хранилищам для всех планов и управляемые хранилища с Secure Links с Personal ожидаются в 2.11. Встроенное резервное копирование и восстановление управляемых баз данных с Personal, а также экспорт конфигурации Gateway для переноса на другой экземпляр на всех планах ожидаются в 2.12. Это ориентиры дорожной карты, а не доступные сегодня операции.

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

Соберите комплект восстановления

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

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

Комплект восстановления для ручной установки Compose

В ручном установщике используются службы app, relay, registry, postgres и redis, а также следующие постоянные тома:

Том	Для чего он нужен при восстановлении
postgres_data	пользователи, ресурсы, желаемое состояние, Tasks и метаданные аудита
gateway_data	загруженные артефакты, сгенерированная конфигурация, TLS и состояние приложения
gateway_relay_identity	идентичность локального Relay, общая для app и relay
gateway_relay_state	рабочее состояние локального Relay
gateway_registry_data	слои и манифесты приватного реестра
gateway_registry_auth	материалы подписи токенов реестра
redis_data	постоянное состояние Redis; полезно для согласованного полного восстановления, но не заменяет PostgreSQL

Сохраните также .env и использованный файл docker-compose.manual.yml. В .env находятся критичные для восстановления секреты: шифруйте его резервную копию отдельно и не прикладывайте к обращениям в поддержку.

Следующий пример создаёт короткое окно согласованной офлайн-копии. Выполняйте команды из каталога с ручным Compose-файлом:

mkdir -p gateway-recovery/{gateway_data,gateway_relay_identity,gateway_relay_state,gateway_registry_data,gateway_registry_auth,redis_data}
cp .env docker-compose.manual.yml gateway-recovery/
chmod 700 gateway-recovery
chmod 600 gateway-recovery/.env

docker compose -f docker-compose.manual.yml stop app relay registry
docker compose -f docker-compose.manual.yml exec -T postgres \
  pg_dump -U gateway -d gateway -Fc > gateway-recovery/postgres.dump
docker compose -f docker-compose.manual.yml stop redis
docker compose -f docker-compose.manual.yml cp --archive app:/var/lib/gateway/. gateway-recovery/gateway_data/
docker compose -f docker-compose.manual.yml cp --archive app:/var/lib/gateway-relay/. gateway-recovery/gateway_relay_identity/
docker compose -f docker-compose.manual.yml cp --archive relay:/var/lib/gateway-relay/state/. gateway-recovery/gateway_relay_state/
docker compose -f docker-compose.manual.yml cp --archive registry:/var/lib/registry/. gateway-recovery/gateway_registry_data/
docker compose -f docker-compose.manual.yml cp --archive app:/var/lib/gateway-registry-auth/. gateway-recovery/gateway_registry_auth/
docker compose -f docker-compose.manual.yml cp --archive redis:/data/. gateway-recovery/redis_data/
docker compose -f docker-compose.manual.yml start redis registry app relay

Перенесите gateway-recovery в зашифрованное хранилище вне хоста и проверьте там контрольную сумму. Этот пример не копирует базы данных на нодах баз данных — для данных приложений используйте штатные средства соответствующего движка.

Для восстановления на чистом совместимом хосте сначала верните .env и тот же Compose-файл, создайте остановленные Containers, скопируйте постоянные данные, запустите PostgreSQL и импортируйте дамп, а затем запускайте остальной контур управления:

docker compose -f docker-compose.manual.yml create

docker compose -f docker-compose.manual.yml cp --archive gateway-recovery/gateway_data/. app:/var/lib/gateway
docker compose -f docker-compose.manual.yml cp --archive gateway-recovery/gateway_relay_identity/. app:/var/lib/gateway-relay
docker compose -f docker-compose.manual.yml cp --archive gateway-recovery/gateway_relay_state/. relay:/var/lib/gateway-relay/state
docker compose -f docker-compose.manual.yml cp --archive gateway-recovery/gateway_registry_data/. registry:/var/lib/registry
docker compose -f docker-compose.manual.yml cp --archive gateway-recovery/gateway_registry_auth/. app:/var/lib/gateway-registry-auth
docker compose -f docker-compose.manual.yml cp --archive gateway-recovery/redis_data/. redis:/data

docker compose -f docker-compose.manual.yml up -d postgres
docker compose -f docker-compose.manual.yml cp gateway-recovery/postgres.dump postgres:/tmp/gateway.dump
docker compose -f docker-compose.manual.yml exec -T postgres \
  pg_restore -U gateway -d gateway --clean --if-exists /tmp/gateway.dump

docker compose -f docker-compose.manual.yml up -d redis registry app relay

Сначала используйте ту же версию. Проверьте вход, расшифровку секретов, идентичность Relay и свежие подключения нод до обновления. Владельцы файлов могут различаться между хостами; при ошибке прав сравните владельцев внутри исходных и восстановленных Containers, не открывая запись всем пользователям.

Процедура обновления Gateway

1. Прочитайте примечания к выпуску и требования к промежуточным версиям.
2. Подтвердите активный канал обновлений и целевую версию.
3. Проверьте свежие резервные копии PostgreSQL и постоянных томов.
4. Запишите текущие версии и дайджесты образов Gateway, Relay и демонов.
5. Проверьте состояние PostgreSQL, Redis, Relay и диска.
6. Переводите клиентские службы в режим обслуживания, только если этого требует обновление.
7. Примените поддерживаемое обновление, не заменяя постоянные тома и главные ключи.
8. Дождитесь готовности Gateway и завершения миграции схемы.
9. Проверьте Relay, вход, начальную загрузку Dashboard, повторное подключение нод, Routes и привязки баз данных.
10. Отключайте режим обслуживания только после внешней проверки.

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

Обновления демонов и Relay

Обновляйте по одному домену отказа. Для участников Relay Pool последовательно выводите каждого участника из обслуживания, обновляйте, проверяйте и возвращайте его, прежде чем переходить к следующему. Для обычных нод после повторного подключения проверяйте ресурсы, относящиеся к их роли. Не обновляйте одновременно все ноды Ingress, баз данных или Relay, если для среды не проверен независимый путь восстановления.

Процедура восстановления

1. Подготовьте чистую совместимую среду Gateway.
2. Восстановите PostgreSQL и постоянные тома из одной точки восстановления.
3. Восстановите материалы идентичности шифрования, PKI и Relay с исходными правами доступа.
4. Запустите внутренние зависимости, Gateway и Relay в документированном порядке.
5. До разрешения изменений проверьте вход и расшифровку.
6. Разрешите управляемым нодам повторно подключиться с существующими идентичностями.
7. Согласуйте с желаемым состоянием Routes, сертификаты, рабочие нагрузки, привязки баз данных, уведомления и интеграции.
8. При необходимости восстановите базы данных приложений средствами их движков.
9. Подтвердите непрерывность аудита и зафиксируйте событие восстановления.

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

Решение об откате

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

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

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

Слой	Необходимое доказательство
Идентичность	Существующие пользователи входят; MFA, OAuth и расшифровка работают
Плоскость управления	Миграции завершены; фоновые планировщики и аудит продолжают работу
Relay и ноды	Версии совместимы; ноды подключились и передали свежий инвентарь
Клиентский трафик	Внешние DNS, TLS, состояние Route и ответ приложения проверены успешно
Данные	Управляемые базы данных работоспособны, приложения выполняют запросы через привязки
Автоматизация	Используемые сборки, вебхуки, уведомления и соединители источников работают

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

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