Для улучшения работы сайта мы используем файлы 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.

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

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

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

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

Предварительные условия

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

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

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

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

4.1. Настройка с помощью kubectl

  1. Установите оператор Data Protection, если он еще не установлен. Для этого сохраните предоставленный ниже манифест в файл, например DataProtectionOperator.yaml.

    Пример манифеста 
    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: nova-data-protection-operator
  namespace: nova-operators
spec:
  channel: stable
  installPlanApproval: Automatic
  name: nova-data-protection-operator
  source: nova-catalog
  sourceNamespace: nova-operatorhub
  startingCSV: nova-data-protection-operator.v1.0.0

  2. Установите манифест в кластер.

    kubectl apply -f DataProtectionOperator.yaml

  3. После установки выполните проверку.

    kubectl get pods -n nova-operators
    Пример вывода:
    NAME                                             READY   STATUS    RESTARTS      AGE
nova-data-protection-operator-86d8bfb546-h7fhm   1/1     Running   2 (44h ago)   12d

    После успешной установки в столбце READY должно быть указано 1/1, в столбце STATUS должно быть указано Running.

  4. Для установки ClusterNodeBackup сохраните предоставленный ниже манифест в файл, например, ClusterNodeBackup.yaml.

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

    Ограничения при создании и обновлении:

    • Имя ресурса должно быть строго cluster

    • Поле schedule должно соответствовать стандартному синтаксису cron (5 полей)

    • Все значения в includedResources должны быть из допустимого набора

    • При spec.backend: job поле nfs обязательно.

    • При spec.backend: velero в кластере должен существовать ClusterBackup с именем cluster в состоянии Ready.

    		 
    apiVersion: velero.nova-platform.io/v1alpha1
kind: ClusterNodeBackup
metadata:
  name: cluster
spec:
  backend: job (1)
  includedResources: (2)
    - starvault/db
    - starvault/unsealtokens
    - k8s/encryptionconfig
    - nova/pki
  schedule: "0 4 * * *" (3)
  retention: 7 (4)
  nfs: (5)
    server: nfs.example.local (6)
    path: /backup/nova-cluster (7)
    1 spec.backend (тип: string) - тип бэкэнда резервного копирования. Допустимые значения: velero, job.
    2 spec.includedResources (тип: []string) - список типов ресурсов для резервного копирования. Допустимые значения:

    • starvault/db - база данных StarVault

    • starvault/unsealtokens - токены для распечатывания StarVault

    • k8s/encryptionconfig - конфигурация шифрования Kubernetes

    • nova/pki - PKI-сертификаты и ключи Nova
    3 spec.schedule (тип: string) - расписание запуска резервного копирования в формате cron (5 полей). Например, 0 4 * * *. Необязательно к заполнению.
    4 spec.retention (тип: int) - срок хранения резервных копий в днях. По умолчанию: 7. Минимальное значение: 0. Необязательно к заполнению.
    5 spec.nfs (тип: object) - настройки NFS сервера для хранения резервных копий. Обязательно при backend: job.
    6 spec.nfs.server (тип: string) - адрес NFS-сервера (hostname или IP).
    7 spec.nfs.path (тип: string) - путь к каталогу на NFS-сервере.

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

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

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

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

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

  5. Установите манифест в кластер.

    Пример вывода:
    kubectl apply -f ClusterNodeBackup.yaml

  6. Выполните проверку после установки.

    kubectl get clusternodebackup cluster

    Поле status.phase может иметь следующие значения:

    • Pending - ресурс создан, ожидает обработки

    • Reconciling - оператор разворачивает компоненты резервного копирования

    • Error - ошибка при обработке, подробности в status.message

    Убедитесь, что статус ресурса Pending.

  7. Получите информацию об установленном регулярном задании 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.2. Настройка с помощью Nova Console

Установите модуль Nova Data Protection Operator через Nova Console OperatorHUB. Для этого выполните следующие шаги.

  1. Установите оператор Nova Data Protection Operator. В Nova Console в главном меню выберите Operators → OperatorHUB. Выберите Nova Data Protection Operator. Нажмите кнопку Установить.

    Заполните поля формы по примеру, представленному на скриншоте.

    data protection operator

    Подтвердите установку, нажав Установить.

  2. Перейдите в раздел Operators → Установленные операторы. Выберите Nova Data Protection Operator или сразу после установки нажмите Открыть оператор.

  3. Перейдите ко вкладке ClusterNodeBackup и нажмите на кнопку Создать ClusterNodeBackup.

  4. Заполнить настройки можно двумя способами:

    • С помощью формы

      clusternode backup 1

      Заполните основные поля:

      • Имя - имя ресурса должно быть строго cluster.

      • backend - тип бэкэнда резервного копирования. Допустимые значения: velero, job

        При выборе типа бэкенда job поля nfs к заполнению обязательны!

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

        • starvault/db - база данных StarVault

        • starvault/unsealtokens - токены для распечатывания StarVault

        • k8s/encryptionconfig - конфигурация шифрования Kubernetes

        • nova/pki - PKI-сертификаты и ключи Nova

      • Заполните настройки nfs:

        • path - путь к каталогу на NFS-сервере

        • server - адрес NFS-сервера

      • retention - срок хранения резервных копий в днях. По умолчанию: 7. Минимальное значение: 0.

      • schedule - расписание запуска резервного копирования в формате cron (5 полей). Например, 0 4 * * *.

    • С помощью манифеста

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

      Ограничения при создании и обновлении:

      • Имя ресурса должно быть строго cluster

      • Поле schedule должно соответствовать стандартному синтаксису cron (5 полей)

      • Все значения в includedResources должны быть из допустимого набора

      • При spec.backend: job поле nfs обязательно.

      • При spec.backend: velero в кластере должен существовать ClusterBackup с именем cluster в состоянии Ready.

      		 
      apiVersion: velero.nova-platform.io/v1alpha1
