Создание резервной копии

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

Резервная копия создается применением манифеста ресурса AstraAutomationBackup.

Создание копии#

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

  1. Создайте файл backup.yaml с манифестом ресурса:

    apiVersion: aa.astra-automation.ru/v1alpha1
kind: AstraAutomationBackup
metadata:
  name: backup-20260716-1430
  namespace: astra-automation
spec:
  deployment_name: aa-demo
  clean_backup_on_delete: true

    Здесь:

    • name – уникальное название ресурса. Рекомендуется включать в название метку времени; название ранее удаленного ресурса нельзя использовать повторно (см. Уникальность названий ресурсов);

    • deployment_name – название ресурса AstraAutomation, состояние которого сохраняется;

    • clean_backup_on_delete – удалять каталог копии из тома PVC (Persistent Volume Claim) при удалении ресурса. Флаг передается всем дочерним ресурсам *Backup (см. Хранение и ротация копий).

    Остальные поля описаны в справочнике.

  2. Примените манифест:

    kubectl apply -f backup.yaml

  3. Дождитесь завершения резервного копирования, то есть условия Successful на корневом и всех дочерних ресурсах:

    kubectl -n astra-automation wait aabackup/backup-20260716-1430 \
  --for=condition=Successful --timeout=30m
kubectl -n astra-automation wait \
  acbackup/backup-20260716-1430-controller \
  edabackup/backup-20260716-1430-eda \
  pahbackup/backup-20260716-1430-hub \
  dashboardbackup/backup-20260716-1430-dashboard \
  --for=condition=Successful --timeout=30m

    Продолжительность зависит от объема баз данных и контента Private Automation Hub.

Корневой ресурс дожидается завершения всех дочерних, поэтому условие Successful=True на корневом ресурсе гарантирует успех всех компонентов. Состояние Failure=True любого дочернего ресурса переводит в Failure=True и корневой ресурс. Причина указана в событиях корневого ресурса и в выводе kubectl describe дочернего ресурса.

После завершения дампы находятся в томах PVC компонентов (<name>-backup-claim) в каталогах вида <prefix>-<timestamp> (например, aa-k8s-backup-<timestamp> у шлюза платформы).

Здесь:

  • <name> – название ресурса компонента;

  • <prefix> – префикс каталога, зависящий от компонента;

  • <timestamp> – дата и время создания копии.

Расположение копии корневого ресурса указано в полях status.backupClaim и status.backupDirectory. Структура файлов приведена в описании архитектуры.

Поля backup_pvc, backup_storage_class, backup_storage_requirements и clean_backup_on_delete, заданные в корневом ресурсе, передаются во все дочерние ресурсы *Backup, включая DashboardBackup.

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

При общем томе backup_pvc для всех компонентов учитывайте режим доступа тома, так как поды резервного копирования пяти операторов монтируют один том PVC, и в хранилище с режимом доступа RWO (ReadWriteOnce) это требует их выполнения на одном узле кластера. Рекомендуется оставить каждому компоненту отдельный том PVC (поведение по умолчанию).

Уникальность названий ресурсов#

Названия ресурсов *Backup нельзя использовать повторно после удаления ресурса. Корневой оператор ожидает завершения дочерних резервных копирований до 60 минут, и обработка удаленного ресурса продолжается до истечения этого времени. Новый ресурс с тем же названием встанет в очередь за удаленным ресурсом и не начнет работу.

Если новый ресурс AstraAutomationBackup длительное время остается без статуса, выполните одно из следующих действий:

  • создайте ресурс заново с другим названием (рекомендуется);

  • дождитесь истечения времени ожидания (до 60 минут);

  • перезапустите под оператора:

    kubectl -n astra-automation rollout restart deploy/aa-operator-aa-manager

Для исключения совпадения названий включайте в название ресурса метку времени, например backup-20260716-1430.

Резервное копирование по расписанию#

Встроенного планировщика в платформе нет. Для регулярного резервного копирования используйте задание cron на узле управления кластером, то есть на узле с настроенной утилитой kubectl. Задание создает ресурсы AstraAutomationBackup по расписанию и удаляет старые ресурсы, оставляя заданное число последних успешных копий. Внешние образы контейнеров для этого не требуются. Готовый сценарий и настройка задания cron приведены в типовой настройке.

Хранение и ротация копий#

Каталоги резервных копий накапливаются в томах PVC. Удаление ресурса *Backup удаляет каталог копии из тома PVC только при clean_backup_on_delete: true. Поскольку по умолчанию его значение равно false, каталоги остаются, и том PVC со временем гарантированно заполнится.

