Alauda Build of Harbor Docs
  • Русский

    • Резервное копирование и восстановление HARBOR с использованием Velero

    В этом руководстве показано, как использовать Velero — инструмент с открытым исходным кодом для аварийного восстановления в облачных нативных средах, для выполнения операций резервного копирования и восстановления HARBOR.

    Содержание

    Область примененияТерминологияПредварительные требованияРезервное копированиеПодготовкаСоздание бакетаНастройка репозитория резервных копий VeleroВыполнение резервного копированияПеревод экземпляра Harbor в режим только для чтенияСоздание Pod для резервного копированияСоздание политики резервного копирования томовВыполнение резервного копированияПосле успешного резервного копирования отключите режим только для чтения в HarborВосстановлениеПодготовкаВыбор резервной копии для восстановленияОпределение целевого пространства имёнУдаление оператора HARBOR CEОперации восстановленияСоздание конфигурационного файла восстановленияСоздание задачи восстановленияОчистка ресурсовИзменение ресурса HARBOR CRРазвёртывание оператора HARBOR CEВопросы и ответыКак определить, поддерживает ли PVC snapshot?

    Область применения

    Данное решение применимо к экземплярам HARBOR версии 2.12 и выше.

    Данные Harbor состоят из трёх основных компонентов: хранилища, базы данных PostgreSQL. Это решение обеспечивает резервное копирование только для хранилища. Резервное копирование базы данных PostgreSQL необходимо выполнять отдельно в соответствии со стратегией резервного копирования вашего поставщика базы данных.

    DANGER

    Данное решение не поддерживает экземпляры HARBOR, развернутые с использованием хранилища HostPath.

    Терминология

    ТерминОписание
    Исходный экземплярЭкземпляр HARBOR до резервного копирования
    Целевой экземплярЭкземпляр HARBOR после восстановления
    Исходное пространство имёнПространство имён, в котором находится исходный экземпляр
    Целевое пространство имёнПространство имён, в котором находится целевой экземпляр
    Ресурс HARBOR CRПользовательский ресурс, описывающий конфигурацию развертывания HARBOR, используемый Operator для развертывания экземпляров HARBOR

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

    1. Разверните объектное хранилище MinIO: данное решение резервного копирования и восстановления использует объектное хранилище для сохранения данных резервных копий, поэтому необходимо заранее развернуть экземпляр MinIO. ACP предоставляет Быстрое создание экземпляра MinIO.
    2. Разверните Velero: Velero — инструмент для резервного копирования и восстановления. ACP предоставляет Alauda Container Platform Data Backup for Velero, который можно развернуть в представлении Administrator в разделе Marketplace -> Cluster Plugins, выполнив поиск по Velero.
    3. Установите командную строку mc: mc — это инструмент командной строки для управления MinIO. Инструкции по установке см. в официальной документации MinIO.
    4. Установите командную строку kubectl: kubectl — инструмент командной строки для управления Kubernetes. Инструкции по установке см. в официальной документации Kubernetes.

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

    export MINIO_HOST=<адрес доступа к экземпляру MinIO> # Пример: http://192.168.1.100:32008
export MINIO_ACCESS_KEY=<ключ доступа к экземпляру MinIO> # Пример: minioadmin
export MINIO_SECRET_KEY=<секретный ключ экземпляра MinIO> # Пример: minioadminpassword
export MINIO_ALIAS_NAME=<псевдоним экземпляра MinIO> # Пример: myminio

export VELERO_BACKUP_BUCKET=<название бакета для резервных копий Velero> # Пример: backup
export VELERO_BACKUP_REPO_NAME=<название репозитория резервных копий Velero> # Пример: harbor-backup-repo

export HARBOR_NAMESPACE=<пространство имён экземпляра HARBOR для резервного копирования>
export HARBOR_NAME=<имя экземпляра HARBOR для резервного копирования>

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

    mc alias set ${MINIO_ALIAS_NAME} ${MINIO_HOST} ${MINIO_ACCESS_KEY} ${MINIO_SECRET_KEY}
mc ping ${MINIO_ALIAS_NAME}

