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

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

Регулярное резервное копирование узлов Nova Container Platform необходимо, чтобы восстановить кластер в критических ситуациях. Рекомендуется организовать хранение резервных копий в инфраструктуре за пределами кластера Kubernetes. Резервное копирование не должно выполняться в пиковые часы нагрузки, поскольку процессы подготовки резервных копий оказывают влияние на дисковую подсистему узлов.

1. Объекты резервного копирования

Критически важными компонентами платформы, узлов и среды Kubernetes являются следующие сервисы:

  • Etcd: основное хранилище данных, содержит всю информацию о ресурсах в Kubernetes.

  • StarVault: основное хранилище TLS-сертификатов, секретов, учетных записей.

Кроме этого, в Nova Container Platform поддерживается опциональная возможность резервного копирования следующих объектов:

  • Токены StarVault (Unseal Tokens): токены для распечатывания (расшифровки) хранилища StarVault.

  • TLS-сертификаты: сертификаты компонентов Kubernetes Control Plane и Nova Configuration Manager.

  • Ключи шифрования Etcd: ключи, необходимые для шифрования секретов в Etcd.

2. Совместимость резервных копий

В Nova Container Platform поддерживается полное восстановление резервной копии только для патч-версии платформы (x.y.Z), в которой данная резервная копия создавалась.

Восстановление образов хранилищ Etcd и StarVault в несовместимые версии Nova Container Platform может привести к непредсказуемому поведению служебных сервисов платформы.

3. Выбор решения для резервного копирования

В Nova Container Platform поддерживается два основных решения для резервного копирования узлов:

  • Регулярное задание CronJob в Kubernetes.

  • C помощью дополнительного модуля Nova Data Protection и ПО Velero, входящего в его состав.

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

  • В регулярном задании CronJob сервис Nova Backup Daemon использует том, куда выполняется сохранение резервной копии. Рекомендуется использовать в качестве тома подключаемое NFS-хранилище.

  • При использовании ПО Velero из модуля Nova Data Protection в пользовательской инфраструктуре должно быть подготовлено и доступно S3-совместимое объектное хранилище. В данном сценарии сервис Nova Backup Daemon сохраняет резервную копию узлов локально, а затем выполняется резервная копия сервиса с его данными с помощью Velero.

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

В разделе Резервное копирование и восстановление пользовательских данных вы можете ознакомиться с требованиями для установки модуля Nova Data Protection.

4. Настройка резервного копирования узлов

В данном разделе описана процедура настройки резервного копирования узлов платформы Nova Container Platform:

  • используя возможности запуска регулярных заданий CronJob в Kubernetes;

  • с помощью ПО Velero, входящего в состав модуля Data Protection.

4.1. Настройка резервного копирования с помощью регулярного задания CronJob

Необходимые условия

  • У вас есть доступ к кластеру с учетной записью, имеющей роль cluster-admin в Kubernetes.

  • Вы установили утилиту kubectl для работы с Kubernetes.

  • У вас подготовлено NFS-хранилище для резервных копий.

Порядок действий

  1. Подготовьте манифест кастомизации (Kustomization) в зависимости от количества узлов в кластере Kubernetes. Далее представлен пример кастомизации, для 3-х узлов:

    3 узла 
    apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: nova-release-cluster-backup-rbac
  namespace: nova-gitops
  labels:
    nova-application-group: data-protection
    kustomization.nova-platform.io/cluster: "true"
spec:
  serviceAccountName: kustomize-controller
  commonMetadata:
    labels:
      app.kubernetes.io/managed-by: Nova
  interval: 10m
  retryInterval: 30s
  timeout: 5m
  prune: false
  force: true
  sourceRef:
    kind: GitRepository
    name: nova-release-gitrepo-main
  path: ./resources/cluster-backup-rbac
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: nova-release-cluster-backup-cronjob
  namespace: nova-gitops
  labels:
    nova-application-group: data-protection
    kustomization.nova-platform.io/cluster: "true"
