Резервное копирование и восстановление GitLab с использованием Velero
В этом руководстве показано, как реализовать операции резервного копирования и восстановления GitLab с помощью Velero — инструмента для аварийного восстановления в облачных нативных средах с открытым исходным кодом.
Область применения
Данное решение применимо к инстансам GitLab версии 17.8 и выше.
Данные GitLab состоят из трёх основных компонентов: базы данных PostgreSQL, Git-репозиториев и загруженных артефактов (включая аватары пользователей, вложения к комментариям и т. д.). Это решение поддерживает резервное копирование только Git-репозиториев и загруженных артефактов. Резервное копирование базы данных PostgreSQL требует отдельной процедуры в соответствии со стратегией резервного копирования вашего поставщика базы данных.
DANGER
Данное решение не поддерживает инстансы GitLab, развернутые с использованием хранилища HostPath.
Терминология
Предварительные требования
- Развернуть MinIO Object Storage: Текущее решение резервного копирования и восстановления использует объектное хранилище для сохранения данных резервных копий, поэтому требуется предварительно развернуть инстанс MinIO. ACP предоставляет
MinIO Object Storage для быстрого создания инстанса MinIO.
- Развернуть Velero: Velero — инструмент для резервного копирования и восстановления. ACP предоставляет
Alauda Container Platform Data Backup for Velero, который можно развернуть во вкладке Administrator на странице Marketplace -> Cluster Plugins, найдите Velero и установите.
- Установить командный инструмент mc: mc — это командная утилита MinIO для управления инстансами MinIO. Инструкции по установке доступны в официальной документации MinIO.
- Установить командный инструмент kubectl: kubectl — командная утилита Kubernetes для управления кластерами 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> # Пример: gitlab-backup-repo
export GITLAB_NAMESPACE=<пространство имён инстанса GitLab для резервного копирования>
export GITLAB_NAME=<имя инстанса GitLab для резервного копирования>
Выполните следующие команды для настройки 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 настроен корректно.
Резервное копирование
Подготовка
Подготовка к резервному копированию включает два шага:
- Создать бакет
- Настроить репозиторий резервных копий Velero
Создание бакета
Выполните команду для создания бакета для хранения данных резервных копий:
mc mb ${MINIO_ALIAS_NAME}/${VELERO_BACKUP_BUCKET}
# Вывод:
# Bucket created successfully `myminio/backup`.
Настройка репозитория резервных копий Velero
Выполните следующие команды для создания репозитория резервных копий Velero, который будет использоваться для хранения данных резервных копий:
gitlab_backup_repo_credentials_secret_name="gitlab-backup-repo-credentials"
minio_gitlab_backup_bucket="${VELERO_BACKUP_BUCKET:-backup}"
minio_gitlab_backup_bucket_directory="gitlab"
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: ${gitlab_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: ${gitlab_backup_repo_credentials_secret_name}
objectStorage:
bucket: ${minio_gitlab_backup_bucket}
prefix: ${minio_gitlab_backup_bucket_directory}
provider: aws
EOF
# Вывод
# secret/gitlab-backup-repo-credentials created
# backupstoragelocationrepo.ait.velero.io/gitlab-backup-repo created
Выполнение резервного копирования
Ручное резервное копирование состоит из шести шагов:
- Пометить ресурсы для резервного копирования
- Остановить сервисы GitLab
- Создать pod для резервного копирования
- Создать расписание резервного копирования
- Выполнить резервное копирование
- Восстановить сервисы GitLab
Пометка ресурсов для резервного копирования
Выполните следующий скрипт:
if [ -z "${GITLAB_NAMESPACE}" ] || [ -z "${GITLAB_NAME}" ]; then
cat <<EOF
Пожалуйста, задайте корректные namespace и имя инстанса:
export GITLAB_NAME=<оригинальное имя инстанса GitLab>
export GITLAB_NAMESPACE=<оригинальное имя namespace>
EOF
return
fi
kubectl label gitlabofficial -n ${GITLAB_NAMESPACE} ${GITLAB_NAME} release=${GITLAB_NAME} --overwrite
secrets_to_label=()
root_password_secret_name=$(kubectl get gitlabofficial -n ${GITLAB_NAMESPACE} ${GITLAB_NAME} -o jsonpath='{.spec.helmValues.global.initialRootPassword.secret}')
secrets_to_label+=(${root_password_secret_name})
rails_secret_name=$(kubectl get gitlabofficial -n ${GITLAB_NAMESPACE} ${GITLAB_NAME} -o jsonpath='{.spec.helmValues.global.railsSecrets.secret}')
if [ -n "${rails_secret_name}" ]; then
echo "Найден rails secret: ${rails_secret_name}"
secrets_to_label+=(${rails_secret_name})
fi
pg_connect_secret_name=$(kubectl get gitlabofficial -n ${GITLAB_NAMESPACE} ${GITLAB_NAME} -o jsonpath='{.spec.helmValues.global.psql.password.secret}')
secrets_to_label+=(${pg_connect_secret_name})
ingress_secret_name=$(kubectl get gitlabofficial -n ${GITLAB_NAMESPACE} ${GITLAB_NAME} -o jsonpath='{.spec.helmValues.global.ingress.tls.secretName}')
if [ -n "${ingress_secret_name}" ]; then
echo "Найден ingress secret: ${ingress_secret_name}"
secrets_to_label+=(${ingress_secret_name})
fi
redis_connect_secret_name=$(kubectl get gitlabofficial -n ${GITLAB_NAMESPACE} ${GITLAB_NAME} -o jsonpath='{.spec.helmValues.global.redis.auth.secret}')
if [ -n "${redis_connect_secret_name}" ]; then
echo "Найден redis auth secret: ${redis_connect_secret_name}"
secrets_to_label+=(${redis_connect_secret_name})
fi
redis_sentinel_connect_secret_name=$(kubectl get gitlabofficial -n ${GITLAB_NAMESPACE} ${GITLAB_NAME} -o jsonpath='{.spec.helmValues.global.redis.sentinelAuth.secret}')
if [ -n "${redis_sentinel_connect_secret_name}" ]; then
echo "Найден redis sentinel connect secret: ${redis_sentinel_connect_secret_name}"
secrets_to_label+=(${redis_sentinel_connect_secret_name})
fi
object_store_secret_name=$(kubectl get gitlabofficial -n ${GITLAB_NAMESPACE} ${GITLAB_NAME} -o jsonpath='{.spec.helmValues.global.appConfig.object_store.connection.secret}')
if [ -n "${object_store_secret_name}" ]; then
echo "Найден секрет подключения к объектному хранилищу: ${object_store_secret_name}"
kubectl label secret ${object_store_secret_name} -n ${GITLAB_NAMESPACE} release=${GITLAB_NAME}
fi
for secret_name in "${secrets_to_label[@]}"; do
echo "Добавление метки к секрету: ${secret_name}"
kubectl label secret ${secret_name} -n ${GITLAB_NAMESPACE} release=${GITLAB_NAME} --overwrite
done
kubectl get pvc -n ${GITLAB_NAMESPACE} --no-headers | grep ${GITLAB_NAME} | awk '{print $1}' | xargs -I {} kubectl label pvc {} release=${GITLAB_NAME} -n ${GITLAB_NAMESPACE}
kubectl get secret -n ${GITLAB_NAMESPACE} --no-headers | grep ${GITLAB_NAME} | awk '{print $1}' | xargs -I {} kubectl label secret {} release=${GITLAB_NAME} -n ${GITLAB_NAMESPACE}
# Вывод:
# secret/sh.helm.release.v1.xxx-gitlab.v9 not labeled
Если необходимо резервировать дополнительные ресурсы, обратитесь к разделу Label Additional Resources for Backup.
Остановка сервисов GitLab
Все компоненты GitLab должны быть остановлены во время резервного копирования:
kubectl annotate statefulset -n ${GITLAB_NAMESPACE} -l release=${GITLAB_NAME} skip-sync="true"
kubectl scale statefulset -n ${GITLAB_NAMESPACE} -l release=${GITLAB_NAME} --replicas=0
kubectl annotate deployment -n ${GITLAB_NAMESPACE} -l release=${GITLAB_NAME} skip-sync="true"
kubectl scale deployment -n ${GITLAB_NAMESPACE} -l release=${GITLAB_NAME} --replicas=0
kubectl delete pod -n ${GITLAB_NAMESPACE} -l release=${GITLAB_NAME} --ignore-not-found
# Вывод:
# statefulset.apps/xxxx-gitlab-gitaly annotated
# deployment.apps/xxxx-gitlab-webservice-default annotated
# deployment.apps/xxxx-gitlab-toolbox scaled
# deployment.apps/xxxx-gitlab-webservice-default scaled
Создание pod для резервного копирования
На этом шаге создаётся pod, который монтирует PVC GitLab, чтобы Velero мог выполнить резервное копирование данных PVC.
image=''
if [ -z "${IMAGE}" ]; then
image=$(kubectl get deployment -n ${GITLAB_NAMESPACE} -l release=${GITLAB_NAME},app=gitlab-shell -o jsonpath='{range .items[0].spec.template.spec.containers[]}{.image}{"\n"}{end}' | head -n1)
fi
PVC_NAMES=($(kubectl get pvc -n ${GITLAB_NAMESPACE} -l release=${GITLAB_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: ${GITLAB_NAME}-backup-pod
namespace: ${GITLAB_NAMESPACE}
labels:
release: ${GITLAB_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 ${GITLAB_NAMESPACE} ${GITLAB_NAME}-backup-pod
# Вывод
# pod/xxxx-gitlab-backup-pod created
# pod/xxxx-gitlab-backup-pod condition met
Создание политики резервного копирования томов
Политика томов используется для указания метода резервного копирования PVC. По умолчанию PVC резервируются с помощью метода fs-backup.
export BACKUP_POLICY_NAME=${BACKUP_POLICY_NAME:-gitlab-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/gitlab-backup-volume-policy created
Если PVC поддерживает snapshot, можно использовать snapshot для резервного копирования PVC, чтобы ускорить процесс. Для этого необходимо изменить 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:-gitlab-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:
- ${GITLAB_NAMESPACE}
includedResources:
- '*'
resourcePolicy:
kind: configmap
name: ${BACKUP_POLICY_NAME}-volume-policy
orLabelSelectors:
- matchLabels:
release: ${GITLAB_NAME}
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:
- ${GITLAB_NAMESPACE}
includedResources:
- "*"
itemOperationTimeout: 4h0m0s
resourcePolicy:
kind: configmap
name: ${BACKUP_POLICY_NAME}-volume-policy
orLabelSelectors:
- matchLabels:
release: ${GITLAB_NAME}
snapshotMoveData: false
storageLocation: ${VELERO_BACKUP_REPO_NAME}
ttl: 720h0m0s
EOF
# Вывод
# schedule.velero.io/gitlab-backup created
# backup.velero.io/gitlab-backup-r6hht created
Просмотр логов резервного копирования:
kubectl logs -f -n cpaas-system -l app.kubernetes.io/instance=velero | grep gitlab-backup
# Вывод
# time="2025-07-01T07:29:54Z" level=info msg="PodVolumeBackup completed" controller=PodVolumeBackup logSource="pkg/controller/pod_volume_backup_controller.go:244" pvb=gitlab-backup-xxx-q7prc
Проверьте статус задачи. Если статус Completed, резервное копирование прошло успешно.
kubectl get backup -n cpaas-system -o jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.phase}{'\t'}{.status.startTimestamp}{'\n'}{end}"
# Вывод
# Completed
Восстановление сервисов GitLab
Удалите pod резервного копирования и восстановите все компоненты GitLab.
kubectl delete pod -n ${GITLAB_NAMESPACE} ${GITLAB_NAME}-backup-pod
kubectl annotate statefulset -n ${GITLAB_NAMESPACE} -l release=${GITLAB_NAME} skip-sync-
kubectl scale statefulset -n ${GITLAB_NAMESPACE} -l release=${GITLAB_NAME} --replicas=1
kubectl annotate deployment -n ${GITLAB_NAMESPACE} -l release=${GITLAB_NAME} skip-sync-
kubectl scale deployment -n ${GITLAB_NAMESPACE} -l release=${GITLAB_NAME} --replicas=1
После восстановления всех компонентов зайдите в инстанс GitLab и убедитесь, что он работает корректно.
Восстановление
Подготовка
Подготовка к восстановлению включает четыре шага:
- Восстановление базы данных PostgreSQL (опционально)
- Выбор резервной копии для восстановления
- Определение целевого пространства имён для восстановления
- Удаление Gitlab CE Operator
Восстановление базы данных PostgreSQL (опционально)
Если новый инстанс будет использовать тот же экземпляр и базу данных PostgreSQL, восстанавливать базу данных не нужно.
Если новый инстанс будет использовать другой экземпляр или базу данных PostgreSQL, необходимо сначала восстановить базу данных PostgreSQL. Обратитесь к документации вашего поставщика PostgreSQL по резервному копированию и восстановлению.
Выбор данных резервной копии для восстановления
Выполните команду для просмотра списка успешных резервных копий и выберите нужную по времени начала.
kubectl get backup -n cpaas-system -o jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.phase}{'\t'}{.status.startTimestamp}{'\n'}{end}" | grep Completed
# Вывод:
# gitlab-backup-xxx Completed 2025-07-01T07:29:19Z
Задайте переменную окружения BACKUP_NAME:
export BACKUP_NAME=<имя выбранной резервной копии>
Определение целевого пространства имён
Рекомендуется восстанавливать инстанс в новое пространство имён. Задайте следующие переменные окружения:
export NEW_GITLAB_NAMESPACE=<имя нового namespace>
kubectl create namespace ${NEW_GITLAB_NAMESPACE}
Удаление Gitlab CE Operator
Выполните команду для удаления GitLab CE Operator:
kubectl get subscription --all-namespaces | grep gitlab-ce-operator | awk '{print "kubectl delete subscription "$2" -n "$1}' | sh
# Вывод:
# subscription.operators.coreos.com "gitlab-ce-operator" deleted
Почему нужно удалить GitLab operator?
Во время восстановления Velero запускает pod для восстановления данных в PVC, что занимает некоторое время. Если operator не удалить, могут возникнуть следующие проблемы:
- Operator может пересоздавать ресурсы workload на основе GitLab CR, что приведёт к перезапуску или пересозданию восстановленных pod и, в итоге, к прерыванию или сбою восстановления.
- Некоторые восстановленные ресурсы могут конфликтовать, например, ingress ресурсы, созданные operator на основе восстановленного GitLab CR, могут конфликтовать с ingress ресурсами старого инстанса.
Влияние удаления GitLab CE Operator
Если operator удалён, изменения в ресурсе GitLab CR не будут применяться, например, изменение ресурсов или размера хранилища.
Удаление operator не приведёт к сбоям в работе существующих инстансов.
Операции восстановления
Восстановление состоит из пяти шагов:
- Создание конфигурационного файла восстановления
- Создание задачи восстановления
- Очистка ресурсов
- Изменение ресурса GitLab CR
- Развёртывание Gitlab CE Operator
Создание конфигурационного файла восстановления
Внимательно прочитайте комментарии в YAML и внесите изменения в соответствии с вашей ситуацией (например, изменение класса хранилища), затем создайте изменённый 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: ${GITLAB_NAMESPACE}
- operation: replace
path: "/metadata/annotations/meta.helm.sh~1release-namespace"
value: ${NEW_GITLAB_NAMESPACE}
kind: ConfigMap
metadata:
labels:
component: velero
name: gitlab-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: ${GITLAB_NAMESPACE}
- operation: replace
path: "/metadata/annotations/meta.helm.sh~1release-namespace"
value: ${NEW_GITLAB_NAMESPACE}
kind: ConfigMap
metadata:
labels:
component: velero
name: gitlab-restore-modifier
namespace: cpaas-system
EOF
fi
Создание задачи восстановления
Выполните команду для создания задачи восстановления:
kubectl create -f - <<EOF
apiVersion: velero.io/v1
kind: Restore
metadata:
generateName: ${GITLAB_NAME}-restore-
namespace: cpaas-system
spec:
backupName: ${BACKUP_NAME}
hooks: {}
includedNamespaces:
- ${GITLAB_NAMESPACE}
includedResources:
- persistentvolumeclaims
- persistentvolumes
- secrets
- pods
- gitlabofficials.operator.alaudadevops.io
- volumesnapshots
- volumesnapshotcontents
itemOperationTimeout: 10h0m0s
namespaceMapping:
${GITLAB_NAMESPACE}: ${NEW_GITLAB_NAMESPACE}
resourceModifier:
kind: configmap
name: gitlab-restore-modifier
EOF
Просмотр логов восстановления:
kubectl logs -f -n cpaas-system -l app.kubernetes.io/instance=velero | grep gitlab-restore
# Вывод
# time="2025-07-01T08:01:41Z" level=info msg="Async fs restore data path completed" PVR=xxxx-gitlab-restore-mv6l5-sc4pk controller=PodVolumeRestore logSource="pkg/controller/pod_volume_restore_controller.go:275" pvr=xxxx-gitlab-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-gitlab-restore-mv6l5-sc4pk
Проверьте статус задачи. Если статус Completed, восстановление прошло успешно.
kubectl get restore -n cpaas-system -o jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.phase}{'\t'}{.status.startTimestamp}{'\n'}{end}"
# Вывод
# xxx-gitlab-restore-xxx InProgress 2025-07-01T10:18:17Z
Очистка ресурсов
Убедитесь, что операция восстановления завершена, прежде чем продолжать!
Выполните команды для очистки ресурсов.
kubectl get pod -n ${NEW_GITLAB_NAMESPACE} | grep ${GITLAB_NAME} | awk '{print $1}' | xargs kubectl delete pod -n ${NEW_GITLAB_NAMESPACE}
kubectl get secret -n ${NEW_GITLAB_NAMESPACE} | grep sh.helm.release.v1.${GITLAB_NAME} | awk '{print $1}' | xargs kubectl delete secret -n ${NEW_GITLAB_NAMESPACE}
Изменение ресурса GitLab CR
kubectl edit gitlabofficial ${GITLAB_NAME} -n ${NEW_GITLAB_NAMESPACE}
В новом CR ресурсе инстанса могут потребоваться следующие изменения. Пожалуйста, внесите изменения в соответствии с вашей ситуацией.
- Доменное имя:
- Сценарий применения: исходный инстанс был развернут с использованием доменного имени
- Причина изменения: одинаковые доменные имена в ingress ресурсах, созданных старым и новым инстансами, вызовут конфликт и не позволят создать ingress ресурсы нового инстанса
- Рекомендации по изменению:
- (Рекомендуется) изменить домен старого инстанса на временный, оставить домен нового инстанса без изменений
- Оставить домен старого инстанса без изменений, изменить домен нового инстанса на новый
- Как изменить: обратитесь к разделу Настройка сетевого доступа инстанса для изменения доменного имени доступа к инстансу.
- NodePort:
- Сценарий применения: исходный инстанс был развернут с использованием NodePort
- Причина изменения: одинаковые NodePort в сервисах, созданных старым и новым инстансами, вызовут конфликт и не позволят создать сервисы нового инстанса
- Рекомендации по изменению:
- (Рекомендуется) изменить NodePort старого инстанса на временный, оставить NodePort нового инстанса без изменений
- Оставить NodePort старого инстанса без изменений, изменить NodePort нового инстанса на новый
- Как изменить: обратитесь к разделу Настройка сетевого доступа инстанса для изменения конфигурации доступа к инстансу.
- Класс хранилища:
- Сценарий применения: исходный инстанс был развернут с классом хранилища, и между старым и новым инстансами изменился класс хранилища (например, старый использовал NFS, новый — Ceph)
- Причина изменения: если не изменить, operator будет использовать старый класс хранилища для создания PVC, что вызовет конфликт с восстановленными PVC
- Рекомендация по изменению: изменить класс хранилища на корректный
- Как изменить: обратитесь к разделу Настройка хранилища инстанса для изменения конфигурации хранилища инстанса.
- Информация для подключения к PostgreSQL:
- Сценарий применения: новый инстанс и старый планируют использовать разные экземпляры или базы данных PostgreSQL
- Причина изменения: если не изменить, новый инстанс будет подключаться к старому экземпляру или базе данных PostgreSQL
- Рекомендация по изменению: изменить данные подключения к PostgreSQL на корректные
- Как изменить: обратитесь к разделу Настройка учётных данных доступа к PostgreSQL для изменения конфигурации доступа к PostgreSQL.
Развёртывание Gitlab CE Operator
Перейдите во вкладку Administrator, на страницу Marketplace -> OperatorHub и заново разверните оператор Alauda Build of Gitlab.
После развертывания Operator развернёт новый инстанс согласно GitLab CR. Вы можете отслеживать прогресс развертывания на странице деталей инстанса.
После того как статус инстанса вернётся в норму, войдите в GitLab и проверьте успешность восстановления данных. Проверяемые элементы включают, но не ограничиваются:
- Группы
- Репозитории
- Пользователи
- Merge Requests
Вопросы и ответы
Label Additional Resources for Backup
Этот шаг необязателен. Если у вас есть другие ресурсы в том же namespace, которые вы хотите резервировать вместе, вы можете добавить метку release к соответствующим ресурсам. Значение метки должно быть именем оригинального инстанса GitLab, например:
metadata:
labels:
release: gitlab-g6zd4
How to determine if the PVC supports 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
