Резервное копирование и восстановление¶

Важно

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

Резервное копирование¶

В KeyStack реализовано резервное копирование данных LCM-узла и баз данных MariaDB для регионов OpenStack.

Резервное копирование LCM-узла¶

Для резервного копирования компонентов LCM-узла используется Velero — инструмент резервного копирования для Kubernetes. Резервные копии вместе с содержимым томов хранятся во внешнем S3-хранилище, которое предоставляет заказчик. Velero создаёт снимок тома, переносит его содержимое в S3 и удаляет снимок из кластера, поэтому резервная копия не зависит от состояния LCM-узла и сохраняется даже при его полной потере.

Предварительные требования:

S3-совместимое хранилище с выделенным bucket: адрес API, регион, Access Key ID и Secret Access Key;
сертификат центра сертификации, которым подписан сертификат S3-хранилища, если хранилище использует корпоративный или самоподписанный сертификат;
сетевой доступ со всех LCM-узлов к адресу S3-хранилища;
свободный объём в bucket не меньше фактического объёма данных копируемых компонентов. Данные передаются со сжатием и дедупликацией.

Резервное копирование выполняется для пространств имён компонентов LCM:

lcm-gitlab — GitLab. Копируйте вместе с lcm-garage: файлы GitLab (артефакты, LFS, загрузки, пакеты) хранятся в Garage;
lcm-garage — S3-хранилище Garage;
lcm-netbox — NetBox;
lcm-vault — Vault;
lcm-nexus — Nexus.

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

Для переноса содержимого томов в S3 агент Velero (node-agent) работает с правами root, чтобы читать файлы любых владельцев. Поды Velero и node-agent исключаются из политик безопасности Kyverno меткой policy.lcm/skip-policies=true.

Для первоначальной настройки Velero выполните следующие действия на первом LCM-узле:

Создайте файл credentials-velero с учётными данными доступа к S3-хранилищу:
```
[default]
aws_access_key_id = <access-key>
aws_secret_access_key = <secret-key>
```
Если S3-хранилище использует корпоративный или самоподписанный сертификат, сохраните сертификат центра сертификации в файл s3-ca.crt в формате PEM.
Создайте пространство имён Velero и конфигурацию агента, которая добавляет метку исключения из политик Kyverno подам переноса данных:
```
$ kubectl create namespace velero
$ kubectl -n velero create configmap node-agent-config \
    --from-literal=node-agent-config.json='{"podLabels":{"policy.lcm/skip-policies":"true"}}'
```
Установите Velero в Kubernetes-кластер:
```
$ velero install \
    --features=EnableCSI \
    --provider aws \
    --plugins docker.io/velero/velero-plugin-for-aws:v1.14.0 \
    --bucket <имя bucket> \
    --secret-file ./credentials-velero \
    --cacert ./s3-ca.crt \
    --use-node-agent \
    --node-agent-disable-host-path \
    --pod-labels policy.lcm/skip-policies=true \
    --node-agent-configmap node-agent-config \
    --backup-location-config region=<регион S3>,s3ForcePathStyle="true",s3Url=<адрес API S3>
```
Где:
- --plugins — образ плагина для S3. Образы Velero и плагина входят в дистрибутив и уже загружены на LCM-узлы;
- --cacert — сертификат центра сертификации S3-хранилища. Без него Velero не подключится к хранилищу с корпоративным или самоподписанным сертификатом. Если сертификат хранилища выпущен общедоступным центром сертификации, параметр не указывайте;
- --use-node-agent — запуск агента, который переносит содержимое томов в S3;
- --node-agent-disable-host-path — отключение монтирования каталога узла в агент: для переноса содержимого томов оно не требуется и запрещено политиками Kyverno;
- --pod-labels — метка исключения из политик Kyverno для подов Velero и агента;
- --node-agent-configmap — конфигурация агента, созданная на предыдущем шаге.
Используйте утилиту velero из дистрибутива: версия сервера Velero определяется версией утилиты.

Проверьте, что под Velero и поды агента запущены. Под агента node-agent должен быть запущен на каждом LCM-узле:

$ kubectl get pod -n velero

NAME                      READY   STATUS    RESTARTS   AGE
node-agent-dlz2l          1/1     Running   0          1m
node-agent-ljsjr          1/1     Running   0          1m
node-agent-mmpx5          1/1     Running   0          1m
velero-6b9998c64f-6w4b4   1/1     Running   0          1m

Проверьте, что Velero подключился к S3-хранилищу. В столбце PHASE должно быть значение Available:
```
$ velero backup-location get

NAME      PROVIDER   BUCKET/PREFIX   PHASE       LAST VALIDATED                  ACCESS MODE   DEFAULT
default   aws        velero          Available   2026-10-19 11:05:08 +0000 UTC   ReadWrite     true
```
Значение Unavailable с ошибкой x509: certificate signed by unknown authority в журнале пода Velero означает, что не указан или указан неверный сертификат центра сертификации в параметре --cacert.
Удалите файл с учётными данными — настройки доступа хранятся в Kubernetes Secret:
```
$ rm -f ./credentials-velero
```

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