spec:
  dependsOn:
  - name: nova-release-cluster-backup-rbac
  serviceAccountName: kustomize-controller
  commonMetadata:
    labels:
      app.kubernetes.io/managed-by: Nova
  interval: 10m
  retryInterval: 30s
  timeout: 5m
  prune: false
  force: true
  sourceRef:
    kind: GitRepository
    name: nova-release-gitrepo-main
  path: ./resources/cluster-backup-cronjob
  postBuild:
    substituteFrom:
    - kind: ConfigMap
      name: nova-gitops-common-substitute-config
  patches:
  - patch: |
      apiVersion: batch/v1
      kind: CronJob
      metadata:
        name: nova-backup-scheduled
        namespace: nova-cluster-backup
      spec:
        schedule: "0 4 * * *"
        jobTemplate:
          spec:
            parallelism: 3 # сколько подов может запускать нода = количеству нод в кластере (если указать меньше, будет рандомно выбираться нода)
            completions: 3 # сколько подов ждать до завершения работы ноды = указываем также количество нод в кластере
            template:
              spec:
                volumes:
                - name: backup-volume
                  nfs:
                    server: nfs-share.mycompany.local
                    path: /nova-cluster-8b4e9344-9dcd-4c64-b98a-4a8a08a53da6
                    readOnly: false
                containers:
                - name: backup-daemon
                  env:
                  - name: MY_NODE_NAME
                    valueFrom:
                      fieldRef:
                        apiVersion: v1
                        fieldPath: spec.nodeName
                  - name: INCLUDE_STARVAULT_UNSEAL_TOKENS
                    value: "true"
                  - name: INCLUDE_PKI_DATA
                    value: "true"
                  - name: INCLUDE_DATA_ENCRYPTION_CONFIG
                    value: "true"
                  - name: INCLUDE_STARVAULT_DB_BACKUP
                    value: "true"
                  - name: RETENTION_PERIOD_DAYS
                    values: "7"
                  - name: MY_POD_NAME
                    valueFrom:
                      fieldRef:
                        apiVersion: v1
                        fieldPath: metadata.name
                  - name: MY_NAMESPACE
                    valueFrom:
                      fieldRef:
                        apiVersion: v1
                        fieldPath: metadata.namespace
    target:
      kind: CronJob
      name: nova-backup-scheduled
      namespace: nova-cluster-backup

  2. Установите параметры резервного копирования.

    Укажите переменные окружения сервиса Nova Backup Daemon:

    Параметр Значение по умолчанию Описание

    INCLUDE_STARVAULT_UNSEAL_TOKENS

    true

    Добавление в архив резервной копии токенов для распечатывания StarVault.

    INCLUDE_PKI_DATA

    true

    Добавление в архив резервной копии всех выпущенных TLS-сертификатов для платформы.

    INCLUDE_DATA_ENCRYPTION_CONFIG

    true

    Добавление в архив резервной копии ключей шифрования Etcd.

    INCLUDE_STARVAULT_DB_BACKUP

    true

    Добавление в архив резервной копии снимка БД StarVault.

    RETENTION_PERIOD_DAYS

    7

    Количество дней, в течение которых необходимо хранить резервные копии на внешнем хранилище.

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

    • Резервная копия Etcd создается всегда и только однократно на одном из узлов платформы.

    • Для получения полного набора токенов для распечатывания StarVault необходимо иметь резервные копии всех узлов.

    • Резервное копирование TLS-сертификатов не включает приватные ключи центров сертификации платформы, поскольку они не являются эскпортируемыми и хранятся только в БД StarVault.

    • Управление количеством дней хранения резервных копий доступно только для решения резервного копирования с помощью регулярного задания CronJob. При использовании модуля Nova Data Protection политика хранения данных определяется средствами ПО Velero.

    Укажите спецификацию тома backup-volume, предназначенного для хранения резервных копий.

    Например, для NFS-хранилища используйте спецификацию:

    spec:
  volumes:
  - name: backup-volume
    nfs:
      server: nfs-share.mycompany.local
      path: /nova-cluster-8b4e9344-9dcd-4c64-b98a-4a8a08a53da6
      readOnly: false

    где nfs.server - DNS-имя вашего NFS-сервера или его IP-адрес, nfs.path - путь для хранения резервных копий.

    Укажите график резервного копирования в формате Cron, например, для выполнения резервных копий каждый день в 4:00:

    schedule: "0 4 * * *"

  3. Сохраните полученный манифест и установите его в кластер Kubernetes с помощью Nova Console или kubectl.

    Пример вывода:
    kubectl apply -f nova-release-cluster-backup-cronjob.yaml