# Пример вывода:
#   1: http://192.168.131.56:32571:32571   min=98.86ms    max=98.86ms    average=98.86ms    errors=0   roundtrip=98.86ms
#   2: http://192.168.131.56:32571:32571   min=29.57ms    max=98.86ms    average=64.21ms    errors=0   roundtrip=29.57ms
#   3: http://192.168.131.56:32571:32571   min=29.57ms    max=98.86ms    average=52.77ms    errors=0   roundtrip=29.88ms

    Если ping до экземпляра MinIO прошёл успешно, значит mc настроен корректно.

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

    Подготовка

    Подготовка к резервному копированию состоит из двух шагов:

    1. Создание бакета
    2. Настройка репозитория резервных копий Velero

    Создание бакета

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

    mc mb ${MINIO_ALIAS_NAME}/${VELERO_BACKUP_BUCKET}

# Вывод:
# Bucket created successfully `myminio/backup`.

    Настройка репозитория резервных копий Velero

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

    harbor_backup_repo_credentials_secret_name="harbor-backup-repo-credentials"
minio_harbor_backup_bucket="${VELERO_BACKUP_BUCKET:-backup}"
minio_harbor_backup_bucket_directory="harbor"

kubectl apply -f - <<EOF
apiVersion: v1
stringData:
  cloud: |
    [default]
    aws_access_key_id = ${MINIO_ACCESS_KEY}
    aws_secret_access_key = ${MINIO_SECRET_KEY}
kind: Secret
metadata:
  labels:
    component: velero
    cpaas.io/backup-storage-location-repo: ${VELERO_BACKUP_REPO_NAME}
  name: ${harbor_backup_repo_credentials_secret_name}
  namespace: cpaas-system
type: Opaque
---
apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
  name: ${VELERO_BACKUP_REPO_NAME}
  namespace: cpaas-system
spec:
  config:
    checksumAlgorithm: ""
    insecureSkipTLSVerify: "true"
    region: minio
    s3ForcePathStyle: "true"
    s3Url: ${MINIO_HOST}
  credential:
    key: cloud
    name: ${harbor_backup_repo_credentials_secret_name}
  objectStorage:
    bucket: ${minio_harbor_backup_bucket}
    prefix: ${minio_harbor_backup_bucket_directory}
  provider: aws
EOF

# Вывод
# secret/harbor-backup-repo-credentials created
# backupstoragelocationrepo.ait.velero.io/harbor-backup-repo created

    Выполнение резервного копирования

    Ручное резервное копирование состоит из четырёх шагов:

    1. Перевести экземпляр Harbor в режим только для чтения
    2. Создать Pod для резервного копирования
    3. Выполнить резервное копирование
    4. После успешного резервного копирования отключить режим только для чтения

    Перевод экземпляра Harbor в режим только для чтения

    Войдите в Harbor, перейдите в Administration -> Configuration -> System Settings -> Repository Read Only и установите режим только для чтения.

    После изменения в верхней части интерфейса Harbor появится сообщение: «Harbor is set to read-only mode, Deleting repository, artifact, tag and pushing image will be deactivated under read-only mode.»

    Создание Pod для резервного копирования

    На этом шаге создаётся Pod, который монтирует PVC HARBOR, что позволяет Velero выполнить резервное копирование данных PVC.

    image=''

if [ -z "${IMAGE}" ]; then
  image=$(kubectl get deployment -n ${HARBOR_NAMESPACE} -l release=${HARBOR_NAME} -o jsonpath='{range .items[0].spec.template.spec.containers[]}{.image}{"\n"}{end}' | head -n1)
fi

PVC_NAMES=($(kubectl get pvc -n ${HARBOR_NAMESPACE} -l release=${HARBOR_NAME} -o jsonpath='{range .items[*]}{.metadata.name}{" "}{end}'))

VOLUME_MOUNTS=""
VOLUMES=""
INDEX=0
for pvc in ${PVC_NAMES[@]}; do
  VOLUME_MOUNTS="${VOLUME_MOUNTS}
        - name: data-${INDEX}
          mountPath: /mnt/data-${INDEX}"
  VOLUMES="${VOLUMES}
    - name: data-${INDEX}
      persistentVolumeClaim:
        claimName: ${pvc}"
  INDEX=$((INDEX+1))
done

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: ${HARBOR_NAME}-backup-pod
  namespace: ${HARBOR_NAMESPACE}
  labels:
    release: ${HARBOR_NAME}
spec:
  containers:
    - name: backup
      image: ${image}
      command: ["/bin/sh", "-c", "sleep 86400"]
      resources:
        limits:
          cpu: 1
          memory: 1Gi
      volumeMounts:${VOLUME_MOUNTS}
  volumes:${VOLUMES}
  restartPolicy: Never
