• 전제 조건
• 백업 및 복원 절차
• 객체 스토리지
  • S3로의 백업
  • Google Cloud Storage (GCS)로의 백업
  • Azure Blob Storage를 이용한 백업
• 문제 해결
  • Pod 추방 문제
  • “Bucket not found” 오류
  • GCP에서 “AccessDeniedException: 403” 오류
  • --backend s3로 backup-utility를 실행할 때 “/home/git/.s3cfg: None” 오류
  • S3를 사용하여 “PermissionError: File not writable” 오류
  • 복원 시 스킵된 저장소

GitLab 인스턴스의 백업 및 복원

GitLab Helm 차트는 Toolbox 하위 차트에서 제공하는 유틸리티 파드를 제공하여 GitLab 인스턴스를 백업하고 복원하는 목적으로 작동하는 인터페이스 역할을 합니다. 이는 이 작업을 위해 다른 필수 파드들과 상호 작용하는 backup-utility 실행 파일이 장착되어 있습니다. 이 유틸리티가 작동하는 기술적인 세부 정보는 architecture documentation에서 찾을 수 있습니다.

전제 조건

• 여기서 설명된 백업 및 복원 절차는 S3 호환 API로만 테스트되었습니다. Google Cloud Storage와 같은 다른 객체 스토리지 서비스에 대한 지원은 향후 개정판에서 테스트될 예정입니다.

• 복원 중에는 백업 tarball을 디스크에 추출해야 합니다. 이는 Toolbox 파드가 필요한 크기의 디스크를 사용할 수 있어야 함을 의미합니다.

• 이 차트는 artifact, uploads, packages, registry 및 lfs 객체에 대해 객체 스토리지의 사용을 전제로 하며, 복원 중에는 현재 이들을 자동으로 마이그레이션하지 않습니다. 다른 인스턴스에서 백업을 복원하는 경우, 백업을 만들기 전에 기존 인스턴스를 객체 스토리지를 사용하도록 마이그레이션해야 합니다. issue 646을 참조하세요.

백업 및 복원 절차

• GitLab 설치를 백업하는 방법
• GitLab 설치를 복원하는 방법

객체 스토리지

기본적으로이 차트를 사용할 때 MinIO 인스턴스를 제공합니다. (외부 객체 스토리지가 지정되지 않은 경우) Toolbox는 특정 설정이 없는 한 기본적으로 포함된 MinIO에 연결합니다. Toolbox는 또한 Amazon S3 또는 Google Cloud Storage (GCS)로 백업할 수 있도록 구성할 수 있습니다.

S3로의 백업

Toolbox는 기본적으로 객체 스토리지에 연결하기 위해 s3cmd를 사용합니다. 다른 s3 도구를 지정하지 않은 한, 외부 객체 스토리지에 연결하기 위해서는 gitlab.toolbox.backups.objectStorage.config.secret가 .s3cfg 파일을 포함하는 Kubernetes 시크릿을 가리키도록 지정되어야 합니다. gitlab.toolbox.backups.objectStorage.config.key는 기본값(config)과 다른 경우 지정해야 합니다. 이는 .s3cfg 파일의 내용을 포함하는 키를 가리킵니다.

다음과 같이 보이어야 합니다.

helm install gitlab gitlab/gitlab \
  --set gitlab.toolbox.backups.objectStorage.config.secret=my-s3cfg \
  --set gitlab.toolbox.backups.objectStorage.config.key=config .

s3cmd .s3cfg 파일 문서는 여기에서 찾을 수 있습니다.

또한, 백업을 저장할 버킷 위치 두 곳을 구성해야 합니다. 그리고 백업 복원시 사용되는 임시 버킷이 필요합니다.

--set global.appConfig.backups.bucket=gitlab-backup-storage
--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage

Google Cloud Storage (GCS)로의 백업