kustomization.kustomize.toolkit.fluxcd.io/nova-release-cluster-backup-cronjob created

  4. Проверьте статус кастомизации:

    kubectl get ks nova-release-cluster-backup-cronjob -n nova-gitops
    Пример вывода:
    kubectl get ks nova-release-cluster-backup-cronjob -n nova-gitops

NAME                                  AGE   READY   STATUS
nova-release-cluster-backup-cronjob   41s   True    Applied revision: v7.1.0@sha1:6789a4025a1edd244044677ed43d8087018e5a7d

  5. Получите информацию об установленном регулярном задании Cronjob:

    kubectl get cronjobs.batch -n nova-cluster-backup
    Пример вывода:
    kubectl get cronjobs.batch -n nova-cluster-backup

NAME                    SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
nova-backup-scheduled   0 4 * * *   False     1        7s              14m

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

В процессе работы задания наузлах будут запускаться сервисы Nova Backup Daemon, а по завершению работы их статус можно будет отследить в пространстве имен nova-cluster-backup. Статус может быть Completed в успешном случае, и Error в случае ошибки.

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

kubectl get pods -n nova-cluster-backup
Пример вывода:
kubectl get pods -n nova-cluster-backup

NAME                                     READY   STATUS      RESTARTS   AGE
nova-backup-scheduled-28629407-0-v7qbv   0/1     Completed   0          24s
nova-backup-scheduled-28629407-1-t2wbt   0/1     Completed   0          24s
nova-backup-scheduled-28629407-2-h6hq9   0/1     Completed   0          24s

4.1.1. Проверка резервных копий на внешнем хранилище

Вы также можете проверить наличие резервных копий на внешнем хранилище. На примере ниже показана директория внешнего NFS-сервера, куда выполняется резервное копирование узлов кластера Nova Container Platform.

Пример вывода:
ls -la /storage/nova-364f9cbe-b209-4f3a-a4d4-9fe36a81afef/

drwxr-xr-x. 2 nobody nobody     4096 Jun  7 15:47 .
drwxr-xr-x. 3 nobody nobody       55 Jun  7 14:44 ..
-rw-r--r--. 1 root   root   16209258 Jun  7 15:47 etcd_snapshot_nova-v7.1.0_k8s-v1.27.11_2024-06-07_124701.db.tar.gz
-rw-------. 1 root   root     219326 Jun  7 15:47 nova-master-1-nova-internal_kuberesources_2024-06-07_124701.tar.gz
-rw-------. 1 root   root     219247 Jun  7 15:47 nova-master-2-nova-internal_kuberesources_2024-06-07_124701.tar.gz
-rw-------. 1 root   root     219279 Jun  7 15:47 nova-master-3-nova-internal_kuberesources_2024-06-07_124700.tar.gz
-rw-------. 1 root   root     314521 Jun  7 15:47 starvault_snapshot_nova-v7.1.0_2024-06-07_124701.db

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

  • Имя архива резервной копии Etcd имеет формат etcd_snapshot_nova-<Версия Nova>_k8s-<Версия Kubernetes>_<Время создания копии>.db.tar.gz.

  • Имена архивов резервных копий конфигураций узлов имеют формат <Имя узла в Kubernetes>_kuberesources_<Время создания копии>.tar.gz.

  • Имя архива резервной копии StarVault имеет формат starvault_snapshot_nova-<Версия Nova>_<Время создания копии>1.db.

4.2. Настройка резервного копирования с помощью Velero

Необходимые условия

  • У вас есть доступ к кластеру с учетной записью, имеющей роль cluster-admin в Kubernetes.

  • Вы установили утилиту kubectl для работы с Kubernetes.

  • Вы установили модуль Data Protection в Nova Container Platform.

  • Вы настроили утилиту velero для работы с резервными копиями Velero.

  • Вы подготовили внешнее хранилище Velero BackupStorageLocation.

Порядок действий

  1. Для установки сервиса Nova Backup Daemon с помощью модуля Data Protection в Nova Container Platform используйте представленный далее манифест кастомизации.

    Манифест кастомизации 
    apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: nova-release-cluster-backup-rbac
  namespace: nova-gitops
  labels:
    nova-application-group: data-protection
    kustomization.nova-platform.io/cluster: "true"