EOF

kubectl wait --for=condition=ready pod -n ${HARBOR_NAMESPACE} ${HARBOR_NAME}-backup-pod

# Вывод
# pod/xxxx-harbor-backup-pod created
# pod/xxxx-harbor-backup-pod condition met

    Создание политики резервного копирования томов

    Политика томов используется для указания метода резервного копирования PVC. По умолчанию PVC резервируются с помощью метода fs-backup.

    export BACKUP_POLICY_NAME=${BACKUP_POLICY_NAME:-harbor-backup}
export VELERO_BACKUP_REPO_NAME=${VELERO_BACKUP_REPO_NAME:-backup}

kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: ${BACKUP_POLICY_NAME}-volume-policy
  namespace: cpaas-system
data:
  resourcepolicies: |
    version: v1
    volumePolicies:
      - conditions:
          csi: {}
        action:
          type: fs-backup
      - conditions:
          csi: {}
        action:
          type: fs-backup
EOF

# Вывод
# configmap/harbor-backup-volume-policy создан

    Если PVC поддерживает создание снимков (snapshot), можно использовать резервное копирование с помощью snapshot для ускорения процесса. Для этого необходимо изменить ConfigMap политики томов, указав, что класс хранилища использует snapshot для резервного копирования. Например, если класс хранилища ceph поддерживает snapshot, добавьте следующую конфигурацию (добавленное условие следует разместить в начале для более высокого приоритета):

    Как определить, поддерживает ли PVC snapshot?

    WARNING

    Если вы используете резервное копирование PVC с помощью snapshot, при восстановлении нельзя менять класс хранилища. Пожалуйста, корректируйте класс хранилища в соответствии с реальной ситуацией.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: ${BACKUP_POLICY_NAME}-volume-policy
  namespace: cpaas-system
data:
  resourcepolicies: |
    version: v1
    volumePolicies:
+      - conditions:
+          storageClass:
+            - ceph
+        action:
+          type: snapshot
      - conditions:
          csi: {}
        action:
          type: fs-backup
      - conditions:
          csi: {}
        action:
          type: fs-backup
    WARNING

    Если Velero не включён с поддержкой CSI snapshot, при резервном копировании вы получите следующую ошибку:

    Skip action velero.io/csi-pvc-backupper for resource persistentvolumeclaims:xxx, because the CSI feature is not enabled.

    Для исправления необходимо добавить параметр --features=EnableCSI в развертывание Velero.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: velero
spec:
  template:
    spec:
      containers:
      - args:
        - server
        - --uploader-type=restic
+        - --features=EnableCSI
        - --namespace=cpaas-system
        command:
        - /velero
        name: velero

    Выполнение резервного копирования

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

    export BACKUP_POLICY_NAME=${BACKUP_POLICY_NAME:-harbor-backup}
export VELERO_BACKUP_REPO_NAME=${VELERO_BACKUP_REPO_NAME:-backup}

kubectl apply -f - <<EOF
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: ${BACKUP_POLICY_NAME}
  namespace: cpaas-system
spec:
  schedule: '@every 876000h'
  template:
    defaultVolumesToFsBackup: true
    hooks: {}
    includedNamespaces:
    - ${HARBOR_NAMESPACE}
    includedResources:
    - '*'
    resourcePolicy:
      kind: configmap
      name: ${BACKUP_POLICY_NAME}-volume-policy
    storageLocation: ${VELERO_BACKUP_REPO_NAME}
    ttl: 720h0m0s
EOF

kubectl create -f - <<EOF
apiVersion: velero.io/v1
kind: Backup
metadata:
  labels:
    velero.io/schedule-name: ${BACKUP_POLICY_NAME}
    velero.io/storage-location: ${VELERO_BACKUP_REPO_NAME}
  generateName: ${BACKUP_POLICY_NAME}-
  namespace: cpaas-system
spec:
  csiSnapshotTimeout: 10m0s
  defaultVolumesToFsBackup: true
  includedNamespaces:
    - ${HARBOR_NAMESPACE}
  includedResources:
    - "*"
  itemOperationTimeout: 4h0m0s
  resourcePolicy:
    kind: configmap
    name: ${BACKUP_POLICY_NAME}-volume-policy
  snapshotMoveData: false
  storageLocation: ${VELERO_BACKUP_REPO_NAME}
  ttl: 720h0m0s