Флаг достаточно задать в корневом ресурсе AstraAutomationBackup, после чего он передается дочерним ресурсам, и при удалении корневого ресурса дочерние удаляются каскадом с очисткой их каталогов. Это относится и к каталогу Private Automation Hub с контентом (самой объемной части копии), и к каталогу Automation Dashboard. Очистка каталога занимает обычно 30–60 секунд.

Если очистка невозможна (том PVC уже удален, недоступен образ или не хватает ресурсов для служебного пода), ресурс все равно удаляется, не оставаясь в состоянии Terminating. В журнал оператора компонента записывается предупреждение с указанием пути к каталогу, названия тома PVC и пространства имен. Такой каталог необходимо удалить вручную. Для этого смонтируйте том PVC в любой под и удалите каталог командой rm -rf.

Ротация выполняется тем же заданием cron, которое создает копии (см. типовую настройку); задание удаляет старые ресурсы, оставляя заданное число последних копий:

KEEP=7
GOOD=$(kubectl -n astra-automation get aabackup --sort-by=.metadata.creationTimestamp \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.conditions[?(@.type=="Successful")].status}{"\n"}{end}' \
  | awk -F"\t" '$2=="True" {print $1}')
COUNT=$(printf '%s\n' "$GOOD" | grep -c . || true)
if [ "$COUNT" -gt "$KEEP" ]; then
  printf '%s\n' "$GOOD" | head -n $((COUNT - KEEP)) \
    | xargs -r kubectl -n astra-automation delete aabackup
fi

Здесь:

  • KEEP – число хранимых успешных копий.

Процесс ротации удаляет только копии в состоянии Successful=True; он не удаляет ресурсы, завершившиеся ошибкой. Удаляйте их вручную после выяснения причины. Команды используют только возможности оболочки POSIX и работают в том числе в минимальных образах на основе busybox.

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

  1. Смонтируйте том PVC во временный под (см. Диагностика).

  2. Скопируйте каталог командой kubectl cp.

  3. Перенесите копию во внешнее хранилище.

Резервная копия содержит все секреты экземпляра платформы в открытом виде (см. Состав резервной копии). При переносе за пределы кластера шифруйте архив. Ограничивайте доступ к внешнему хранилищу так же, как доступ к секретам платформы (см. Обновления и резервное копирование). При использовании файлового хранилища Private Automation Hub контент входит в каталог копии и попадает во внешний архив вместе с дампами. При использовании хранилища S3 необходимо скопировать bucket отдельно (см. Проверки перед восстановлением).

Если в томе PVC Private Automation Hub не хватает места, резервное копирование контента завершается ошибкой not enough space on /backups (журнал задания Kubernetes (Job) <hub-name>-backup-content). Неполное копирование завершается ошибкой сверки количества файлов. В обоих случаях дочерний и корневой ресурсы переходят в Failure=True.

Здесь:

  • <hub-name> – название ресурса Private Automation Hub.

Требования к размеру тома приведены в проверках емкости хранилища.

Диагностика#

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

Состояние ресурсов резервного копирования и восстановления:

kubectl -n astra-automation get aabackup,acbackup,edabackup,pahbackup,dashboardbackup
kubectl -n astra-automation get aarestore,acrestore,edarestore,pahrestore,dashboardrestore

Подробный статус одного ресурса:

kubectl -n astra-automation describe aabackup backup-20260716-1430

Если ресурс находится в состоянии Failure=True, проверьте журналы операторов:

kubectl -n astra-automation logs deploy/aa-operator-aa-manager -c manager
kubectl -n astra-automation logs deploy/ac-operator-ac-manager -c ac-manager
kubectl -n astra-automation logs deploy/eda-operator-eda-manager -c eda-manager
kubectl -n astra-automation logs deploy/pah-operator-pah-manager -c pah-operator
kubectl -n astra-automation logs deploy/dashboard-operator-dashboard-manager -c dashboard-manager

Служебный под, выполняющий pg_dump и pg_restore, существует около минуты во время операции:

kubectl -n astra-automation get pods | grep db-management

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

kubectl -n astra-automation run inspect --image=busybox --rm -ti --restart=Never \
  --overrides='{"spec":{"containers":[{"name":"inspect","image":"busybox",
                "command":["sh"],"stdin":true,"tty":true,
                "volumeMounts":[{"name":"b","mountPath":"/backups"}]}],
                "volumes":[{"name":"b","persistentVolumeClaim":
                {"claimName":"aa-demo-backup-claim"}}]}}'