Восстановление

Содержание

Восстановление#

Восстановление выполняется применением манифеста ресурса AstraAutomationRestore. Каждое восстановление развертывает новый комплект компонентов; процедура не удаляет существующие компоненты.

Поддерживаются два сценария:

восстановление на новых ресурсах рядом с исходной платформой (рекомендуемый сценарий), при котором исходный экземпляр платформы продолжает работать, восстановленный используется для проверки копии или переноса данных;
восстановление на месте с тем же названием ресурсов и заменой исходной платформы (см. Восстановление на месте).

Автоматическое восстановление рассчитано на применение внутренней СУБД PostgreSQL, развернутой в кластере (type: managed в секрете конфигурации базы данных шлюза платформы). Если компоненты платформы используют внешнюю СУБД PostgreSQL, ресурс AstraAutomationRestore применять нельзя. Используйте ручную процедуру, описанную в инструкции.

Важно

Восстановленная платформа – это полная копия исходной платформы, потребляющая сопоставимые ресурсы кластера. Перед восстановлением убедитесь в выполнении всех пунктов контрольного списка. После проверки удалите восстановленную платформу, если она создавалась только для проверки копии (см. Удаление восстановленной платформы).

Восстановление на новых ресурсах#

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

Создайте файл restore.yaml с манифестом ресурса:
```
apiVersion: aa.astra-automation.ru/v1alpha1
kind: AstraAutomationRestore
metadata:
  name: restore-20260717-0900
  namespace: astra-automation
spec:
  deployment_name: aa-restored
  backup_name: backup-20260716-1430
  hostname: aa-restored.example.com
  ingress_tls_secret: aa-restored-tls
```
Здесь:
- deployment_name – название нового экземпляра платформы; под этим названием будет развернут отдельный комплект компонентов;
- backup_name – название ресурса AstraAutomationBackup с восстанавливаемой копией;
- hostname – собственное название узла восстановленного экземпляра платформы;
- ingress_tls_secret – секрет с сертификатом TLS, действительным для нового названия узла.
Если исходный экземпляр платформы продолжает работать в том же кластере, поля hostname и ingress_tls_secret необходимо задать, так как без них восстановленный экземпляр наследует адрес исходного, и контроллер ingress отклонит дублирующийся узел – ресурс останется в состоянии Failure до смены адреса (см. Адрес восстановленного экземпляра).
Примените манифест:
```
kubectl apply -f restore.yaml
```

Дождитесь завершения восстановления:

kubectl -n astra-automation wait aarestore/restore-20260717-0900 \
  --for=condition=Successful --timeout=45m
kubectl -n astra-automation wait \
  acrestore/restore-20260717-0900-controller \
  edarestore/restore-20260717-0900-eda \
  pahrestore/restore-20260717-0900-hub \
  dashboardrestore/restore-20260717-0900-dashboard \
  --for=condition=Successful --timeout=45m

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

При восстановлении оператор выполняет следующие действия:

Развертывает новый экземпляр внутренней PostgreSQL и дожидается его готовности.
Восстанавливает секреты из копии под новыми названиями (<deployment>-gateway-postgres-configuration и подобными) и подменяет в них адрес базы данных на новый экземпляр. Адрес подменяется также в секретах компонентов, которые указывали на ту же внутреннюю базу данных, что и шлюз платформы. Секреты, указывающие на внешнюю СУБД с другим адресом, не изменяются. В такой смешанной конфигурации компонент восстановленного экземпляра использует ту же внешнюю базу данных, что и исходный. Для смешанных конфигураций и внешней СУБД используйте ручную процедуру (см. Восстановление при внешней СУБД).
Восстанавливает базы данных из дампов и применяет поверх них миграции.
Развертывает компоненты нового экземпляра и дочерний Automation Dashboard (<deployment>-dashboard).
При использовании файлового хранилища Private Automation Hub (storage_type: File) восстанавливает контент. Отдельное задание Kubernetes (Job) копирует каталог pulp/ из копии в новый том PVC (Persistent Volume Claim) <hub-name>-file-storage.

Здесь:

<deployment> – название нового экземпляра платформы из поля deployment_name;
<hub-name> – название ресурса Private Automation Hub нового экземпляра платформы (<deployment>-hub).

Примечание

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

Адрес восстановленного экземпляра#

Файл aa_object резервной копии хранит полностью секцию spec исходного ресурса, включая поля hostname, public_base_url, ingress_class_name и ingress_tls_secret. По умолчанию эти поля наследуются как есть, что необходимо, когда восстановление выполняется взамен утраченного исходного экземпляра платформы, так как адрес должен сохраниться.

Если исходный экземпляр продолжает работать, задайте новому экземпляру собственный адрес в ресурсе AstraAutomationRestore:

hostname – новое название узла ingress. Публичный URL при этом выводится автоматически как https://<hostname>;
public_base_url – задается, только если публичный URL должен отличаться от https://<hostname>, например при работе за внешним балансировщиком. Явное значение имеет приоритет над выведенным. Публичный URL используется всеми компонентами восстановленного экземпляра; без его замены они бы обращались по адресу исходного;
ingress_tls_secret – секрет с сертификатом для нового названия узла. Оператор не выпускает сертификаты: без переопределения восстановленный экземпляр платформы отдает сертификат исходного, недействительный для нового названия узла. Подготовьте секрет заранее.

При заданных полях восстановленный экземпляр платформы запускается на своем адресе сразу. Конфликта в ingress и состояния Failure не возникает.

Примечание

При ingress_type: route поле hostname не влияет на адрес маршрута (им управляет поле route_host), и публичный URL из него не выводится. Задавайте public_base_url явно.

Проверка восстановленных данных#

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

Для проверки подключитесь к контроллеру восстановленного экземпляра платформы напрямую, минуя ingress:

# Трансляция порта к сервису контроллера восстановленного экземпляра платформы
kubectl -n astra-automation port-forward svc/aa-restored-controller-service 18080:80 &

# Пароль администратора восстановленного экземпляра платформы
PASS=$(kubectl -n astra-automation get secret <admin-password-secret> \
       -o jsonpath='{.data.password}' | base64 -d)

# Список организаций
curl -ks http://localhost:18080/api/v2/organizations/ -u "admin:$PASS" \
  | python3 -m json.tool

Здесь:

<admin-password-secret> – секрет *-admin-password контроллера восстановленного экземпляра платформы. Название можно уточнить командой kubectl -n astra-automation get secret | grep admin-password.

Пароль администратора после восстановления совпадает с паролем исходного экземпляра платформы; он восстановлен из копии.

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

Каталог файлов проектов Automation Controller (/var/lib/awx/projects/) в резервную копию не входит (см. состав копии). Записи проектов восстанавливаются, содержимое каталога – нет. Проекты из системы контроля версий синхронизируйте повторно; каталоги локальных проектов перенесите из сохраненной отдельно копии.

Повторное восстановление и создание базы данных заново#

Восстановление рассчитано на наполнение пустой базы данных из дампа. Новый экземпляр PostgreSQL развертывается с пустыми базами данных, и pg_restore --clean --if-exists проходит без ошибок. Если восстановление выполняется в непустую базу данных (например, при повторном запуске после сбоя поверх частично восстановленных данных), команда pg_restore --clean завершается ошибками вида cannot drop ... because other objects depend on it, и восстановление останавливается.

Для таких случаев предназначено поле force_drop_db: true, приводящее к тому, что перед восстановлением база данных создается заново (DROP DATABASE IF EXISTS ... WITH (FORCE) и CREATE DATABASE), после чего она заполняется из дампа. Поле, заданное в корневом ресурсе, действует и на базы данных дочерних компонентов, включая Automation Dashboard. Режим рекомендуется для восстановления с внутренней PostgreSQL в производственной среде, где пустота целевой базы данных не гарантирована:

spec:
  deployment_name: aa-demo
  backup_name: backup-20260716-1430
  force_drop_db: true

При использовании поля force_drop_db учитывайте следующие правила:

Для каждого повторного восстановления создавайте ресурс AstraAutomationRestore с новым названием.
Повторное создание базы данных выполняется под административной ролью PostgreSQL, так как прикладные роли компонентов создаются без привилегии CREATEDB. Для внутренней PostgreSQL дополнительных действий не требуется, поскольку пароль административной роли уже содержится в секрете конфигурации базы данных и передается дочерним ресурсам восстановления. У Automation Dashboard повторное создание внутренней базы данных выполняется через локальный сокет в поде PostgreSQL. Пароль также не требуется.
Если база данных компонента находится во внешней СУБД, восстановление безопасно прервется до удаления базы данных с сообщением в журнале оператора. Данные при этом не теряются. Ограничение можно снять ключом postgres_admin_password в секрете конфигурации базы данных (при необходимости также ключом postgres_admin_user, по умолчанию postgres). Снимайте его, только если целевая база данных принадлежит восстановленному экземпляру и не используется работающим исходным, например при восстановлении отдельного компонента ресурсом DashboardRestore в собственную новую базу данных. В смешанной конфигурации восстановленные секреты указывают на базы данных работающего исходного экземпляра, поэтому применять поле force_drop_db нельзя. Повторное создание уничтожило бы данные исходного экземпляра. Корневое восстановление при полностью внешней СУБД не поддерживается (см. Восстановление при внешней СУБД).
Перед удалением базы данных выполняется предварительная проверка на существование роли-владельца и наличие привилегий на повторное создание. База данных удаляется, только если ее повторное создание гарантированно возможно.

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

Восстановление на месте#

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

Предупреждение

Процедура является деструктивной, так как исходный экземпляр платформы удаляется, и единственной точкой возврата остается созданная ранее резервная копия. Для проверки копии используйте восстановление в новый экземпляр платформы (см. Восстановление на новых ресурсах).