EOF

# Вывод
# schedule.velero.io/harbor-backup создан
# backup.velero.io/harbor-backup-r6hht создан

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

    kubectl logs -f -n cpaas-system -l app.kubernetes.io/instance=velero --max-log-requests 100 | grep harbor-backup

# Вывод
# time="2025-07-01T07:29:54Z" level=info msg="PodVolumeBackup completed" controller=PodVolumeBackup logSource="pkg/controller/pod_volume_backup_controller.go:244" pvb=harbor-backup-xxx-q7prc

    Проверьте статус задачи. Если статус Completed, резервное копирование прошло успешно.

    kubectl get backup -n cpaas-system -o jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.phase}{'\t'}{.status.startTimestamp}{'\n'}{end}" | grep ${BACKUP_POLICY_NAME}

# Вывод
# Completed

    После успешного резервного копирования отключите режим только для чтения в Harbor

    Войдите в Harbor и снимите галочку в Administration -> Configuration -> System Settings -> Repository Read Only

    Восстановление

    Подготовка

    Подготовка к восстановлению состоит из четырёх шагов:

    1. Выбор резервной копии для восстановления
    2. Определение целевого пространства имён для восстановления
    3. Удаление оператора HARBOR CE

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

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

    kubectl get backup -n cpaas-system -o jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.phase}{'\t'}{.status.startTimestamp}{'\n'}{end}" | grep ${BACKUP_POLICY_NAME} | grep Completed

# Вывод:
# harbor-backup-xxx     Completed       2025-07-01T07:29:19Z

    Установите переменную окружения BACKUP_NAME:

    export BACKUP_NAME=<имя выбранной записи резервного копирования>

    Определение целевого пространства имён

    Рекомендуется восстанавливать в новое пространство имён. Установите следующие переменные окружения:

    export NEW_HARBOR_NAMESPACE=<имя нового пространства имён>
kubectl create namespace ${NEW_HARBOR_NAMESPACE}

    Удаление оператора HARBOR CE

    Выполните следующую команду для удаления оператора HARBOR CE:

    kubectl get subscription --all-namespaces | grep harbor-ce-operator | awk '{print "kubectl delete subscription "$2" -n "$1}' | sh

# Вывод:
# subscription.operators.coreos.com "harbor-ce-operator" deleted
    Почему нужно удалить оператор HARBOR?

    Во время восстановления Velero запускает backup pods для восстановления данных PVC, что занимает длительное время. Если оператор не удалить, могут возникнуть следующие проблемы:

    1. Оператор может пересоздавать рабочие нагрузки на основе HARBOR CR, что приведёт к перезапуску или пересозданию восстановленных pod, в итоге прервав или сорвав восстановление.
    2. Некоторые восстановленные ресурсы могут конфликтовать с существующими, например, Ingress.
    Влияние удаления оператора HARBOR CE

    После удаления оператора изменения в HARBOR CR не будут применяться, например, изменение ресурсов или размера хранилища.

    Удаление оператора не приведёт к сбоям в работе существующих экземпляров.

    Операции восстановления

    Восстановление состоит из пяти шагов:

    1. Создание конфигурационного файла восстановления
    2. Создание задачи восстановления
    3. Очистка ресурсов
    4. Изменение ресурса HARBOR CR
    5. Развёртывание оператора HARBOR CE

    Создание конфигурационного файла восстановления

    Внимательно прочитайте комментарии в YAML и при необходимости внесите изменения (например, смените класс хранилища) перед созданием.

    # Если необходимо изменить класс хранилища, установите следующие переменные окружения
OLD_STORAGECLASS_NAME='' # Исходное имя класса хранилища
NEW_STORAGECLASS_NAME='' # Новое имя класса хранилища