spec:
  serviceAccountName: kustomize-controller
  commonMetadata:
    labels:
      app.kubernetes.io/managed-by: Nova
  interval: 10m
  retryInterval: 30s
  timeout: 5m
  prune: false
  force: true
  sourceRef:
    kind: GitRepository
    name: nova-release-gitrepo-main
  path: ./resources/cluster-backup-rbac
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: nova-release-cluster-backup-velero
  namespace: nova-gitops
  labels:
    nova-application-group: data-protection
    kustomization.nova-platform.io/cluster: "true"
spec:
  serviceAccountName: kustomize-controller
  commonMetadata:
    labels:
      app.kubernetes.io/managed-by: Nova
  interval: 10m
  retryInterval: 30s
  timeout: 5m
  prune: false
  force: true
  dependsOn:
  - name: nova-release-velero-main
  - name: nova-release-cluster-backup-rbac
  sourceRef:
    kind: GitRepository
    name: nova-release-gitrepo-main
  path: ./resources/cluster-backup-velero
  postBuild:
    substituteFrom:
    - kind: ConfigMap
      name: nova-gitops-common-substitute-config
  healthChecks:
    - apiVersion: apps/v1
      kind: DaemonSet
      name: nova-backup-daemon
      namespace: nova-cluster-backup

  2. Проверьте статус кастомизации:

    kubectl get ks nova-release-cluster-backup-velero -n nova-gitops
    Пример вывода:
    kubectl get ks nova-release-cluster-backup-velero -n nova-gitops

NAME                                 AGE   READY   STATUS
nova-release-cluster-backup-velero   39s   True    Applied revision: v7.1.0@sha1:86f53cb7e4dbacb29fa42f2c1c9814fa6aec7a07

  3. Получите информацию об установленном сервисе Nova Backup Daemon:

    kubectl get ds nova-backup-daemon -n nova-cluster-backup
    Пример вывода:
    kubectl get ds nova-backup-daemon -n nova-cluster-backup

NAME                 DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                            AGE
nova-backup-daemon   3         3         3       3            3           node-role.kubernetes.io/control-plane=   103s

  4. Резервную копию можно создать разово или настроить расписание для автоматического создания резервных копий согласно настройкам. Для создания разовой или регулярной резервной копии необходимо сначала создать Место хранения резервной копии и только потом приступить к созданию резервных копий. Далее описаны оба варианта создания резервных копий.

4.2.1. Разовое создание резервной копии

4.2.1.1. Через консоль

Подготовьте и установите манифест резервного копирования узлов в кластер Kubernetes с помощью Nova Console или kubectl.

Пример и расшифровка полей конфигурационного файла приведен ниже:

YAML-манифест 
apiVersion: velero.io/v1
kind: Backup
metadata:
  name: nova-backup-redis (1)
  namespace: nova-cluster-backup (2)
spec:
  csiSnapshotTimeout: 0s (3)
  itemOperationTimeout: 4h
  includedNamespaces: (4)
  - 'nova-redis'
  includedResources: (5)
  - 'configmap'
  - 'pods'
  labelSelector: (6)
    matchLabels:
      app: redis
  storageLocation: backup-control-plane (7)
  ttl: 24h0m0s (8)
  defaultVolumesToFsBackup: true
  snapshotMoveData: true
  datamover: velero
  uploaderConfig:
      parallelFilesUpload: 10
1 metadata.name (тип данных: string) - имя ресурса Backup. Должно быть уникальным в Namespace. Заполнение обязательно.
2 metadata.namespace (тип данных: string) - пространство имен, в котором расположен ресурс Backup. Заполнение обязательно.
3 spec.csiSnapshotTimeout (тип данных: string (длительность)) - время ожидания готовности CSI Snapshot, прежде чем вернуть ошибку таймаута. Значение по умолчанию - 10 минут. Заполнение необязательно.
4 spec.includedNamespaces (тип данных: []string ) - массив пространств имен для включения в резервную копию. * или если не указан, включает все пространства имен.

