Архитектура резервного копирования

Содержание

Архитектура резервного копирования#

Резервное копирование и восстановление платформы в кластере Kubernetes выполняются операторами Astra Automation декларативно:

Администратор создает ресурс резервного копирования или восстановления.
Оператор выполняет операцию и отражает результат в статусе ресурса.

Операторы и ресурсы#

За каждый компонент платформы отвечает собственная пара ресурсов:

Компонент	Оператор	Ресурс резервного копирования	Ресурс восстановления
Шлюз платформы и общие компоненты	`aa-operator-aa-manager`	`AstraAutomationBackup`	`AstraAutomationRestore`
Automation Controller	`ac-operator-ac-manager`	`AutomationControllerBackup`	`AutomationControllerRestore`
Event-Driven Automation	`eda-operator-eda-manager`	`EDABackup`	`EDARestore`
Private Automation Hub	`pah-operator-pah-manager`	`PrivateAutomationHubBackup`	`PrivateAutomationHubRestore`
Automation Dashboard (средства аналитики)	`dashboard-operator-dashboard-manager`	`DashboardBackup`	`DashboardRestore`

Ресурс AstraAutomationBackup является корневым. При его создании корневой оператор создает четыре дочерних ресурса *Backup с названиями <name>-controller, <name>-eda, <name>-hub и <name>-dashboard. Здесь:

<name> – название ресурса AstraAutomationBackup.

После завершения резервного копирования поле status корневого ресурса содержит ссылки на дочерние ресурсы и расположение копии:

status:
  backupClaim: aa-demo-backup-claim
  backupDirectory: /backups/aa-k8s-backup-2026-05-15-13:54:42
  controllerBackup: aa-demo-backup-controller
  edaBackup: aa-demo-backup-eda
  hubBackup: aa-demo-backup-hub
  dashboardBackup: aa-demo-backup-dashboard

Ресурс AstraAutomationRestore работает аналогично, то есть по ссылкам из ресурсов *Backup он создает дочерние ресурсы AutomationControllerRestore, EDARestore, PrivateAutomationHubRestore и DashboardRestore.

Механизм резервного копирования имеет следующие особенности:

Каждый компонент записывает свою часть копии в собственный Persistent Volume Claim (PVC) с названием <name>-backup-claim. Корневой ресурс не агрегирует данные. Резервная копия состоит из пяти раздельных томов. Здесь:
- <name> – название ресурса компонента; для Automation Dashboard – это название ресурса Dashboard, обычно <deployment>-dashboard;
- <deployment> – название ресурса AstraAutomation.
Все ресурсы резервного копирования и восстановления создаются в том же пространстве имен, где работают операторы и ресурс AstraAutomation (обычно astra-automation). Роль операторов RBAC ограничена пределами пространства имен.
Встроенного планировщика резервного копирования и политики хранения копий в платформе нет. Расписание следует настраивать с помощью задания cron на узле управления кластером, а ротацию копий выполнять периодическим удалением старых ресурсов *Backup (см. Резервное копирование по расписанию).

Состав резервной копии#

Один ресурс AstraAutomationBackup сохраняет состояние всех компонентов экземпляра платформы. В резервную копию входит следующее содержимое:

дампы пяти баз данных PostgreSQL: шлюза платформы, Automation Controller, Event-Driven Automation, Private Automation Hub и Automation Dashboard (pg_dump в формате custom);
полностью секции spec ресурса AstraAutomation и всех дочерних ресурсов, включая Dashboard;
содержимое всех секретов, на которые ссылаются поля spec: пароли, ключи шифрования, конфигурации баз данных, сертификаты TLS, секреты доступа к репозиториям образов и к образам сред исполнения;
контент Private Automation Hub при использовании файлового хранилища (storage_type: File). Содержимое каталога /var/lib/pulp/ копируется в каталог pulp/ резервной копии в томе PVC реестра.

В резервную копию не входит следующее содержимое:

тома PVC с данными компонентов (кроме контента Private Automation Hub): дампы Redis и каталог проектов Automation Controller /var/lib/awx/projects/;
контент Private Automation Hub при использовании хранилища S3 (storage_type: S3). Операторы не копируют объекты хранилища (bucket) и не восстанавливают их. Bucket переносится отдельно (см. Хранилище Private Automation Hub);
ресурсы ConfigMap и секреты, не упомянутые в секции spec;
настройки ingress, не описанные в ресурсе AstraAutomation.

При необходимости сохраняйте данные Redis и каталог проектов Automation Controller отдельно, например снимками томов средствами хранилища.

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

Резервная копия включает содержимое всех секретов экземпляра платформы в открытом виде (файл secrets.yml): пароли, ключи шифрования, сертификаты TLS, учетные данные репозиториев. Доступ к томам PVC с копиями и к любому месту выгрузки копий равнозначен доступу ко всем секретам платформы. Обращайтесь с копиями так же, как с самими секретами. Ограничивайте доступ к томам и хранилищам копий. Шифруйте копии при передаче за пределы кластера (см. Обновления и резервное копирование).

Примечание

Резервные копии, созданные в версии 2.0 платформы, не содержат данных Automation Dashboard. При восстановлении такой копии Automation Dashboard восстановленного экземпляра платформы остается отключенным, а его название заменяется на <deployment>-dashboard. Данные при этом не теряются, так как данных Automation Dashboard в такой копии нет. Пока исходный экземпляр платформы работает в том же кластере, оставьте Automation Dashboard восстановленного экземпляра платформы отключенным. Если исходная платформа не работоспособна (восстановление происходит в другом кластере или взамен утраченного), компонент можно включить. Он будет создан пустым:

kubectl -n astra-automation patch aa <deployment> --type=merge \
  -p '{"spec":{"dashboard":{"disabled":false}}}'

Структура файлов резервной копии#

В томе PVC каждого компонента резервная копия хранится в отдельном каталоге:

<name>-backup-claim/
└── <prefix>-<timestamp>/
    ├── <component>.db      # Дамп базы данных в формате custom
    ├── <spec-file>         # Содержимое spec исходного ресурса
    └── secrets.yml         # Содержимое секретов, на которые ссылается spec

Здесь:

<name> – название ресурса компонента;
<timestamp> – дата и время создания копии;
<prefix>, <component>.db, <spec-file> – названия, зависящие от компонента (приведены в таблице ниже).

Названия каталогов и файлов по компонентам:

Компонент	Префикс каталога (`<prefix>`)	Дамп базы данных (`<component>.db`)	Файл spec (`<spec-file>`)
Шлюз платформы	`aa-k8s-backup`	`aa.db`	`aa_object`
Automation Controller	`ac-k8s-backup`	`ac.db`	`ac_object`
Event-Driven Automation	`eda-k8s-backup`	`eda.db`	`eda_object`
Private Automation Hub	`pah-k8s-backup`	`pulp.db`	`pah_object`
Automation Dashboard	`dashboard-k8s-backup`	`dashboard.db`	`dashboard_object`

При использовании файлового хранилища Private Automation Hub рядом с дампом реестра находится каталог pulp/ с контентом.

Примечание

Резервные копии, созданные в версии 2.0 платформы, используют другие названия каталогов и файлов (aa-openshift-backup, tower-openshift-backup, awx_object, tower.db и подобные). Процесс восстановления читает оба формата, поэтому преобразование таких копий не требуется.