Запустите резервное копирование, указав пространства имён компонентов через запятую:
```
$ velero backup create <имя-копии> --include-namespaces <пространства имён компонентов LCM> --snapshot-move-data --wait
```
Параметр --snapshot-move-data обязателен: без него содержимое томов останется снимками внутри кластера и не попадёт в S3-хранилище.
Проверьте статус резервной копии. В поле Phase должно быть значение Completed:
```
$ velero backup describe <имя-копии>
```

Проверьте, что содержимое всех томов перенесено в S3-хранилище. Для каждого тома в столбце PHASE должно быть значение Completed:

$ kubectl -n velero get datauploads \
    -o custom-columns=PVC:.spec.sourcePVC,PHASE:.status.phase,BYTES:.status.progress.totalBytes

PVC                      PHASE       BYTES
cnpg-cluster-1           Completed   470212629
cnpg-cluster-2           Completed   436517331
netbox-media             Completed   <none>

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

Создайте расписание, указав cron-выражение, пространства имён компонентов и, при необходимости, срок хранения копий:
```
$ velero schedule create <имя-расписания> \
    --schedule="<cron-выражение>" \
    --include-namespaces <пространства имён компонентов LCM> \
    --snapshot-move-data \
    --ttl <срок хранения в формате XhYmZs (часы, минуты, секунды)>
```
Например, для ежедневного запуска резервного копирования GitLab в 04:00 с хранением 30 дней команда создания расписания будет выглядеть следующим образом:
```
$ velero schedule create lcm-daily \
    --schedule="0 4 * * *" \
    --include-namespaces lcm-gitlab,lcm-garage \
    --snapshot-move-data \
    --ttl 720h0m0s
```
По истечении срока хранения Velero удаляет резервную копию вместе с её данными в S3-хранилище.
Проверьте список созданных расписаний, чтобы убедиться, что расписание было создано корректно:
```
$ velero schedule get
```

Резервное копирование базы данных OpenStack¶

Данные региона OpenStack хранятся в базе данных MariaDB. При резервном копировании MariaDB выполняется только полное копирование базы данных — инкрементальные резервные копии не поддерживаются. Резервные копии баз данных регионов шифруются алгоритмом AES-256 с использованием PBKDF2 для усиления безопасности ключа.

Резервное копирование MariaDB включено по умолчанию. При необходимости его отключения добавьте в конфигурационный файл globals.d/REGION.yml параметр:

enable_mariabackup: "no"

После изменения конфигурации запустите пайплайн развёртывания региона:

Откройте веб-интерфейс развёрнутого GitLab и перейдите в репозиторий региона project_k / deployments / <имя региона>.
Создайте новый пайплайн: Build > Pipelines > New Pipeline.
В списке Run for branch name or tag оставьте ветку по умолчанию, соответствующую установленному релизу.
Запустите задачу deploy в созданном пайплайне.
Дождитесь завершения выполнения задачи.

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

три управляющих узла — резервное копирование выполняется в штатном режиме;

два управляющих узла — резервное копирование продолжается, в лог записывается предупреждение, состояние отражается в метриках мониторинга;

один управляющий узел или менее — пайплайн завершается с ошибкой.

Поддерживается три варианта хранения резервных копий:

Хранение на LCM-узле (встроенное S3-хранилище Garage) — по умолчанию:

Параметры хранилища настраиваются автоматически при установке LCM и сохраняются как переменные группы в GitLab: s3_host, s3_backet, s3_access_key, s3_secret_key, s3_region. Ручная настройка не требуется.

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

После успешной проверки файл копируется в хранилище. При этом выполняется проверка контрольной суммы SHA-256: контрольная сумма файла на управляющем узле сравнивается с контрольной суммой файла в хранилище. Если суммы не совпадают, шаг копирования повторяется ещё раз. Если после повтора несоответствие сохраняется, пайплайн завершается с ошибкой.
Хранение во внешнем S3:
Для этого варианта добавьте следующие переменные в раздел Settings > CI/CD > Variables репозитория региона project_k / deployments / <имя региона>:
s3_host — адрес сервиса S3;

s3_backet — имя bucket для хранения резервных копий;

s3_access_key — Access Key ID;

s3_secret_key — Secret Access Key;

s3_region — регион S3.
Проверка контрольной суммы SHA-256 при хранении во внешнем S3 не выполняется.
Хранение в Nexus:
Для этого варианта добавьте следующие переменные в раздел Settings > CI/CD > Variables репозитория региона project_k / deployments / <имя региона>:
KEYSTACK_NEXUS_BACKUP — адрес сервиса Nexus, например http://nexus:8081/repository/k-backup/;