if [ -n "${OLD_STORAGECLASS_NAME}" ] && [ -n "${NEW_STORAGECLASS_NAME}" ] && [ ${NEW_STORAGECLASS_NAME} != ${OLD_STORAGECLASS_NAME} ]; then
kubectl apply -f - <<EOF
apiVersion: v1
data:
  resourcemodifier: |
    version: v1
    resourceModifierRules:
      - conditions:
          groupResource: persistentvolumeclaims
          resourceNameRegex: .*
          namespaces:
            - "*"
        patches: &a1
          - operation: test
            path: /spec/storageClassName
            value: ${OLD_STORAGECLASS_NAME}
          - operation: replace
            path: /spec/storageClassName
            value: ${NEW_STORAGECLASS_NAME}
      - conditions:
          groupResource: persistentvolume
          resourceNameRegex: .*
          namespaces:
            - "*"
        patches: *a1
      - conditions:
          groupResource: persistentvolumeclaims
          resourceNameRegex: .*
          namespaces:
            - "*"
        patches:
          - operation: test
            path: "/metadata/annotations/meta.helm.sh~1release-namespace"
            value: ${HARBOR_NAMESPACE}
          - operation: replace
            path: "/metadata/annotations/meta.helm.sh~1release-namespace"
            value: ${NEW_HARBOR_NAMESPACE}
kind: ConfigMap
metadata:
  labels:
    component: velero
  name: harbor-restore-modifier
  namespace: cpaas-system
EOF

else

kubectl apply -f - <<EOF
apiVersion: v1
data:
  resourcemodifier: |
    version: v1
    resourceModifierRules:
      - conditions:
          groupResource: persistentvolumeclaims
          resourceNameRegex: .*
          namespaces:
            - "*"
        patches:
          - operation: test
            path: "/metadata/annotations/meta.helm.sh~1release-namespace"
            value: ${HARBOR_NAMESPACE}
          - operation: replace
            path: "/metadata/annotations/meta.helm.sh~1release-namespace"
            value: ${NEW_HARBOR_NAMESPACE}
kind: ConfigMap
metadata:
  labels:
    component: velero
  name: harbor-restore-modifier
  namespace: cpaas-system
EOF
fi

    Создание задачи восстановления

    Выполните следующую команду для создания задачи восстановления:

    kubectl create -f - <<EOF
apiVersion: velero.io/v1
kind: Restore
metadata:
  generateName: ${HARBOR_NAME}-restore-
  namespace: cpaas-system
spec:
  backupName: ${BACKUP_NAME}
  hooks: {}
  includedNamespaces:
    - ${HARBOR_NAMESPACE}
  includedResources:
    - persistentvolumeclaims
    - persistentvolumes
    - secrets
    - pods
    - harbors.operator.alaudadevops.io
    - volumesnapshots
    - volumesnapshotcontents
  itemOperationTimeout: 10h0m0s
  namespaceMapping:
    ${HARBOR_NAMESPACE}: ${NEW_HARBOR_NAMESPACE}
  resourceModifier:
    kind: configmap
    name: harbor-restore-modifier
EOF

    Просмотр логов восстановления:

    kubectl logs -f -n cpaas-system -l app.kubernetes.io/instance=velero --max-log-requests 100 | grep harbor-restore

# Вывод
# time="2025-07-01T08:01:41Z" level=info msg="Async fs restore data path completed" PVR=xxxx-HARBOR-restore-mv6l5-sc4pk controller=PodVolumeRestore logSource="pkg/controller/pod_volume_restore_controller.go:275" pvr=xxxx-HARBOR-restore-mv6l5-sc4pk
# time="2025-07-01T08:01:41Z" level=info msg="Restore completed" controller=PodVolumeRestore logSource="pkg/controller/pod_volume_restore_controller.go:327" pvr=xxxx-HARBOR-restore-mv6l5-sc4pk

    Проверьте статус задачи. Если статус Completed, восстановление прошло успешно.

    kubectl get restore -n cpaas-system -o jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.phase}{'\t'}{.status.startTimestamp}{'\n'}{end}" | grep ${HARBOR_NAME}-restore

# Вывод
# xxx-harbor-restore-xxx    InProgress      2025-07-01T10:18:17Z

    Очистка ресурсов

    Убедитесь, что операция восстановления завершена, прежде чем продолжить!

    Выполните следующие команды для очистки ресурсов:

    kubectl delete configmap,secrets,sa -n ${NEW_HARBOR_NAMESPACE} -l release=${HARBOR_NAME}

kubectl get pod -n ${NEW_HARBOR_NAMESPACE} | grep ${HARBOR_NAME} | awk '{print $1}' | xargs kubectl delete pod -n ${NEW_HARBOR_NAMESPACE}