Восстановление на месте поверх работающей платформы не поддерживается. При восстановлении дочерние компоненты развертываются под названиями <deployment>-controller, <deployment>-hub, <deployment>-eda, <deployment>-dashboard, тогда как при установке платформы названия компонентов задаются в манифесте явно (например, ac-demo, pah-demo, eda-demo). Запуск восстановления с использованием названия работающей платформы без предварительного удаления ее ресурса AstraAutomation приводит к развертыванию рядом с работающими компонентами их дублей на тех же данных. В результате возникает конфликт в ingress, смешение сервисных узлов в базе данных шлюза и перезапись секрета авторизации Automation Dashboard.

Для восстановления на месте выполните следующие действия:

Удалите исходный ресурс AstraAutomation:
```
kubectl -n astra-automation delete aa aa-demo
```
Удалите ресурс StatefulSet внутренней PostgreSQL и ее том PVC, иначе схема базы данных не будет создана заново:
```
kubectl -n astra-automation delete sts aa-demo-postgres-15
kubectl -n astra-automation delete pvc postgres-15-aa-demo-postgres-15-0
```
Ресурс StatefulSet базы данных Automation Dashboard удаляется каскадом вместе с ресурсом AstraAutomation, но его том PVC (postgres-15-aa-demo-dashboard-postgres-15-0) удалите вручную. Вместо удаления томов для непустой базы данных можно использовать поле force_drop_db: true (см. Повторное восстановление и создание базы данных заново).
Убедитесь, что пространство имен и тома PVC с резервными копиями не затронуты. Удалять их нельзя. В них находятся дампы.
Создайте ресурс AstraAutomationRestore с тем же названием экземпляра платформы:
```
spec:
  deployment_name: aa-demo
  backup_name: backup-20260716-1430
```

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

Повторное восстановление с полем force_drop_db: true допустимо только поверх экземпляра платформы, ранее созданного процедурой восстановления. Названия его дочерних компонентов уже соответствуют шаблону <deployment>-*.

Удаление восстановленной платформы#

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

Восстановленный комплект намеренно отвязан от сборщика мусора Kubernetes. Ссылки ownerReferences сняты, чтобы восстановленная платформа не удалялась вместе с ресурсом восстановления. Поэтому удаление одного корневого ресурса не удаляет восстановленную платформу; удаляйте по шагам:

N=astra-automation
D=aa-restored           # Название восстановленного экземпляра платформы
R=restore-20260717-0900 # Название ресурса AstraAutomationRestore
T=aa-restored-tls       # Секрет из поля ingress_tls_secret не удаляется

# 1. Ресурсы компонентов: каскадом удаляются их ресурсы Deployment и поды
kubectl -n $N delete acs/$D-controller edas/$D-eda pahs/$D-hub
kubectl -n $N delete dashboards $D-dashboard

# 2. Корневой ресурс: каскадом удаляются шлюз и Redis
kubectl -n $N delete aas $D

# 3. Ресурс восстановления: владеет ресурсом StatefulSet базы данных восстановленного экземпляра
kubectl -n $N delete aarestores $R

# 4. Оставшиеся ресурсы без ownerReferences
kubectl -n $N delete pvc $D-hub-file-storage postgres-15-$D-postgres-15-0 \
  postgres-15-$D-dashboard-postgres-15-0

# 5. Просмотр секретов восстановленного экземпляра
kubectl -n $N get secret --no-headers | awk '{print $1}' | grep "^$D-" | grep -v "^$T$"

Предупреждение

Выборка секретов выполняется по началу названия (^$D-). Если в кластере работает другой экземпляр платформы, название которого начинается с $D- (например, aa-restored и aa-restored-2), его секреты тоже попадут в выборку. Не используйте пересекающиеся названия экземпляров.

Убедитесь, что в списке только секреты восстановленного экземпляра, затем удалите их:

kubectl -n $N get secret --no-headers | awk '{print $1}' | grep "^$D-" \
  | grep -v "^$T$" | xargs -r kubectl -n $N delete secret

Убедитесь, что вывод следующей команды пуст (намеренно сохраненный секрет TLS $T исключен из проверки):

kubectl -n $N get pods,deploy,sts,svc,pvc,secret,ingress --no-headers | grep $D | grep -v "^secret/$T"

Процедура не затрагивает тома PVC с резервными копиями и каталоги копий. Команды не удаляют секрет TLS (переменная T – значение поля ingress_tls_secret ресурса восстановления), подготовленный вручную перед восстановлением. Удалите его отдельно, когда он перестанет быть нужным.

Предупреждение

Не удаляйте ресурс AstraAutomationRestore отдельно от процедуры выше. Он владеет ресурсом StatefulSet базы данных восстановленного экземпляра. Его удаление уничтожит базу данных, оставив остальные компоненты без данных. Дочерние ресурсы *Restore удаляются каскадом вместе с корневым.