NEXUS_USER — имя пользователя Nexus.
Пароль пользователя Nexus берётся автоматически из Vault.

По умолчанию на LCM-узле и во внешнем S3 хранятся последние 2 резервных копии, более старые удаляются автоматически. Чтобы изменить количество хранимых копий, добавьте в конфигурационный файл региона globals.d/REGION.yml параметр backup_keep_count и запустите пайплайн развёртывания, чтобы применить новую конфигурацию:

backup_keep_count: <количество>

В Nexus автоматическая ротация не выполняется — настройте её на стороне хранилища.

Статус резервных копий отображается:

на Портале администратора в разделе DB Backups на вкладке Состояние системы — данные за последние 7 дней;

в Grafana на дашборде OpenStack Dashboard — дата и статус последнего резервного копирования (метрики db_backup_job_status и db_backup_job_last_run).

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

Резервное копирование MariaDB рекомендуется выполнять в период минимальной нагрузки на кластер (например, ночью).

При запуске резервного копирования под высокой нагрузкой возможна блокировка таблиц БД: ряд сервисов управляющего слоя (nova-compute, ovs, ovs-agent, cinder-volume, cinder-scheduler) может кратковременно перейти в состояние down и автоматически восстановиться после завершения пайплайна. Ориентируйтесь на графики загрузки MariaDB и выбирайте время с низкими показателями.

Требования к дисковой подсистеме управляющих узлов (Enterprise SSD, RAID1) приведены в разделе Аппаратные и программные требования к инфраструктуре. Их соблюдение обязательно в том числе для корректной работы резервного копирования.

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

Откройте веб-интерфейс развёрнутого GitLab и перейдите в репозиторий региона project_k / deployments / <имя региона>.
Создайте новый пайплайн: Build > Pipelines > New Pipeline.
В списке Run for branch name or tag оставьте ветку по умолчанию, соответствующую установленному релизу.
Запустите пайплайн New pipeline.
Вручную запустите задачу backup-db на этапе deploy.
Дождитесь выполнения пайплайна.

Также вы можете настроить регулярное резервное копирование БД через планировщик заданий в Портале администратора. Для этого при создании задания в планировщике выберите тип «Запуск Gitlab stage job» и вариант mariadb-backup. Подробнее см. в разделе Планировщик заданий.

Восстановление из резервной копии¶

Восстановление LCM-узла из резервной копии¶

Восстановление LCM-узла выполняется средствами Velero: объекты Kubernetes и содержимое томов загружаются из S3-хранилища.

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

Velero не перезаписывает существующие объекты: восстановление поверх работающего пространства имён ничего не изменит. Перед восстановлением удалите пространство имён компонента.

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

Получите список доступных резервных копий:
```
$ velero backup get
```
Удалите пространство имён восстанавливаемого компонента и дождитесь завершения удаления:
```
$ kubectl delete namespace <пространство имён>
```
Запустите восстановление пространства имён из выбранной резервной копии:
```
$ velero restore create --from-backup <имя-копии> --include-namespaces <пространство имён> --wait
```
Восстанавливайте пространство имён целиком, без исключения ресурсов: поды компонентов LCM обращаются к API Kubernetes через egress gateway, и без ресурсов Gateway API, ServiceEntry и маршрутов компоненты не запустятся.
Проверьте статус восстановления. В поле Phase должно быть значение Completed:
```
$ velero restore describe <имя-восстановления>
```
Предупреждения о том, что объекты ConfigMap istio-ca-root-cert и kube-root-ca.crt уже существуют, — норма: эти объекты создаются в пространстве имён автоматически.
Проверьте, что содержимое всех томов загружено из S3-хранилища. Для каждого тома в столбце PHASE должно быть значение Completed:
```
$ kubectl -n velero get datadownloads \
    -o custom-columns=PVC:.spec.targetVolume.pvc,PHASE:.status.phase
```
Дождитесь запуска подов компонента:
```
$ kubectl get pod -n <пространство имён>
```
В первые минуты после восстановления в журналах компонентов возможны ошибки подключения к базе данных и Redis — компоненты запускаются раньше, чем базы данных и реплики Redis становятся доступны. После их запуска ошибки прекращаются.

Velero не восстанавливает завершённые задания (Job): задания, созданные по расписанию (CronJob), будут созданы заново в соответствии с расписанием.

Восстановление базы данных OpenStack из резервной копии¶

За помощью в восстановлении базы данных регионов OpenStack следует обратиться к вендору.

Успешность восстановления можно проверить по дашбордам Grafana OpenStack Dashboard и Galera/MariaDB Dashboard — по статусу кластера базы данных и региона в целом.