GCS로 백업하기 위해 gitlab.toolbox.backups.objectStorage.backend를 gcs로 설정해야 합니다. 이를 통해 Toolbox가 객체 저장 및 검색시 gsutil CLI를 사용합니다. 추가로, gitlab.toolbox.backups.objectStorage.config.gcpProject를 사용하여 저장 버킷을 포함하는 GCP 프로젝트의 프로젝트 ID로 설정해야 합니다. 백업에 사용할 버킷의 저장소 관리자 역할을 가진 서비스 계정이 있는 유효한 서비스 계정 JSON 키의 내용을 포함하는 Kubernetes 시크릿을 생성해야 합니다. 아래는 gcloud 및 kubectl을 사용하여 시크릿을 만드는 예제입니다.

export PROJECT_ID=$(gcloud config get-value project)
gcloud iam service-accounts create gitlab-gcs --display-name "Gitlab Cloud Storage"
gcloud projects add-iam-policy-binding --role roles/storage.admin ${PROJECT_ID} --member=serviceAccount:gitlab-gcs@${PROJECT_ID}.iam.gserviceaccount.com
gcloud iam service-accounts keys create --iam-account gitlab-gcs@${PROJECT_ID}.iam.gserviceaccount.com storage.config
kubectl create secret generic storage-config --from-file=config=storage.config

GCS에 인증하기 위해 서비스 계정 키를 사용하도록 Helm 차트를 다음과 같이 구성해야 합니다.

helm install gitlab gitlab/gitlab \
  --set gitlab.toolbox.backups.objectStorage.config.secret=storage-config \
  --set gitlab.toolbox.backups.objectStorage.config.key=config \
  --set gitlab.toolbox.backups.objectStorage.config.gcpProject=my-gcp-project-id \
  --set gitlab.toolbox.backups.objectStorage.backend=gcs

또한, 백업을 저장할 버킷 위치 두 곳을 구성해야 합니다. 그리고 백업 복원시 사용되는 임시 버킷이 필요합니다.

--set global.appConfig.backups.bucket=gitlab-backup-storage
--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage

Azure Blob Storage를 이용한 백업

Azure Blob Storage는 gitlab.toolbox.backups.objectStorage.backend를 azure로 설정하여 백업을 저장하는 데 사용할 수 있습니다. 이를 통해 Toolbox는 azcopy의 내장 복사본을 사용하여 백업 파일을 Azure Blob Storage로 전송하고 검색할 수 있습니다.

Azure Blob Storage를 사용하려면 기존 리소스 그룹에서 저장소 계정을 생성해야 합니다. 저장소 계정의 이름, 액세스 키 및 Blob 호스트로 구성 시크릿을 생성해야 합니다.

다음과 같은 매개변수를 포함하는 구성 파일을 만드세요.

# azure-backup-conf.yaml
azure_storage_account_name: <storage account>
azure_storage_access_key: <access key value>
azure_storage_domain: blob.core.windows.net # 선택 사항

다음 kubectl 명령을 사용하여 Kubernetes 시크릿을 만들 수 있습니다.

kubectl create secret generic backup-azure-creds \
  --from-file=config=azure-backup-conf.yaml

시크릿을 생성한 후에는 GitLab Helm 차트를 구성하여 배포된 값 또는 Helm 명령줄에 설정을 추가하여 백업 설정을 추가할 수 있습니다. 예를 들면:

helm install gitlab gitlab/gitlab \
  --set gitlab.toolbox.backups.objectStorage.config.secret=backup-azure-creds \
  --set gitlab.toolbox.backups.objectStorage.config.key=config \
  --set gitlab.toolbox.backups.objectStorage.backend=azure

시크릿의 액세스 키는 저장소 계정에 액세스하기 위해 짧은 기간 동안 공유 액세스 서명(SAS) 토큰을 생성하고 새로 고침하는 데 사용됩니다.

또한, 백업을 저장할 버킷/컨테이너와 백업을 복원할 때 사용할 임시 버킷/컨테이너 두 개를 미리 생성해야 합니다. 버킷 이름을 값이나 설정에 추가하세요. 예를 들면:

--set global.appConfig.backups.bucket=gitlab-backup-storage
--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage

문제 해결

Pod 추방 문제