kubectl get secret -n ${NEW_HARBOR_NAMESPACE} | grep sh.helm.release.v1.${HARBOR_NAME} | awk '{print $1}' | xargs kubectl delete secret -n ${NEW_HARBOR_NAMESPACE}

    Изменение ресурса HARBOR CR

    kubectl edit harbor ${HARBOR_NAME} -n ${NEW_HARBOR_NAMESPACE}

    В новом CR экземпляра могут потребоваться следующие изменения. Пожалуйста, скорректируйте в соответствии с вашей ситуацией:

    1. Доменное имя:
      • Сценарий применения: исходный экземпляр был развернут с использованием доменного имени
      • Причина: одинаковые доменные имена в ресурсах Ingress старого и нового экземпляров вызовут конфликт, из-за чего создание Ingress для нового экземпляра не удастся
      • Рекомендация:
        • (Рекомендуется) изменить домен исходного экземпляра на временный, оставить новый экземпляр без изменений
        • Или оставить исходный экземпляр без изменений, а новый экземпляр изменить на новый домен
      • Как изменить: см. Настройка сетевого доступа экземпляра
    2. NodePort:
      • Сценарий применения: исходный экземпляр был развернут с использованием NodePort
      • Причина: одинаковые NodePort в ресурсах Service старого и нового экземпляров вызовут конфликт, из-за чего создание Service для нового экземпляра не удастся
      • Рекомендация:
        • (Рекомендуется) изменить NodePort исходного экземпляра на временный порт, оставить новый экземпляр без изменений
        • Или оставить исходный экземпляр без изменений, а новый экземпляр изменить на новый порт
      • Как изменить: см. Настройка сетевого доступа экземпляра
    3. Класс хранилища:
      • Сценарий применения: класс хранилища старого и нового экземпляров различается (например, исходный использовал NFS, новый — Ceph)
      • Причина: если не изменить, оператор будет использовать старый класс хранилища для создания PVC, что вызовет конфликт с восстановленными PVC
      • Рекомендация: изменить на корректный класс хранилища
      • Как изменить: см. Настройка хранилища экземпляра
    4. Информация для подключения к PostgreSQL:
      • Сценарий применения: новый и старый экземпляры используют разные инстансы или базы данных PostgreSQL
      • Причина: если не изменить, новый экземпляр будет подключаться к старой базе данных
      • Рекомендация: изменить на корректные данные подключения
      • Как изменить: см. Настройка учетных данных PostgreSQL

    Развёртывание оператора HARBOR CE

    Перейдите в представление Administrator, на страницу Marketplace -> OperatorHub и повторно разверните оператор Alauda Build of HARBOR.

    После развертывания оператора он создаст новый экземпляр согласно HARBOR CR. Прогресс можно отслеживать на странице деталей экземпляра.

    После того, как статус экземпляра вернётся в норму, войдите в HARBOR и проверьте успешность восстановления данных. Проверяемые элементы включают, но не ограничиваются:

    • Группы
    • Репозитории
    • Образы

    Одновременно отключите режим только для чтения для восстановленного экземпляра Harbor (войдите в Harbor и снимите галочку в Administration -> Configuration -> System Settings -> Repository Read Only).

    Вопросы и ответы

    Как определить, поддерживает ли PVC snapshot?

    Чтобы определить, поддерживает ли PVC snapshot, необходимо проверить, поддерживает ли его базовый StorageClass функцию snapshot. PVC поддерживает snapshot, если в кластере существует VolumeSnapshotClass, у которого поле driver совпадает с provisioner StorageClass. Если такой VolumeSnapshotClass существует, значит StorageClass (и, следовательно, PVC) поддерживает функцию snapshot.

    Пример конфигурации:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ceph
provisioner: rook-ceph.cephfs.csi.ceph.com
parameters:
  clusterID: rook-ceph
  csi.storage.k8s.io/controller-expand-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/controller-expand-secret-namespace: rook-ceph
  csi.storage.k8s.io/node-stage-secret-name: rook-csi-cephfs-node
  csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph
  fsName: cephfs
  pool: cephfs-data0
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
---
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-cephfs-snapshotclass
deletionPolicy: Delete
driver: rook-ceph.cephfs.csi.ceph.com
parameters:
  clusterID: rook-ceph
  csi.storage.k8s.io/snapshotter-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/snapshotter-secret-namespace: rook-ceph

    Ключевые моменты:

    • provisioner StorageClass должен точно совпадать с driver VolumeSnapshotClass
    • Оба ресурса должны существовать в кластере
    • CSI-драйвер должен поддерживать операции snapshot