Заполнение необязательно.
5 spec.includedResources (тип данных: []string ) - массив ресурсов для включения в резервную копию. * или если не указан, включает все ресурсы. Могут быть сокращениями (например, 'po' для 'pods') или полностью квалифицированными.Заполнение необязательно.
6 spec.labelSelector (тип данных: object (map)) - задает критерии выбора объектов по меткам. Только объекты, полностью соответствующие этим критериям, будут включены в резервное копирование. Заполнение необязательно.
7 spec.storageLocation (тип данных: string) - местоположение для хранения резервных копий. Заполнение обязательно.
8 spec.ttl (тип данных: string) - время до удаления резервной копии.

Если не указано иное, будет использоваться значение по умолчанию, равное 30 дням. Значение по умолчанию можно настроить на сервере velero, установив флаг --default-backup-ttl. Заполнение обязательно.
Пример вывода:
kubectl create -f backup.yaml

backup.velero.io/one-time-backup created
4.2.1.2. Через веб-интерфейс

  1. Перейдите в раздел Резервные копии.

  2. Нажмите кнопку Создать резервную копию.

    Создать резервную копию

  3. Далее необходимо задать параметры конфигурации. В верхней части интерфейса выберите один из следующих способов:

    Через YAML-манифест

    Заполните поля манифеста:

    YAML

    Пример и расшифровка полей конфигурационного файла приведен ниже:

    apiVersion: velero.io/v1
kind: Backup
metadata:
  name: nova-backup-redis (1)
  namespace: nova-cluster-backup (2)