kind: ClusterNodeBackup
metadata:
  name: cluster
spec:
  backend: job (1)
  includedResources: (2)
    - starvault/db
    - starvault/unsealtokens
    - k8s/encryptionconfig
    - nova/pki
  schedule: "0 4 * * *" (3)
  retention: 7 (4)
  nfs: (5)
    server: nfs.example.local (6)
    path: /backup/nova-cluster (7)
      1 spec.backend (тип: string) - тип бэкэнда резервного копирования. Допустимые значения: velero, job.
      2 spec.includedResources (тип: []string) - список типов ресурсов для резервного копирования. Допустимые значения:

      • starvault/db - база данных StarVault

      • starvault/unsealtokens - токены для распечатывания StarVault

      • k8s/encryptionconfig - конфигурация шифрования Kubernetes

      • nova/pki - PKI-сертификаты и ключи Nova
      3 spec.schedule (тип: string) - расписание запуска резервного копирования в формате cron (5 полей). Например, 0 4 * * *. Необязательно к заполнению.
      4 spec.retention (тип: int) - срок хранения резервных копий в днях. По умолчанию: 7. Минимальное значение: 0. Необязательно к заполнению.
      5 spec.nfs (тип: object) - настройки NFS сервера для хранения резервных копий. Обязательно при backend: job.
      6 spec.nfs.server (тип: string) - адрес NFS-сервера (hostname или IP).
      7 spec.nfs.path (тип: string) - путь к каталогу на NFS-сервере.

  5. Нажмите Создать. Отслеживайте статус на вкладке ClusterNodeBackup на странице оператора.

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

Вы также можете проверить наличие резервных копий на внешнем хранилище. На примере ниже показана директория внешнего 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.6.2_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.6.2_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.

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

5.1. Предварительные условия

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

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

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

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

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

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

5.2. Настройка с помощью kubectl

  1. Установите оператор Data Protection, если он еще не установлен. Для этого сохраните предоставленный ниже манифест в файл, например DataProtectionOperator.yaml.

    Пример манифеста 
    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: nova-data-protection-operator
  namespace: nova-operators
spec:
  channel: stable
  installPlanApproval: Automatic
  name: nova-data-protection-operator
  source: nova-catalog
  sourceNamespace: nova-operatorhub
  startingCSV: nova-data-protection-operator.v1.0.0

  2. Установите манифест в кластер.

    kubectl apply -f DataProtectionOperator.yaml

  3. После установки выполните проверку.

    kubectl get pods -n nova-operators
    Пример вывода:
    NAME                                             READY   STATUS    RESTARTS      AGE
nova-data-protection-operator-86d8bfb546-h7fhm   1/1     Running   2 (44h ago)   12d

    После успешной установки в столбце READY должно быть указано 1/1, в столбце STATUS должно быть указано Running.

  4. Для установки ClusterNodeBackup сохраните предоставленный ниже манифест в файл, например, ClusterNodeBackup.yaml.

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

    Ограничения при создании и обновлении:

    • Имя ресурса должно быть строго cluster

    • Поле schedule должно соответствовать стандартному синтаксису cron (5 полей)

    • Все значения в includedResources должны быть из допустимого набора

    • При spec.backend: job поле nfs обязательно.

    • При spec.backend: velero в кластере должен существовать ClusterBackup с именем cluster в состоянии Ready.

    		 
    apiVersion: velero.nova-platform.io/v1alpha1
kind: ClusterNodeBackup
metadata:
  name: cluster