백업이 개체 저장 대상 외부에서 지역적으로 조합되기 때문에 임시 디스크 공간이 필요합니다. 필요한 공간은 실제 백업 아카이브의 크기를 초과할 수 있습니다. 기본 구성은 임시 데이터를 저장하기 위해 Toolbox 팟의 파일 시스템을 사용합니다. 자원이 부족하여 팟이 추방되는 경우, 임시 데이터를 저장하기 위해 지속적인 볼륨을 팟에 연결해야 합니다. GKE의 경우 Helm 명령에 다음 설정을 추가하세요.

--set gitlab.toolbox.persistence.enabled=true

백업이 내장된 백업 cron 작업의 일부로 실행되는 경우, cron 작업에 대해서도 지속성을 활성화해야 합니다.

--set gitlab.toolbox.backups.cron.persistence.enabled=true

다른 제공업체의 경우 지속적인 볼륨을 만들어야 할 수 있습니다. 가능한 이를 위한 예제는 저장소 문서를 참조하세요.

“Bucket not found” 오류

백업 중에 Bucket not found 오류가 발생하는 경우 버킷에 대해 구성이 제대로 되었는지 확인하세요.

클라우드 서비스 제공업체에 따라 명령이 다릅니다:

• AWS S3의 경우, 자격 증명은 ~/.s3cfg에 저장됩니다. 다음을 실행하세요:

  s3cmd ls
  

• GCP GCS의 경우 다음을 실행하세요:

  gsutil ls
  

사용 가능한 버킷 목록을 볼 수 있어야 합니다.

GCP에서 “AccessDeniedException: 403” 오류

[Error] AccessDeniedException: 403 <GCP Account>와 같은 오류는 주로 GitLab 인스턴스의 백업 또는 복원 중에 발생하는데, 이는 권한이 없어서 발생합니다.

백업 및 복원 작업은 환경의 모든 버킷을 사용하기 때문에 환경의 모든 버킷에 액세스할 수 있는지 확인하세요.

1. Toolbox 팟을 찾습니다.

   kubectl get pods -lrelease=RELEASE_NAME,app=toolbox
   

2. 환경에 있는 모든 버킷을 가져옵니다. <toolbox-pod-name>을 실제 toolbox 팟 이름으로 바꾸되, “BUCKET_NAME”은 그대로 둡니다.

   kubectl describe pod <toolbox-pod-name> | grep "BUCKET_NAME"
   

3. 환경의 모든 버킷에 액세스 할 수 있는지 확인하세요.

   # 목록
   gsutil ls gs://<bucket-to-validate>/
   
   # 읽기
   gsutil cp gs://<bucket-to-validate>/<object-to-get> <save-to-location>
   
   # 쓰기
   gsutil cp -n <local-file> gs://<bucket-to-validate>/
   

--backend s3로 backup-utility를 실행할 때 “/home/git/.s3cfg: None” 오류

이 오류는 .s3cfg 파일을 포함하는 Kubernetes 시크릿이 gitlab.toolbox.backups.objectStorage.config.secret 값을 통해 지정되지 않았을 때 발생합니다.

이 문제를 해결하려면 S3로의 백업 안내를 따르세요.

S3를 사용하여 “PermissionError: File not writable” 오류

[에러] 경고: <file> 쓰기 불가능: 작업이 허용되지 않음과 같은 오류는 툴박스 사용자가 버킷 아이템의 저장된 권한과 일치하는 파일을 쓰기 위한 권한을 갖고 있지 않을 때 발생합니다.

이를 방지하기 위해 s3cmd를 구성하여 파일 소유자, 모드 및 타임스탬프를 유지하지 않도록 .s3cfg 파일에 다음 플래그를 추가하세요: gitlab.toolbox.backups.objectStorage.config.secret를 통해 참조되는.

preserve_attrs = False

복원 시 스킵된 저장소

GitLab 16.6/Chart 7.6부터 백업 아카이브가 이름이 변경된 경우, 저장소가 복원 중에 건너뛸 수 있습니다. 이를 피하려면 백업 아카이브의 이름을 바꾸지 말고 백업을 원래 이름({backup_id}_gitlab_backup.tar)으로 다시 명명하세요.

원래 백업 ID는 저장소 백업 디렉터리 구조에서 추출할 수 있습니다: repositories/@hashed/*/*/*/{backup_id}/LATEST