spec:
  csiSnapshotTimeout: 0s (3)
  itemOperationTimeout: 4h
  includedNamespaces: (4)
  - 'nova-redis'
  includedResources: (5)
  - 'configmap'
  - 'pods'
  labelSelector: (6)
    matchLabels:
      app: redis
  storageLocation: backup-control-plane (7)
  ttl: 24h0m0s (8)
  defaultVolumesToFsBackup: true
  snapshotMoveData: true
  datamover: velero
  uploaderConfig:
      parallelFilesUpload: 10
    1 metadata.name (тип данных: string) - имя ресурса Backup. Должно быть уникальным в Namespace. Заполнение обязательно.
    2 metadata.namespace (тип данных: string) - пространство имен, в котором расположен ресурс Backup. Заполнение обязательно.
    3 spec.csiSnapshotTimeout (тип данных: string (длительность)) - время ожидания готовности CSI Snapshot, прежде чем вернуть ошибку таймаута. Значение по умолчанию - 10 минут. Заполнение необязательно.
    4 spec.includedNamespaces (тип данных: []string ) - массив пространств имен для включения в резервную копию. * или если не указан, включает все пространства имен.

    Заполнение необязательно.
    5 spec.includedResources (тип данных: []string ) - массив ресурсов для включения в резервную копию. * или если не указан, включает все ресурсы. Могут быть сокращениями (например, 'po' для 'pods') или полностью квалифицированными. Заполнение необязательно.
    6 spec.labelSelector (тип данных: object (map)) - задает критерии выбора объектов по меткам. Только объекты, полностью соответствующие этим критериям, будут включены в резервное копирование. Заполнение необязательно.
    7 spec.storageLocation (тип данных: string) - местоположение для хранения резервных копий. Заполнение обязательно.
    8 spec.ttl (тип данных: string) - время до удаления резервной копии.

    Если не указано иное, будет использоваться значение по умолчанию, равное 30 дням. Значение по умолчанию можно настроить на сервере velero, установив флаг --default-backup-ttl. Заполнение обязательно.

    Раздел status заполняется системой и не должен быть указан при создании объекта Schedule.
    Через заполнение формы

    Некоторые поля спецификации могут не отображаться в этом представлении формы. Пожалуйста, выберите представление YAML для детальной настройки.
    Форма

    • Заполните поле Имя. Параметр отвечает за имя ресурса Backup. Должно быть уникальным в Namespace (пример: my-backup).

    • Заполните поле Namespace. Параметр отвечает за пространство имен, в котором расположен ресурс Backup (пример: my-namespace).

    • Необязательно. Заполните поле Включить ресурсы - массив ресурсов для включения в резервную копию (пример: pods).

    • Необязательно. Заполните поле Включить пространства имен - массив пространств имен для включения в резервную копию (пример: default).

    • Заполните поле TTL - время до удаления резервной копии (пример: 24h0m0s).

    • Необязательно. Заполните поле Селектор меток (OR) - список альтернативных наборов селекторов меток. Любой объект, соответствующий хотя бы одному из этих селекторов, будет включен в резервное копирование. Не может быть использован одновременно с labelSelector (пример: app=velero).

    • Необязательно. Заполните поле Селектор меток (AND) - задает критерии выбора объектов по меткам. Только объекты, полностью соответствующие этим критериям, будут включены в резервное копирование (пример: component=server).

    • Заполните поле Место резервного копирования - местоположение для хранения резервных копий (пример: s3://my-velero-backup-bucket).

    • Необязательно. Заполните поле Настройки-Резервное копирование томов в файловую систему по умолчанию - определяет, следует ли использовать резервное копирование файловой системы тома (Pod Volume) по умолчанию для всех томов (пример: check).

  4. Нажмите кнопку Создать.

4.2.2. Создание резервных копий по расписанию

4.2.2.1. Через консоль

Подготовьте и установите манифест плана резервного копирования узлов в кластер Kubernetes с помощью Nova Console или kubectl:

YAML-манифест 
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: control-plane-backup
  namespace: nova-cluster-backup
spec:
  paused: false
  schedule: 0 4 * * *
  template:
    csiSnapshotTimeout: 0s
    includedNamespaces:
    - nova-cluster-backup
    includedResources:
    - 'daemonsets'
    - 'pods'
    labelSelector:
      matchLabels:
        app.kubernetes.io/component: nova-backup-daemon
    metadata: {}
    ttl: 24h0m0s

Укажите график резервного копирования в формате Cron, например, для выполнения резервных копий каждый день в 4:00:

Поле для задания времени:
schedule: "0 4 * * *"
Пример вывода:
kubectl create -f backup-schedule.yaml

schedule.velero.io/control-plane-backup created

Если требуется выполнить резервное копирование данных внутри пода или PVC, необходимо добавить в ресурс Schedule параметры defaultVolumesToFsBackup и orderedResources.

Пример YAML-манифеста с параметрами для резервного копирования данных внутри пода и характеристика его полей показаны ниже:

YAML-манифест 
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: control-plane-backup
  namespace: nova-cluster-backup
spec:
  paused: false
  schedule: 57 15 * * *
  skipImmediately: false
  template:
    csiSnapshotTimeout: 0s
    defaultVolumesToFsBackup: true (1)
    includedNamespaces:
      - test
    includedResources:
      - pods
      - pv
      - pvc
    metadata: {}
    orderedResources: (2)
      persistentvolumes: pvc-d5e22e80-f2f9-4ac7-9dce-092d402dd2f0
      pods: test/busybox-pod
    ttl: 24h0m0s
1 defaultVolumesToFsBackup(тип: boolean) - параметр, определяющий, следует ли использовать резервное копирование файловой системы тома (Pod Volume) по умолчанию для всех томов.
2 orderedResources(тип: object (map)) - порядок сбора ресурсов во время резервного копирования. Ключ - имя ресурса (во мн.ч.), значение - список имен объектов, разделенных запятыми. Для кластерных ресурсов используется только имя объекта.
4.2.2.2. Через веб-интерфейс

  1. Перейдите в раздел Расписания.

  2. Нажмите кнопку Создать расписание.

    Создать расписание

  3. Далее необходимо задать параметры конфигурации. В верхней части интерфейса выберите один из следующих способов:

    Через YAML-манифест

    Необходимо заполнить поля манифеста:

    YAML

    Пример заполнения YAML-манифеста представлен ниже:

    apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: nova-redis-schedule
  namespace: nova-cluster-backup
spec:
  paused: false
  schedule: 0 4 * * *
  template:
    csiSnapshotTimeout: 0s
    itemOperationTimeout: 4h
    includedNamespaces:
    - nova-redis
    includedResources:
    - 'configmap'
    - 'pods'
    labelSelector:
      matchLabels:
        app: redis
        storageLocation: backup-control-plane
      volumeSnapshotLocations:
        - backup-control-plane
      ttl: 24h0m0s
      defaultVolumesToFsBackup: true
      snapshotMoveData: true
      datamover: velero
      uploaderConfig:
        parallelFilesUpload: 10

    Укажите график резервного копирования в формате Cron, например, для выполнения резервных копий каждый день в 4:00:

    schedule: "0 4 * * *"
    Через заполнение формы

    Некоторые поля спецификации могут не отображаться в этом представлении формы. Пожалуйста, выберите представление YAML для детальной настройки.
    Форма

    • Заполните поле Имя. Параметр отвечает за имя Schedule. Должно быть допустимым именем Kubernetes объекта (пример: my-backup).

    • Заполните поле Namespace. Параметр отвечает за пространство имен, в котором находится Schedule (пример: my-backup).

    • Заполните поле Расписание - cron-выражение, определяющее время запуска резервного копирования (пример: "0 7 * * *").

    • Заполните поле TTL - время до удаления резервной копии (пример: 24h0m0s).

    • Заполните поле Место резервного копирования - местоположение для хранения резервных копий (пример: s3://my-velero-backup-bucket).

    • Необязательно. Заполните поле Настройки-Резервное копирование томов в файловую систему по умолчанию - определяет, следует ли использовать резервное копирование файловой системы тома (pod volume) по умолчанию для всех томов (пример: check).

  4. Нажмите на кнопку Создать.

4.2.3. Проверка после создания резервных копий

  1. Проверьте статус плана резервного копирования одним из способов:

    Через kubectl 
    kubectl get schedules.velero.io -n nova-cluster-backup

    Пример

    kubectl get schedules.velero.io -n nova-cluster-backup

NAME                   STATUS    SCHEDULE     LASTBACKUP   AGE   PAUSED
control-plane-backup   Enabled   15 * * * *                48s   false
    Через Velero CLI 
    velero schedule get

    Пример

    velero schedule get

NAME                   STATUS    CREATED                         SCHEDULE     BACKUP TTL   LAST BACKUP   SELECTOR                                         PAUSED
control-plane-backup   Enabled   2024-06-10 11:59:00 +0000 UTC   15 * * * *   24h0m0s      n/a           app.kubernetes.io/component=nova-backup-daemon   false
    Через веб-интерфейс

    Перейдите в раздел Резервные копии.

    Форма

    Статус плана резервного копирования можно посмотреть в таблице мест в столбце Статус. Значение Запущен указывает на то, что план активирован.

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

    kubectl 
    kubectl get schedules.velero.io -n nova-cluster-backup

    Пример

    kubectl get schedules.velero.io -n nova-cluster-backup

NAME                   STATUS    SCHEDULE     LASTBACKUP   AGE     PAUSED
control-plane-backup   Enabled   15 * * * *   41m          3h57m   false
    Velero CLI 
    velero schedule get

    Пример

    velero schedule get

NAME                   STATUS    CREATED                         SCHEDULE     BACKUP TTL   LAST BACKUP   SELECTOR                                         PAUSED
control-plane-backup   Enabled   2024-06-10 11:59:00 +0000 UTC   15 * * * *   24h0m0s      41m ago       app.kubernetes.io/component=nova-backup-daemon   false

  3. Проверьте статус отдельных заданий резервного копирования:

    kubectl 
    kubectl get backups.velero.io -n nova-cluster-backup

    Пример

    kubectl get backups.velero.io -n nova-cluster-backup

NAME                                  AGE
control-plane-backup-20240610121525   3h45m
control-plane-backup-20240610131525   165m
control-plane-backup-20240610141525   105m
control-plane-backup-20240610151525   45m
    Velero CLI 
    velero backup get

    Пример

    velero backup get

NAME                                  STATUS      ERRORS   WARNINGS   CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
control-plane-backup-20240610151525   Completed   0        0          2024-06-10 15:15:25 +0000 UTC   23h       default            app.kubernetes.io/component=nova-backup-daemon
control-plane-backup-20240610141525   Completed   0        0          2024-06-10 14:15:25 +0000 UTC   22h       default            app.kubernetes.io/component=nova-backup-daemon
control-plane-backup-20240610131525   Completed   0        0          2024-06-10 13:15:25 +0000 UTC   21h       default            app.kubernetes.io/component=nova-backup-daemon
control-plane-backup-20240610121525   Completed   0        0          2024-06-10 12:15:25 +0000 UTC   20h       default            app.kubernetes.io/component=nova-backup-daemon

4.2.4. Проверка резервных копий на внешнем хранилище

Вы также можете проверить наличие резервных копий в объектном хранилище. На примере ниже показан пример резервных копий в объектном хранилище, куда выполняется резервное копирование узлов кластера Nova Container Platform.

Вы можете использовать любой совместимый с вашим объектным хранилищем консольный клиент или веб-интерфейс.
Пример вывода:
aws s3 ls s3://velero-backup-bucket --endpoint-url https://s3.mycompany.local

                           PRE backups/
                           PRE kopia/

В директории backups/ находятся резервные копии спецификаций ресурсов (манифестов) Kubernetes.

Пример вывода:
aws s3 ls s3://velero-backup-bucket/backups/ --endpoint-url https://s3.mycompany.local

                           PRE control-plane-backup-20240610121525/
                           PRE control-plane-backup-20240610131525/
                           PRE control-plane-backup-20240610141525/
                           PRE control-plane-backup-20240610151525/

В директории kopia/ находятся резервные копии файлов сервиса Nova Backup Daemon: резервные копии Etcd, StarVault, PKI и др.

Пример вывода:
aws s3 ls s3://velero-backup-bucket/kopia/nova-cluster-backup/ --endpoint-url https://s3.mycompany.local

2024-06-10 15:15:43        747 _log_20240610121542_f5ce_1718021742_1718021743_1_6bd1da03b924c1be6ec634227e336f19
2024-06-10 15:15:45       1685 _log_20240610121544_c120_1718021744_1718021745_1_dfc7e059b0394a85ca25fe7ecce7ab29
2024-06-10 15:16:04       1755 _log_20240610121603_6ea6_1718021763_1718021764_1_64d9d4b3f4b3d8c4eb7dc310be213d1a
2024-06-10 15:16:28       2640 _log_20240610121626_aa10_1718021786_1718021788_1_0eeb3acc062071d4a84bd08f8ab82621
2024-06-10 16:15:32       1919 _log_20240610131531_287a_1718025331_1718025332_1_60750784af3ee83ed569fbe2e82d40ee
2024-06-10 16:15:39       1941 _log_20240610131537_04d8_1718025337_1718025339_1_564e1ea03aade8ccfb2236efc04f1fb7
2024-06-10 16:15:50       2737 _log_20240610131548_7f66_1718025348_1718025350_1_5595519176d088bf2512ae9d22513816
2024-06-10 16:16:26       3775 _log_20240610131625_6f8c_1718025385_1718025386_1_c60f0d81f4b09128277702e43ddf3655
2024-06-10 17:15:32       2097 _log_20240610141530_363a_1718028930_1718028932_1_dd21e1a8aa835344b058b311aa58ad78
2024-06-10 17:15:39       3334 _log_20240610141537_b56d_1718028937_1718028939_1_efd4f6b0da8be6a04d392e7aa4e8e20b
2024-06-10 17:15:51       2875 _log_20240610141549_8d12_1718028949_1718028951_1_75f3ceb8dce9a244c56bd08631a34761
2024-06-10 17:16:26       1320 _log_20240610141625_ca81_1718028985_1718028986_1_c4975114b6b94de09792c2bbe8694061
2024-06-10 18:15:32       2261 _log_20240610151531_7b9a_1718032531_1718032532_1_7325bf67c58d582df1363ddaff938cfa
2024-06-10 18:15:39       2392 _log_20240610151537_074c_1718032537_1718032539_1_4c8b33484e2ee5c7cc21d411b7eeefbd
2024-06-10 18:15:50       3330 _log_20240610151548_2718_1718032548_1718032550_1_5b2cb4f36c3124cc78acf28574555b65
2024-06-10 18:16:26       1825 _log_20240610151625_aff3_1718032585_1718032586_1_9be5f2ab4206fd4b43b49fdc8dfde303
2024-06-10 15:15:42         30 kopia.blobcfg
2024-06-10 18:16:26        620 kopia.maintenance
2024-06-10 15:15:42       1075 kopia.repository
2024-06-10 18:15:31   26726736 p0941d6b0f97eccef7587b5cbff2207f6-s77d051db729eba1e129
...