spec:
  backend: velero (1)
  includedResources: (2)
    - starvault/db
    - starvault/unsealtokens
    - k8s/encryptionconfig
    - nova/pki
  schedule: "0 3 * * *" (3)
  retention: 30 (4)
    1 spec.backend (тип: string) - тип бэкэнда резервного копирования. Допустимые значения: velero, job.
    2 spec.includedResources (тип: []string) - список типов ресурсов для резервного копирования. Допустимые значения:

    • starvault/db - база данных StarVault

    • starvault/unsealtokens - токены для распечатывания StarVault

    • k8s/encryptionconfig - конфигурация шифрования Kubernetes

    • nova/pki - PKI-сертификаты и ключи Nova
    3 spec.schedule (тип: string) - расписание запуска резервного копирования в формате cron (5 полей). Например, 0 4 * * *. Необязательно к заполнению.
    4 spec.retention (тип: int) - срок хранения резервных копий в днях. По умолчанию: 7. Минимальное значение: 0. Необязательно к заполнению.

  5. Установите манифест в кластер.

    Пример вывода:
    kubectl apply -f ClusterNodeBackup.yaml

  6. Выполните проверку после установки.

    kubectl get clusternodebackup cluster

    Поле status.phase может иметь следующие значения:

    • Pending - ресурс создан, ожидает обработки

    • Reconciling - оператор разворачивает компоненты резервного копирования

    • Error - ошибка при обработке, подробности в status.message

    Убедитесь, что статус ресурса Pending.

  7. Получите информацию об установленном сервисе 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

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

5.3. Настройка с помощью Nova Console

Установите модуль Nova Data Protection Operator через Nova Console OperatorHUB. Для этого выполните следующие шаги.

  1. Установите оператор Nova Data Protection Operator. В Nova Console в главном меню выберите Operators → OperatorHUB. Выберите Nova Data Protection Operator. Нажмите кнопку Установить.

    Заполните поля формы по примеру, представленному на скриншоте.

    data protection operator

    Подтвердите установку, нажав Установить.

  2. Перейдите в раздел Operators → Установленные операторы. Выберите Nova Data Protection Operator или сразу после установки нажмите Открыть оператор.

  3. Перейдите ко вкладке ClusterNodeBackup и нажмите на кнопку Создать ClusterNodeBackup.

  4. Заполнить настройки можно двумя способами:

    • С помощью формы

      clusternode backup 6

      Заполните основные поля:

      • Имя - имя ресурса должно быть строго cluster.

      • backend - тип бэкэнда резервного копирования. Допустимые значения: velero, job

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

        • starvault/db - база данных StarVault

        • starvault/unsealtokens - токены для распечатывания StarVault

        • k8s/encryptionconfig - конфигурация шифрования Kubernetes

        • nova/pki - PKI-сертификаты и ключи Nova

      • retention - срок хранения резервных копий в днях. По умолчанию: 7. Минимальное значение: 0.

      • schedule - расписание запуска резервного копирования в формате cron (5 полей). Например, 0 4 * * *.

    • С помощью манифеста

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

      Ограничения при создании и обновлении:

      • Имя ресурса должно быть строго cluster

      • Поле schedule должно соответствовать стандартному синтаксису cron (5 полей)

      • Все значения в includedResources должны быть из допустимого набора

      • При spec.backend: job поле nfs обязательно.

      • При spec.backend: velero в кластере должен существовать ClusterBackup с именем cluster в состоянии Ready.

      		 
      apiVersion: velero.nova-platform.io/v1alpha1
kind: ClusterNodeBackup
metadata:
  name: cluster
spec:
  backend: velero (1)
  includedResources: (2)
    - starvault/db
    - starvault/unsealtokens
    - k8s/encryptionconfig
    - nova/pki
  schedule: "0 3 * * *" (3)
  retention: 30 (4)
      1 spec.backend (тип: string) - тип бэкэнда резервного копирования. Допустимые значения: velero, job.
      2 spec.includedResources (тип: []string) - список типов ресурсов для резервного копирования. Допустимые значения:

      • starvault/db - база данных StarVault

      • starvault/unsealtokens - токены для распечатывания StarVault

      • k8s/encryptionconfig - конфигурация шифрования Kubernetes

      • nova/pki - PKI-сертификаты и ключи Nova
      3 spec.schedule (тип: string) - расписание запуска резервного копирования в формате cron (5 полей). Например, 0 4 * * *. Необязательно к заполнению.
      4 spec.retention (тип: int) - срок хранения резервных копий в днях. По умолчанию: 7. Минимальное значение: 0. Необязательно к заполнению.

  5. Нажмите Создать. Отслеживайте статус на вкладке ClusterNodeBackup на странице оператора.

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

5.3.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
5.3.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. Нажмите кнопку Создать.

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

5.3.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)) - порядок сбора ресурсов во время резервного копирования. Ключ - имя ресурса (во мн.ч.), значение - список имен объектов, разделенных запятыми. Для кластерных ресурсов используется только имя объекта.
5.3.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. Нажмите на кнопку Создать.

5.3.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

5.3.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
...

5.3.5. Приостановка-возобновление расписания

В версиях 7.4.0 и 6.5.0 имеется возможность приостановить или запустить существующее расписание. Также можно задать пропуск первого резервного копирования при возобновлении расписания.

  1. Для приостановки или запуска расписания перейдите к разделу Backup and restore → Расписание.

    shed 1

  2. Для приостановки текущего расписания зайдите в настройки расписания и переключите свич Режим в нужное положение.

    shed 3

  3. Для пропуска первого резервного копирования после запуска используйте свич Пропуск резервного копирования. После пропуска настройка автоматически сбрасывается в значение по умолчанию (выполнить).

    shed 2