Типовая настройка резервного копирования

Содержание

Типовая настройка резервного копирования#

Типовая настройка состоит из разовой подготовки и регулярного создания копий по расписанию. После подготовки задание cron создает копии без участия администратора. Настройка не зависит от топологии. Команды одинаковы для внутренней PostgreSQL и внешней СУБД, для экземпляров платформы с Automation Dashboard (панель аналитики) и без него. Подробности каждого шага приведены в описании создания копий. Состав копии приведен в описании архитектуры.

Разовая подготовка#

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

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

Убедитесь, что на всех узлах кластера работает служба NTP (chrony) и вывод timedatectl содержит System clock synchronized: yes. Синхронизация времени обязательна для работы реестра Private Automation Hub и восстановления из копии (см. общие проверки).
Если реестр Private Automation Hub использует файловое хранилище, рассчитайте емкость тома PVC (Persistent Volume Claim) для копий: не меньше, чем (объем контента /var/lib/pulp/media/ + размер дампов) × число хранимых копий KEEP × 1,1. Полученное значение задается переменной STORAGE в сценарии следующего шага. Размера по умолчанию (5Gi) недостаточно уже при двух копиях, а расширить существующий том можно только вручную (см. требования к емкости).
Создайте на узле файл /usr/local/bin/aa-backup.sh со сценарием создания копии и ротации:
```
#!/bin/sh
# Создание резервной копии Astra Automation и ротация старых копий
set -e
NS=astra-automation
DEPLOYMENT=aa-demo
KEEP=7
STORAGE=20Gi
NAME="auto-$(date +%Y%m%d-%H%M%S)"
kubectl -n $NS apply -f - <<EOF
apiVersion: aa.astra-automation.ru/v1alpha1
kind: AstraAutomationBackup
metadata: {name: $NAME, namespace: $NS}
spec:
  deployment_name: $DEPLOYMENT
  clean_backup_on_delete: true
  backup_storage_requirements: $STORAGE
EOF
GOOD=$(kubectl -n $NS 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 $NS delete aabackup
fi
```
Здесь:
- NS – пространство имен экземпляра платформы;
- DEPLOYMENT – название ресурса AstraAutomation;
- KEEP – число хранимых копий. Учитывайте емкость томов PVC;
- STORAGE – размер томов PVC для копий, рассчитанный на предыдущем шаге. Поле backup_storage_requirements действует при создании томов, то есть при первом запуске. Существующие тома оператор не изменяет; их можно расширить только вручную (см. требования к емкости).
Процесс ротации удаляет только копии в состоянии Successful=True, включая созданные вручную; успешных копий остается не меньше KEEP. Процесс ротации не удаляет ресурсы, завершившиеся ошибкой. Удаляйте их вручную после выяснения причины (см. диагностику). Флаг clean_backup_on_delete: true обеспечивает удаление каталогов копий вместе с ресурсами (см. описание ротации).
Сделайте сценарий исполняемым:
```
chmod +x /usr/local/bin/aa-backup.sh
```
Добавьте задание в crontab суперпользователя командой sudo crontab -e:
```
KUBECONFIG=/etc/kubernetes/admin.conf
0 3 * * * /usr/local/bin/aa-backup.sh >> /var/log/aa-backup.log 2>&1
```
Здесь:
- KUBECONFIG – путь к файлу kubeconfig с привилегиями на управление ресурсами платформы;
- 0 3 * * * – период запуска в формате cron. Задание выполняется в часовом поясе узла. Выбирайте период по интенсивности изменений и допустимой потере данных. Для типовой нагрузки достаточно одной копии в сутки в часы минимальной активности.
На Astra Linux правка crontab обычного пользователя по умолчанию ограничена, поэтому задание необходимо настраивать в crontab суперпользователя.
Проверьте первый запуск, выполнив сценарий вручную:
```
sudo KUBECONFIG=/etc/kubernetes/admin.conf /usr/local/bin/aa-backup.sh
B=$(kubectl -n astra-automation get aabackup \
  --sort-by=.metadata.creationTimestamp -o name | tail -1)
kubectl -n astra-automation wait "$B" --for=condition=Successful --timeout=30m
```
Условие Successful=True на корневом ресурсе AstraAutomationBackup гарантирует успех резервного копирования всех компонентов. Если ресурс переходит в Failure=True, проверьте журналы операторов (см. диагностику).

Примечание

При использовании хранилища S3 реестра Private Automation Hub объекты хранилища (bucket) в копию не входят и переносятся отдельно (см. требования к хранилищу реестра).

Ручное создание копии#

Расписание не требует участия администратора при каждом запуске. Ручной запуск применяется для внеочередной копии, например перед обновлением платформы.

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

Создайте файл 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 – уникальное название ресурса с меткой времени. Название ранее удаленного ресурса нельзя использовать повторно (см. описание ограничения).
Примените манифест:
```
kubectl apply -f backup.yaml
```

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

kubectl -n astra-automation wait aabackup/backup-20260716-1430 \
  --for=condition=Successful --timeout=30m

Расположение созданной копии указано в полях status.backupClaim и status.backupDirectory ресурса. Процесс ротации удаляет и копии, созданные вручную. Для сохранения внеочередной копии скопируйте ее за пределы кластера до создания KEEP новых копий по расписанию (см. рекомендации по хранению). Копия содержит секреты экземпляра платформы в открытом виде. При переносе за пределы кластера шифруйте архив. Перед восстановлением в производственной среде выполните проверки.