InfoGrab Docs

대규모 참조 아키텍처의 백업 및 복원

요약

GitLab 백업은 데이터 일관성을 보존하고 대규모 GitLab 배포에 대한 재해 복구를 가능하게 합니다. 3,000명 이상의 사용자를 지원하는 참조 아키텍처를 실행하는 GitLab 환경에 대해 이러한 절차를 따르고, 클라우드 기반 데이터베이스와 오브젝트 스토리지에 대한 특별 고려사항을 따릅니다.

GitLab 백업은 데이터 일관성을 보존하고 대규모 GitLab 배포에 대한 재해 복구를 가능하게 합니다. 이 프로세스는:

  • 분산 스토리지 구성 요소 간 데이터 백업 조율
  • 수 테라바이트 크기의 PostgreSQL 데이터베이스 보존
  • 외부 서비스의 오브젝트 스토리지 데이터 보호
  • 대용량 Git 리포지터리 컬렉션의 백업 무결성 유지
  • 구성 및 비밀 파일의 복구 가능한 복사본 생성
  • 최소한의 다운타임으로 시스템 데이터 복원 가능

3,000명 이상의 사용자를 지원하는 참조 아키텍처를 실행하는 GitLab 환경에 대해 이러한 절차를 따르고, 클라우드 기반 데이터베이스와 오브젝트 스토리지에 대한 특별 고려사항을 따릅니다.

Note

이 문서는 다음을 사용하는 환경을 위한 것입니다:

일일 백업 구성#

PostgreSQL 데이터 백업 구성#

백업 명령은 pg_dump를 사용하는데, 이는 100GB를 초과하는 데이터베이스에는 적합하지 않습니다. 네이티브 강력한 백업 기능을 갖춘 PostgreSQL 솔루션을 선택해야 합니다.

  1. RDS(및 S3) 데이터를 백업하도록 AWS Backup을 구성합니다. 최대 보호를 위해 지속적인 백업과 스냅샷 백업을 모두 구성합니다.
  2. 백업을 별도의 리전으로 복사하도록 AWS Backup을 구성합니다. AWS가 백업을 수행할 때 백업이 저장된 리전에서만 백업을 복원할 수 있습니다.
  3. AWS Backup이 하나 이상의 예약된 백업을 실행한 후 필요에 따라 온디맨드 백업을 생성할 수 있습니다.

Google Cloud SQL 데이터의 자동 일일 백업을 예약합니다. 일일 백업은 최대 1년 동안 보존될 수 있으며 트랜잭션 로그는 특정 시점 복구를 위해 기본적으로 7일 동안 보존됩니다.

오브젝트 스토리지 데이터 백업 구성#

블롭 및 컨테이너 레지스트리를 포함한 GitLab 데이터를 저장하려면 오브젝트 스토리지(NFS가 아님)를 권장합니다.

S3 데이터를 백업하도록 AWS Backup을 구성합니다. 이는 PostgreSQL 데이터 백업 구성과 동시에 수행할 수 있습니다.

  1. GCS에 백업 버킷을 생성합니다.

  2. 각 GitLab 오브젝트 스토리지 버킷을 백업 버킷으로 복사하는 스토리지 전송 서비스 작업을 생성합니다. 이러한 작업을 한 번 생성하고 매일 실행되도록 예약할 수 있습니다. 그러나 이렇게 하면 새 오브젝트 스토리지 데이터와 이전 데이터가 혼합되므로 GitLab에서 삭제된 파일이 백업에 여전히 존재합니다. 이는 복원 후 스토리지를 낭비하지만 그 외에는 문제가 없습니다. 이러한 파일은 GitLab 데이터베이스에 존재하지 않기 때문에 GitLab 사용자에게 액세스할 수 없습니다. 복원 후 이러한 고아 파일 중 일부를 삭제할 수 있지만 이 정리 Rake 작업은 파일의 일부에서만 작동합니다.

    1. 덮어쓸 때에서 없음을 선택합니다. GitLab 오브젝트 저장 파일은 변경 불가능해야 합니다. 이 선택은 악의적인 행위자가 GitLab 파일을 변조에 성공한 경우 도움이 될 수 있습니다.
    2. 삭제할 때에서 없음을 선택합니다. 백업 버킷을 소스와 동기화하면 소스에서 파일이 실수로 또는 악의적으로 삭제된 경우 복구할 수 없습니다.

  3. 또는 날짜별로 구분된 버킷 또는 하위 디렉토리에 오브젝트 스토리지를 백업할 수 있습니다. 이렇게 하면 복원 후 고아 파일 문제를 피할 수 있으며 필요한 경우 파일 버전 백업을 지원합니다. 그러나 백업 스토리지 비용이 크게 증가합니다. 이는 Cloud Scheduler에 의해 트리거되는 Cloud Function이나 cron 작업으로 실행되는 스크립트로 수행할 수 있습니다. 부분 예시:

    # Set GCP project so you don't have to specify it in every command
gcloud config set project example-gcp-project-name

# Grant the Storage Transfer Service's hidden service account permission to write to the backup bucket. The integer 123456789012 is the GCP project's ID.
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.objectAdmin gs://backup-bucket

# Grant the Storage Transfer Service's hidden service account permission to list and read objects in the source buckets. The integer 123456789012 is the GCP project's ID.
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-artifacts
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-ci-secure-files
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-dependency-proxy
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-lfs
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-mr-diffs
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-packages
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-pages
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-registry
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-terraform-state
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-uploads

# Create transfer jobs for each bucket, targeting a subdirectory in the backup bucket.
today=$(date +%F)
gcloud transfer jobs create gs://gitlab-bucket-artifacts/ gs://backup-bucket/$today/artifacts/ --name "$today-backup-artifacts"
gcloud transfer jobs create gs://gitlab-bucket-ci-secure-files/ gs://backup-bucket/$today/ci-secure-files/ --name "$today-backup-ci-secure-files"
gcloud transfer jobs create gs://gitlab-bucket-dependency-proxy/ gs://backup-bucket/$today/dependency-proxy/ --name "$today-backup-dependency-proxy"
gcloud transfer jobs create gs://gitlab-bucket-lfs/ gs://backup-bucket/$today/lfs/ --name "$today-backup-lfs"
gcloud transfer jobs create gs://gitlab-bucket-mr-diffs/ gs://backup-bucket/$today/mr-diffs/ --name "$today-backup-mr-diffs"
gcloud transfer jobs create gs://gitlab-bucket-packages/ gs://backup-bucket/$today/packages/ --name "$today-backup-packages"
gcloud transfer jobs create gs://gitlab-bucket-pages/ gs://backup-bucket/$today/pages/ --name "$today-backup-pages"
gcloud transfer jobs create gs://gitlab-bucket-registry/ gs://backup-bucket/$today/registry/ --name "$today-backup-registry"
gcloud transfer jobs create gs://gitlab-bucket-terraform-state/ gs://backup-bucket/$today/terraform-state/ --name "$today-backup-terraform-state"
gcloud transfer jobs create gs://gitlab-bucket-uploads/ gs://backup-bucket/$today/uploads/ --name "$today-backup-uploads"
    1. 이러한 전송 작업은 실행 후 자동으로 삭제되지 않습니다. 스크립트에서 오래된 작업 정리를 구현할 수 있습니다.
    2. 예시 스크립트는 이전 백업을 삭제하지 않습니다. 원하는 보존 정책에 따라 이전 백업 정리를 구현할 수 있습니다.

  4. 백업이 Cloud SQL 백업보다 같은 시간 또는 늦게 수행되도록 하여 데이터 불일치를 줄입니다.

Git 리포지터리 백업 구성#

Gitaly 서버 사이드 백업을 수행하기 위한 cron 작업을 설정합니다:

  1. 서버 사이드 백업 구성을 따라 모든 Gitaly 노드에서 Gitaly 서버 사이드 백업 대상을 구성합니다. 이 버킷은 리포지터리 데이터를 저장하기 위해 Gitaly에서만 사용됩니다.

  2. Gitaly가 이전에 구성된 지정된 오브젝트 스토리지 버킷에 모든 Git 리포지터리 데이터를 백업하는 동안, 백업 유틸리티 도구(gitlab-backup)는 추가 백업 데이터를 업로드합니다. 이 데이터에는 복원을 위한 필수 메타데이터가 포함된 tar 파일이 포함됩니다. 다른 백업과 동일한 버킷을 사용하거나 별도의 버킷을 사용할 수 있습니다. 이 백업 데이터가 원격(클라우드) 스토리지에 올바르게 업로드되도록 백업을 원격(클라우드) 스토리지에 업로드를 따라 업로드 버킷을 설정합니다.

  3. (선택 사항) 이 백업 데이터의 내구성을 강화하기 위해 이전에 구성된 버킷을 오브젝트 스토리지 데이터 백업에 추가하여 해당 오브젝트 스토어 제공업체로 백업합니다.

  4. Puma 또는 Sidekiq를 실행하는 노드인 GitLab Rails 노드에 SSH로 접속합니다.

  5. Git 데이터의 전체 백업을 수행합니다. REPOSITORIES_SERVER_SIDE 변수를 사용하고 PostgreSQL 데이터를 건너뜁니다:

    sudo gitlab-backup create REPOSITORIES_SERVER_SIDE=true SKIP=db

    이렇게 하면 Gitaly 노드가 Git 데이터와 일부 메타데이터를 원격 스토리지에 업로드합니다. 업로드, 아티팩트, LFS와 같은 블롭은 gitlab-backup 명령이 기본적으로 오브젝트 스토리지를 백업하지 않으므로 명시적으로 건너뛸 필요가 없습니다.

  6. 다음 단계에 필요한 백업의 백업 ID를 기록합니다. 예를 들어 백업 명령이 2024-02-22 02:17:47 UTC -- Backup 1708568263_2024_02_22_16.9.0-ce is done.을 출력하면 백업 ID는 1708568263_2024_02_22_16.9.0-ce입니다.

  7. 전체 백업이 Gitaly 백업 버킷과 일반 백업 버킷 모두에 데이터를 생성했는지 확인합니다.

  8. 백업 명령을 다시 실행하되, 이번에는 Git 리포지터리의 증분 백업과 백업 ID를 지정합니다. 이전 단계의 예시 ID를 사용하면 명령은:

    sudo gitlab-backup create REPOSITORIES_SERVER_SIDE=true SKIP=db INCREMENTAL=yes PREVIOUS_BACKUP=1708568263_2024_02_22_16.9.0-ce

    PREVIOUS_BACKUP의 값은 이 명령에서 사용되지 않지만 명령에서 필요합니다. 이 불필요한 요구사항을 제거하기 위한 이슈가 있습니다. 이슈 429141을 참조하십시오.

  9. 증분 백업이 성공했고 오브젝트 스토리지에 데이터가 추가되었는지 확인합니다.

  10. cron을 구성하여 일일 백업을 수행합니다. root 사용자의 crontab을 편집합니다:

    sudo su -
crontab -e

  11. 매달 1일에는 Git 리포지터리의 전체 백업을, 나머지 날에는 증분 백업을 수행하도록 매월 매일 오전 2시에 백업을 예약하는 다음 줄을 추가합니다. 이는 백업을 복원하는 데 필요한 증분 수를 제한하기 위한 것입니다:

    0 2 1 * * /opt/gitlab/bin/gitlab-backup create REPOSITORIES_SERVER_SIDE=true SKIP=db CRON=1
0 2 2-31 * * /opt/gitlab/bin/gitlab-backup create REPOSITORIES_SERVER_SIDE=true SKIP=db INCREMENTAL=yes PREVIOUS_BACKUP=1708568263_2024_02_22_16.9.0-ce CRON=1

  1. 서버 사이드 백업 구성을 따라 모든 Gitaly 노드에서 Gitaly 서버 사이드 백업 대상을 구성합니다. 이 버킷은 리포지터리 데이터를 저장하기 위해 Gitaly에서만 사용됩니다.

  2. Gitaly가 이전에 구성된 지정된 오브젝트 스토리지 버킷에 모든 Git 리포지터리 데이터를 백업하는 동안, 백업 유틸리티 도구(gitlab-backup)는 추가 백업 데이터를 업로드합니다. 이 데이터에는 복원을 위한 필수 메타데이터가 포함된 tar 파일이 포함됩니다. 다른 백업과 동일한 버킷을 사용하거나 별도의 버킷을 사용할 수 있습니다. 이 백업 데이터가 원격(클라우드) 스토리지에 올바르게 업로드되도록 백업을 원격(클라우드) 스토리지에 업로드를 따라 업로드 버킷을 설정합니다.

  3. (선택 사항) 이 백업 데이터의 내구성을 강화하기 위해 이전에 구성된 버킷을 오브젝트 스토리지 데이터 백업에 추가하여 해당 오브젝트 스토어 제공업체로 백업할 수 있습니다.

  4. Puma 또는 Sidekiq를 실행하는 노드인 GitLab Rails 노드에 SSH로 접속합니다.

  5. Git 데이터의 전체 백업을 수행합니다. REPOSITORIES_SERVER_SIDE 변수를 사용하고 다른 모든 데이터를 건너뜁니다:

    kubectl exec  -it -- backup-utility --repositories-server-side --skip db,builds,pages,registry,uploads,artifacts,lfs,packages,external_diffs,terraform_state,pages,ci_secure_files

    이렇게 하면 Gitaly 노드가 Git 데이터와 일부 메타데이터를 원격 스토리지에 업로드합니다. Toolbox 포함 도구를 참조하십시오.

  6. 전체 백업이 Gitaly 백업 버킷과 일반 백업 버킷 모두에 데이터를 생성했는지 확인합니다. 증분 리포지터리 백업은 서버 사이드 리포지터리 백업과 함께 backup-utility에서 지원되지 않습니다. charts 이슈 3421을 참조하십시오.

  7. cron을 구성하여 일일 백업을 수행합니다. 구체적으로 gitlab.toolbox.backups.cron.extraArgs를 다음을 포함하도록 설정합니다:

    --repositories-server-side --skip db --skip repositories --skip uploads --skip builds --skip artifacts --skip pages --skip lfs --skip terraform_state --skip registry --skip packages --skip ci_secure_files

구성 파일 백업 구성#

구성 및 비밀이 배포 외부에 정의된 다음 배포에 배포된 경우 백업 전략의 구현은 특정 설정 및 요구 사항에 따라 달라집니다. 예를 들어 여러 리전으로 복제하는 AWS Secret Manager에 비밀을 저장하고 비밀을 자동으로 백업하는 스크립트를 구성할 수 있습니다.

구성 및 비밀이 배포 내부에만 정의된 경우:

  1. 구성 파일 저장에서는 구성 및 비밀 파일을 추출하는 방법을 설명합니다.
  2. 이러한 파일은 별도의 더 제한적인 오브젝트 스토리지 계정에 업로드해야 합니다.

백업 복원#

GitLab 인스턴스의 백업을 복원합니다.

사전 요구사항#

백업을 복원하기 전에:

  1. 작동하는 대상 GitLab 인스턴스를 선택합니다.

  2. 대상 GitLab 인스턴스가 AWS 백업이 저장된 리전에 있는지 확인합니다.

  3. 대상 GitLab 인스턴스가 백업 데이터가 생성된 것과 정확히 동일한 버전과 유형(CE 또는 EE)의 GitLab을 사용하는지 확인합니다. 예를 들어 CE 15.1.4.

  4. 대상 GitLab 인스턴스에 백업된 비밀을 복원합니다.

  5. 대상 GitLab 인스턴스에 동일한 리포지터리 스토리지가 구성되어 있는지 확인합니다. 추가 스토리지는 괜찮습니다.

  6. 오브젝트 스토리지가 구성되어 있는지 확인합니다.

  7. 새 비밀 또는 구성을 사용하고 복원 중에 예상치 못한 구성 변경을 처리하지 않으려면:

    • 모든 노드의 Linux 패키지 설치:

      1. 대상 GitLab 인스턴스를 재구성합니다.
      2. 대상 GitLab 인스턴스를 재시작합니다.

    • Helm chart(Kubernetes) 설치:

      1. 모든 GitLab Linux 패키지 노드에서 다음을 실행합니다:

        sudo gitlab-ctl reconfigure
sudo gitlab-ctl start

      2. 차트를 배포하여 실행 중인 GitLab 인스턴스가 있는지 확인합니다. 다음 명령을 실행하여 Toolbox pod가 활성화되고 실행 중인지 확인합니다:

        kubectl get pods -lrelease=RELEASE_NAME,app=toolbox

      3. Webservice, Sidekiq 및 Toolbox pod를 다시 시작해야 합니다. 이러한 pod를 다시 시작하는 가장 안전한 방법은 다음을 실행하는 것입니다:

        kubectl delete pods -lapp=sidekiq,release=<helm release name>
kubectl delete pods -lapp=webservice,release=<helm release name>
kubectl delete pods -lapp=toolbox,release=<helm release name>

  8. 대상 GitLab 인스턴스가 여전히 작동하는지 확인합니다. 예를 들어:

  9. PostgreSQL 데이터베이스에 연결하는 GitLab 서비스를 중지합니다.

    • Puma 또는 Sidekiq를 실행하는 모든 노드의 Linux 패키지 설치:

      sudo gitlab-ctl stop

    • Helm chart(Kubernetes) 설치:

      1. 이후 재시작을 위해 데이터베이스 클라이언트의 현재 복제본 수를 기록합니다:

        kubectl get deploy -n <namespace> -lapp=sidekiq,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
kubectl get deploy -n <namespace> -lapp=webservice,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
kubectl get deploy -n <namespace> -lapp=prometheus,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'

      2. 복원 프로세스에 방해가 되는 잠금을 방지하기 위해 데이터베이스 클라이언트를 중지합니다:

        kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=0
kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=0
kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=0

오브젝트 스토리지 데이터 복원#

각 버킷은 AWS 내에서 별도의 백업으로 존재하며 각 백업은 기존 또는 새 버킷으로 복원할 수 있습니다.

  1. 버킷을 복원하려면 올바른 권한이 있는 IAM 권한이 필요합니다:

    • AWSBackupServiceRolePolicyForBackup
    • AWSBackupServiceRolePolicyForRestores
    • AWSBackupServiceRolePolicyForS3Restore
    • AWSBackupServiceRolePolicyForS3Backup

  2. 기존 버킷을 사용하는 경우 액세스 제어 목록이 활성화되어 있어야 합니다.

  3. 내장 도구를 사용하여 S3 버킷을 복원합니다.

  4. 복원 작업이 실행되는 동안 PostgreSQL 데이터 복원으로 진행할 수 있습니다.

  1. 스토리지 전송 서비스 작업을 생성하여 백업된 데이터를 GitLab 버킷으로 전송합니다.
  2. 전송 작업이 실행되는 동안 PostgreSQL 데이터 복원으로 진행할 수 있습니다.

PostgreSQL 데이터 복원#

  1. 내장 도구를 사용하여 AWS RDS 데이터베이스를 복원하면 새 RDS 인스턴스가 생성됩니다.

  2. 새 RDS 인스턴스에는 다른 엔드포인트가 있으므로 새 데이터베이스를 가리키도록 대상 GitLab 인스턴스를 재구성해야 합니다:

  3. 계속하기 전에 새 RDS 인스턴스가 생성되어 사용할 준비가 될 때까지 기다립니다.

  1. 내장 도구를 사용하여 Google Cloud SQL 데이터베이스를 복원합니다.

  2. 새 데이터베이스 인스턴스로 복원하는 경우 새 데이터베이스를 가리키도록 GitLab을 재구성합니다:

  3. 계속하기 전에 Cloud SQL 인스턴스가 사용할 준비가 될 때까지 기다립니다.

Git 리포지터리 복원#

먼저 오브젝트 스토리지 데이터 복원의 일환으로 이미 다음을 수행했어야 합니다:

  • Git 리포지터리의 Gitaly 서버 사이드 백업이 포함된 버킷을 복원합니다.
  • *_gitlab_backup.tar 파일이 포함된 버킷을 복원합니다.

  1. Puma 또는 Sidekiq를 실행하는 노드인 GitLab Rails 노드에 SSH로 접속합니다.

  2. 백업 버킷에서 복원한 PostgreSQL 및 오브젝트 스토리지 데이터와 타임스탬프를 기준으로 *_gitlab_backup.tar 파일을 선택합니다.

  3. /var/opt/gitlab/backups/에 tar 파일을 다운로드합니다.

  4. 복원하려는 백업의 ID를 지정하고 이름에서 _gitlab_backup.tar를 생략하여 백업을 복원합니다:

    # This command will overwrite the contents of your GitLab database!
sudo gitlab-backup restore BACKUP=11493107454_2018_04_25_10.6.4-ce SKIP=db

    백업 tar 파일과 설치된 GitLab 버전 간에 GitLab 버전 불일치가 있는 경우 복원 명령이 오류 메시지와 함께 중단됩니다. 올바른 GitLab 버전을 설치한 다음 다시 시도합니다.

  5. GitLab을 재구성, 시작하고 확인합니다:

    1. 모든 PostgreSQL 노드에서 다음을 실행합니다:

      sudo gitlab-ctl reconfigure

    2. 모든 Puma 또는 Sidekiq 노드에서 다음을 실행합니다:

      sudo gitlab-ctl start

    3. 하나의 Puma 또는 Sidekiq 노드에서 다음을 실행합니다:

      sudo gitlab-rake gitlab:check SANITIZE=true

  6. 데이터베이스 값을 현재 비밀을 사용하여 해독할 수 있는지 확인합니다. 특히 /etc/gitlab/gitlab-secrets.json이 복원된 경우 또는 다른 서버가 복원의 대상인 경우:

    Puma 또는 Sidekiq 노드에서 다음을 실행합니다:

    sudo gitlab-rake gitlab:doctor:secrets

  7. 추가적인 보증을 위해 업로드된 파일에 대한 무결성 검사를 수행할 수 있습니다:

    Puma 또는 Sidekiq 노드에서 다음을 실행합니다:

    sudo gitlab-rake gitlab:artifacts:check
sudo gitlab-rake gitlab:lfs:check
sudo gitlab-rake gitlab:uploads:check

    누락되거나 손상된 파일이 발견되더라도 백업 및 복원 프로세스가 실패했다는 의미는 아닙니다. 예를 들어 파일이 원본 GitLab 인스턴스에서 누락되거나 손상될 수 있습니다. 이전 백업을 교차 참조해야 할 수 있습니다. GitLab을 새 환경으로 마이그레이션하는 경우 원본 GitLab 인스턴스에서 동일한 검사를 실행하여 무결성 검사 결과가 기존 것인지 백업 및 복원 프로세스와 관련된 것인지 확인할 수 있습니다.

  1. toolbox pod에 SSH로 접속합니다.

  2. 백업 버킷에서 복원한 PostgreSQL 및 오브젝트 스토리지 데이터와 타임스탬프를 기준으로 *_gitlab_backup.tar 파일을 선택합니다.

  3. /var/opt/gitlab/backups/에 tar 파일을 다운로드합니다.

  4. 복원하려는 백업의 ID를 지정하고 이름에서 _gitlab_backup.tar를 생략하여 백업을 복원합니다:

    # This command will overwrite the contents of Gitaly!
kubectl exec  -it -- backup-utility --restore -t 11493107454_2018_04_25_10.6.4-ce --skip db,builds,pages,registry,uploads,artifacts,lfs,packages,external_diffs,terraform_state,pages,ci_secure_files

    백업 tar 파일과 설치된 GitLab 버전 간에 GitLab 버전 불일치가 있는 경우 복원 명령이 오류 메시지와 함께 중단됩니다. 올바른 GitLab 버전을 설치한 다음 다시 시도합니다.

  5. GitLab을 재시작하고 확인합니다:

    1. 사전 요구사항에서 기록된 복제본 수를 사용하여 중지된 배포를 시작합니다:

      kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=<original value>
kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=<original value>
kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=<original value>

    2. Toolbox pod에서 다음을 실행합니다:

      sudo gitlab-rake gitlab:check SANITIZE=true

  6. 데이터베이스 값을 현재 비밀을 사용하여 해독할 수 있는지 확인합니다. 특히 /etc/gitlab/gitlab-secrets.json이 복원된 경우 또는 다른 서버가 복원의 대상인 경우:

    Toolbox pod에서 다음을 실행합니다:

    sudo gitlab-rake gitlab:doctor:secrets

  7. 추가적인 보증을 위해 업로드된 파일에 대한 무결성 검사를 수행할 수 있습니다:

    이러한 명령은 모든 행을 반복하기 때문에 시간이 오래 걸릴 수 있습니다. 따라서 Toolbox pod가 아닌 GitLab Rails 노드에서 다음 명령을 실행합니다:

    sudo gitlab-rake gitlab:artifacts:check
sudo gitlab-rake gitlab:lfs:check
sudo gitlab-rake gitlab:uploads:check

    누락되거나 손상된 파일이 발견되더라도 백업 및 복원 프로세스가 실패했다는 의미는 아닙니다. 예를 들어 파일이 원본 GitLab 인스턴스에서 누락되거나 손상될 수 있습니다. 이전 백업을 교차 참조해야 할 수 있습니다. GitLab을 새 환경으로 마이그레이션하는 경우 원본 GitLab 인스턴스에서 동일한 검사를 실행하여 무결성 검사 결과가 기존 것인지 백업 및 복원 프로세스와 관련된 것인지 확인할 수 있습니다.

복원이 완료되어야 합니다.

대규모 참조 아키텍처의 백업 및 복원

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

GitLab 백업은 데이터 일관성을 보존하고 대규모 GitLab 배포에 대한 재해 복구를 가능하게 합니다. 3,000명 이상의 사용자를 지원하는 참조 아키텍처를 실행하는 GitLab 환경에 대해 이러한 절차를 따르고, 클라우드 기반 데이터베이스와 오브젝트 스토리지에 대한 특별 고려사항을 따릅니다.

GitLab 백업은 데이터 일관성을 보존하고 대규모 GitLab 배포에 대한 재해 복구를 가능하게 합니다. 이 프로세스는:

  • 분산 스토리지 구성 요소 간 데이터 백업 조율
  • 수 테라바이트 크기의 PostgreSQL 데이터베이스 보존
  • 외부 서비스의 오브젝트 스토리지 데이터 보호
  • 대용량 Git 리포지터리 컬렉션의 백업 무결성 유지
  • 구성 및 비밀 파일의 복구 가능한 복사본 생성
  • 최소한의 다운타임으로 시스템 데이터 복원 가능

3,000명 이상의 사용자를 지원하는 참조 아키텍처를 실행하는 GitLab 환경에 대해 이러한 절차를 따르고, 클라우드 기반 데이터베이스와 오브젝트 스토리지에 대한 특별 고려사항을 따릅니다.

Note

이 문서는 다음을 사용하는 환경을 위한 것입니다:

일일 백업 구성#

PostgreSQL 데이터 백업 구성#

백업 명령은 pg_dump를 사용하는데, 이는 100GB를 초과하는 데이터베이스에는 적합하지 않습니다. 네이티브 강력한 백업 기능을 갖춘 PostgreSQL 솔루션을 선택해야 합니다.

  1. RDS(및 S3) 데이터를 백업하도록 AWS Backup을 구성합니다. 최대 보호를 위해 지속적인 백업과 스냅샷 백업을 모두 구성합니다.
  2. 백업을 별도의 리전으로 복사하도록 AWS Backup을 구성합니다. AWS가 백업을 수행할 때 백업이 저장된 리전에서만 백업을 복원할 수 있습니다.
  3. AWS Backup이 하나 이상의 예약된 백업을 실행한 후 필요에 따라 온디맨드 백업을 생성할 수 있습니다.

Google Cloud SQL 데이터의 자동 일일 백업을 예약합니다. 일일 백업은 최대 1년 동안 보존될 수 있으며 트랜잭션 로그는 특정 시점 복구를 위해 기본적으로 7일 동안 보존됩니다.

오브젝트 스토리지 데이터 백업 구성#

블롭 및 컨테이너 레지스트리를 포함한 GitLab 데이터를 저장하려면 오브젝트 스토리지(NFS가 아님)를 권장합니다.

S3 데이터를 백업하도록 AWS Backup을 구성합니다. 이는 PostgreSQL 데이터 백업 구성과 동시에 수행할 수 있습니다.

  1. GCS에 백업 버킷을 생성합니다.

  2. 각 GitLab 오브젝트 스토리지 버킷을 백업 버킷으로 복사하는 스토리지 전송 서비스 작업을 생성합니다. 이러한 작업을 한 번 생성하고 매일 실행되도록 예약할 수 있습니다. 그러나 이렇게 하면 새 오브젝트 스토리지 데이터와 이전 데이터가 혼합되므로 GitLab에서 삭제된 파일이 백업에 여전히 존재합니다. 이는 복원 후 스토리지를 낭비하지만 그 외에는 문제가 없습니다. 이러한 파일은 GitLab 데이터베이스에 존재하지 않기 때문에 GitLab 사용자에게 액세스할 수 없습니다. 복원 후 이러한 고아 파일 중 일부를 삭제할 수 있지만 이 정리 Rake 작업은 파일의 일부에서만 작동합니다.

    1. 덮어쓸 때에서 없음을 선택합니다. GitLab 오브젝트 저장 파일은 변경 불가능해야 합니다. 이 선택은 악의적인 행위자가 GitLab 파일을 변조에 성공한 경우 도움이 될 수 있습니다.
    2. 삭제할 때에서 없음을 선택합니다. 백업 버킷을 소스와 동기화하면 소스에서 파일이 실수로 또는 악의적으로 삭제된 경우 복구할 수 없습니다.

  3. 또는 날짜별로 구분된 버킷 또는 하위 디렉토리에 오브젝트 스토리지를 백업할 수 있습니다. 이렇게 하면 복원 후 고아 파일 문제를 피할 수 있으며 필요한 경우 파일 버전 백업을 지원합니다. 그러나 백업 스토리지 비용이 크게 증가합니다. 이는 Cloud Scheduler에 의해 트리거되는 Cloud Function이나 cron 작업으로 실행되는 스크립트로 수행할 수 있습니다. 부분 예시:

    # Set GCP project so you don't have to specify it in every command
gcloud config set project example-gcp-project-name

# Grant the Storage Transfer Service's hidden service account permission to write to the backup bucket. The integer 123456789012 is the GCP project's ID.
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.objectAdmin gs://backup-bucket

# Grant the Storage Transfer Service's hidden service account permission to list and read objects in the source buckets. The integer 123456789012 is the GCP project's ID.
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-artifacts
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-ci-secure-files
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-dependency-proxy
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-lfs
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-mr-diffs
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-packages
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-pages
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-registry
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-terraform-state
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.legacyBucketReader,roles/storage.objectViewer gs://gitlab-bucket-uploads

# Create transfer jobs for each bucket, targeting a subdirectory in the backup bucket.
today=$(date +%F)
gcloud transfer jobs create gs://gitlab-bucket-artifacts/ gs://backup-bucket/$today/artifacts/ --name "$today-backup-artifacts"
gcloud transfer jobs create gs://gitlab-bucket-ci-secure-files/ gs://backup-bucket/$today/ci-secure-files/ --name "$today-backup-ci-secure-files"
gcloud transfer jobs create gs://gitlab-bucket-dependency-proxy/ gs://backup-bucket/$today/dependency-proxy/ --name "$today-backup-dependency-proxy"
gcloud transfer jobs create gs://gitlab-bucket-lfs/ gs://backup-bucket/$today/lfs/ --name "$today-backup-lfs"
gcloud transfer jobs create gs://gitlab-bucket-mr-diffs/ gs://backup-bucket/$today/mr-diffs/ --name "$today-backup-mr-diffs"
gcloud transfer jobs create gs://gitlab-bucket-packages/ gs://backup-bucket/$today/packages/ --name "$today-backup-packages"
gcloud transfer jobs create gs://gitlab-bucket-pages/ gs://backup-bucket/$today/pages/ --name "$today-backup-pages"
gcloud transfer jobs create gs://gitlab-bucket-registry/ gs://backup-bucket/$today/registry/ --name "$today-backup-registry"
gcloud transfer jobs create gs://gitlab-bucket-terraform-state/ gs://backup-bucket/$today/terraform-state/ --name "$today-backup-terraform-state"
gcloud transfer jobs create gs://gitlab-bucket-uploads/ gs://backup-bucket/$today/uploads/ --name "$today-backup-uploads"
    1. 이러한 전송 작업은 실행 후 자동으로 삭제되지 않습니다. 스크립트에서 오래된 작업 정리를 구현할 수 있습니다.
    2. 예시 스크립트는 이전 백업을 삭제하지 않습니다. 원하는 보존 정책에 따라 이전 백업 정리를 구현할 수 있습니다.

  4. 백업이 Cloud SQL 백업보다 같은 시간 또는 늦게 수행되도록 하여 데이터 불일치를 줄입니다.

Git 리포지터리 백업 구성#

Gitaly 서버 사이드 백업을 수행하기 위한 cron 작업을 설정합니다:

  1. 서버 사이드 백업 구성을 따라 모든 Gitaly 노드에서 Gitaly 서버 사이드 백업 대상을 구성합니다. 이 버킷은 리포지터리 데이터를 저장하기 위해 Gitaly에서만 사용됩니다.

  2. Gitaly가 이전에 구성된 지정된 오브젝트 스토리지 버킷에 모든 Git 리포지터리 데이터를 백업하는 동안, 백업 유틸리티 도구(gitlab-backup)는 추가 백업 데이터를 업로드합니다. 이 데이터에는 복원을 위한 필수 메타데이터가 포함된 tar 파일이 포함됩니다. 다른 백업과 동일한 버킷을 사용하거나 별도의 버킷을 사용할 수 있습니다. 이 백업 데이터가 원격(클라우드) 스토리지에 올바르게 업로드되도록 백업을 원격(클라우드) 스토리지에 업로드를 따라 업로드 버킷을 설정합니다.

  3. (선택 사항) 이 백업 데이터의 내구성을 강화하기 위해 이전에 구성된 버킷을 오브젝트 스토리지 데이터 백업에 추가하여 해당 오브젝트 스토어 제공업체로 백업합니다.

  4. Puma 또는 Sidekiq를 실행하는 노드인 GitLab Rails 노드에 SSH로 접속합니다.

  5. Git 데이터의 전체 백업을 수행합니다. REPOSITORIES_SERVER_SIDE 변수를 사용하고 PostgreSQL 데이터를 건너뜁니다:

    sudo gitlab-backup create REPOSITORIES_SERVER_SIDE=true SKIP=db

    이렇게 하면 Gitaly 노드가 Git 데이터와 일부 메타데이터를 원격 스토리지에 업로드합니다. 업로드, 아티팩트, LFS와 같은 블롭은 gitlab-backup 명령이 기본적으로 오브젝트 스토리지를 백업하지 않으므로 명시적으로 건너뛸 필요가 없습니다.

  6. 다음 단계에 필요한 백업의 백업 ID를 기록합니다. 예를 들어 백업 명령이 2024-02-22 02:17:47 UTC -- Backup 1708568263_2024_02_22_16.9.0-ce is done.을 출력하면 백업 ID는 1708568263_2024_02_22_16.9.0-ce입니다.

  7. 전체 백업이 Gitaly 백업 버킷과 일반 백업 버킷 모두에 데이터를 생성했는지 확인합니다.

  8. 백업 명령을 다시 실행하되, 이번에는 Git 리포지터리의 증분 백업과 백업 ID를 지정합니다. 이전 단계의 예시 ID를 사용하면 명령은:

    sudo gitlab-backup create REPOSITORIES_SERVER_SIDE=true SKIP=db INCREMENTAL=yes PREVIOUS_BACKUP=1708568263_2024_02_22_16.9.0-ce

    PREVIOUS_BACKUP의 값은 이 명령에서 사용되지 않지만 명령에서 필요합니다. 이 불필요한 요구사항을 제거하기 위한 이슈가 있습니다. 이슈 429141을 참조하십시오.

  9. 증분 백업이 성공했고 오브젝트 스토리지에 데이터가 추가되었는지 확인합니다.

  10. cron을 구성하여 일일 백업을 수행합니다. root 사용자의 crontab을 편집합니다:

    sudo su -
crontab -e

  11. 매달 1일에는 Git 리포지터리의 전체 백업을, 나머지 날에는 증분 백업을 수행하도록 매월 매일 오전 2시에 백업을 예약하는 다음 줄을 추가합니다. 이는 백업을 복원하는 데 필요한 증분 수를 제한하기 위한 것입니다:

    0 2 1 * * /opt/gitlab/bin/gitlab-backup create REPOSITORIES_SERVER_SIDE=true SKIP=db CRON=1
0 2 2-31 * * /opt/gitlab/bin/gitlab-backup create REPOSITORIES_SERVER_SIDE=true SKIP=db INCREMENTAL=yes PREVIOUS_BACKUP=1708568263_2024_02_22_16.9.0-ce CRON=1

  1. 서버 사이드 백업 구성을 따라 모든 Gitaly 노드에서 Gitaly 서버 사이드 백업 대상을 구성합니다. 이 버킷은 리포지터리 데이터를 저장하기 위해 Gitaly에서만 사용됩니다.

  2. Gitaly가 이전에 구성된 지정된 오브젝트 스토리지 버킷에 모든 Git 리포지터리 데이터를 백업하는 동안, 백업 유틸리티 도구(gitlab-backup)는 추가 백업 데이터를 업로드합니다. 이 데이터에는 복원을 위한 필수 메타데이터가 포함된 tar 파일이 포함됩니다. 다른 백업과 동일한 버킷을 사용하거나 별도의 버킷을 사용할 수 있습니다. 이 백업 데이터가 원격(클라우드) 스토리지에 올바르게 업로드되도록 백업을 원격(클라우드) 스토리지에 업로드를 따라 업로드 버킷을 설정합니다.

  3. (선택 사항) 이 백업 데이터의 내구성을 강화하기 위해 이전에 구성된 버킷을 오브젝트 스토리지 데이터 백업에 추가하여 해당 오브젝트 스토어 제공업체로 백업할 수 있습니다.

  4. Puma 또는 Sidekiq를 실행하는 노드인 GitLab Rails 노드에 SSH로 접속합니다.

  5. Git 데이터의 전체 백업을 수행합니다. REPOSITORIES_SERVER_SIDE 변수를 사용하고 다른 모든 데이터를 건너뜁니다:

    kubectl exec  -it -- backup-utility --repositories-server-side --skip db,builds,pages,registry,uploads,artifacts,lfs,packages,external_diffs,terraform_state,pages,ci_secure_files

    이렇게 하면 Gitaly 노드가 Git 데이터와 일부 메타데이터를 원격 스토리지에 업로드합니다. Toolbox 포함 도구를 참조하십시오.

  6. 전체 백업이 Gitaly 백업 버킷과 일반 백업 버킷 모두에 데이터를 생성했는지 확인합니다. 증분 리포지터리 백업은 서버 사이드 리포지터리 백업과 함께 backup-utility에서 지원되지 않습니다. charts 이슈 3421을 참조하십시오.

  7. cron을 구성하여 일일 백업을 수행합니다. 구체적으로 gitlab.toolbox.backups.cron.extraArgs를 다음을 포함하도록 설정합니다:

    --repositories-server-side --skip db --skip repositories --skip uploads --skip builds --skip artifacts --skip pages --skip lfs --skip terraform_state --skip registry --skip packages --skip ci_secure_files

구성 파일 백업 구성#

구성 및 비밀이 배포 외부에 정의된 다음 배포에 배포된 경우 백업 전략의 구현은 특정 설정 및 요구 사항에 따라 달라집니다. 예를 들어 여러 리전으로 복제하는 AWS Secret Manager에 비밀을 저장하고 비밀을 자동으로 백업하는 스크립트를 구성할 수 있습니다.

구성 및 비밀이 배포 내부에만 정의된 경우:

  1. 구성 파일 저장에서는 구성 및 비밀 파일을 추출하는 방법을 설명합니다.
  2. 이러한 파일은 별도의 더 제한적인 오브젝트 스토리지 계정에 업로드해야 합니다.

백업 복원#

GitLab 인스턴스의 백업을 복원합니다.

사전 요구사항#

백업을 복원하기 전에:

  1. 작동하는 대상 GitLab 인스턴스를 선택합니다.

  2. 대상 GitLab 인스턴스가 AWS 백업이 저장된 리전에 있는지 확인합니다.

  3. 대상 GitLab 인스턴스가 백업 데이터가 생성된 것과 정확히 동일한 버전과 유형(CE 또는 EE)의 GitLab을 사용하는지 확인합니다. 예를 들어 CE 15.1.4.

  4. 대상 GitLab 인스턴스에 백업된 비밀을 복원합니다.

  5. 대상 GitLab 인스턴스에 동일한 리포지터리 스토리지가 구성되어 있는지 확인합니다. 추가 스토리지는 괜찮습니다.

  6. 오브젝트 스토리지가 구성되어 있는지 확인합니다.

  7. 새 비밀 또는 구성을 사용하고 복원 중에 예상치 못한 구성 변경을 처리하지 않으려면:

    • 모든 노드의 Linux 패키지 설치:

      1. 대상 GitLab 인스턴스를 재구성합니다.
      2. 대상 GitLab 인스턴스를 재시작합니다.

    • Helm chart(Kubernetes) 설치:

      1. 모든 GitLab Linux 패키지 노드에서 다음을 실행합니다:

        sudo gitlab-ctl reconfigure
sudo gitlab-ctl start

      2. 차트를 배포하여 실행 중인 GitLab 인스턴스가 있는지 확인합니다. 다음 명령을 실행하여 Toolbox pod가 활성화되고 실행 중인지 확인합니다:

        kubectl get pods -lrelease=RELEASE_NAME,app=toolbox

      3. Webservice, Sidekiq 및 Toolbox pod를 다시 시작해야 합니다. 이러한 pod를 다시 시작하는 가장 안전한 방법은 다음을 실행하는 것입니다:

        kubectl delete pods -lapp=sidekiq,release=<helm release name>
kubectl delete pods -lapp=webservice,release=<helm release name>
kubectl delete pods -lapp=toolbox,release=<helm release name>

  8. 대상 GitLab 인스턴스가 여전히 작동하는지 확인합니다. 예를 들어:

  9. PostgreSQL 데이터베이스에 연결하는 GitLab 서비스를 중지합니다.

    • Puma 또는 Sidekiq를 실행하는 모든 노드의 Linux 패키지 설치:

      sudo gitlab-ctl stop

    • Helm chart(Kubernetes) 설치:

      1. 이후 재시작을 위해 데이터베이스 클라이언트의 현재 복제본 수를 기록합니다:

        kubectl get deploy -n <namespace> -lapp=sidekiq,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
kubectl get deploy -n <namespace> -lapp=webservice,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
kubectl get deploy -n <namespace> -lapp=prometheus,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'

      2. 복원 프로세스에 방해가 되는 잠금을 방지하기 위해 데이터베이스 클라이언트를 중지합니다:

        kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=0
kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=0
kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=0

오브젝트 스토리지 데이터 복원#

각 버킷은 AWS 내에서 별도의 백업으로 존재하며 각 백업은 기존 또는 새 버킷으로 복원할 수 있습니다.

  1. 버킷을 복원하려면 올바른 권한이 있는 IAM 권한이 필요합니다:

    • AWSBackupServiceRolePolicyForBackup
    • AWSBackupServiceRolePolicyForRestores
    • AWSBackupServiceRolePolicyForS3Restore
    • AWSBackupServiceRolePolicyForS3Backup

  2. 기존 버킷을 사용하는 경우 액세스 제어 목록이 활성화되어 있어야 합니다.

  3. 내장 도구를 사용하여 S3 버킷을 복원합니다.

  4. 복원 작업이 실행되는 동안 PostgreSQL 데이터 복원으로 진행할 수 있습니다.

  1. 스토리지 전송 서비스 작업을 생성하여 백업된 데이터를 GitLab 버킷으로 전송합니다.
  2. 전송 작업이 실행되는 동안 PostgreSQL 데이터 복원으로 진행할 수 있습니다.

PostgreSQL 데이터 복원#

  1. 내장 도구를 사용하여 AWS RDS 데이터베이스를 복원하면 새 RDS 인스턴스가 생성됩니다.

  2. 새 RDS 인스턴스에는 다른 엔드포인트가 있으므로 새 데이터베이스를 가리키도록 대상 GitLab 인스턴스를 재구성해야 합니다:

  3. 계속하기 전에 새 RDS 인스턴스가 생성되어 사용할 준비가 될 때까지 기다립니다.

  1. 내장 도구를 사용하여 Google Cloud SQL 데이터베이스를 복원합니다.

  2. 새 데이터베이스 인스턴스로 복원하는 경우 새 데이터베이스를 가리키도록 GitLab을 재구성합니다:

  3. 계속하기 전에 Cloud SQL 인스턴스가 사용할 준비가 될 때까지 기다립니다.

Git 리포지터리 복원#

먼저 오브젝트 스토리지 데이터 복원의 일환으로 이미 다음을 수행했어야 합니다:

  • Git 리포지터리의 Gitaly 서버 사이드 백업이 포함된 버킷을 복원합니다.
  • *_gitlab_backup.tar 파일이 포함된 버킷을 복원합니다.

  1. Puma 또는 Sidekiq를 실행하는 노드인 GitLab Rails 노드에 SSH로 접속합니다.

  2. 백업 버킷에서 복원한 PostgreSQL 및 오브젝트 스토리지 데이터와 타임스탬프를 기준으로 *_gitlab_backup.tar 파일을 선택합니다.

  3. /var/opt/gitlab/backups/에 tar 파일을 다운로드합니다.

  4. 복원하려는 백업의 ID를 지정하고 이름에서 _gitlab_backup.tar를 생략하여 백업을 복원합니다:

    # This command will overwrite the contents of your GitLab database!
sudo gitlab-backup restore BACKUP=11493107454_2018_04_25_10.6.4-ce SKIP=db

    백업 tar 파일과 설치된 GitLab 버전 간에 GitLab 버전 불일치가 있는 경우 복원 명령이 오류 메시지와 함께 중단됩니다. 올바른 GitLab 버전을 설치한 다음 다시 시도합니다.

  5. GitLab을 재구성, 시작하고 확인합니다:

    1. 모든 PostgreSQL 노드에서 다음을 실행합니다:

      sudo gitlab-ctl reconfigure

    2. 모든 Puma 또는 Sidekiq 노드에서 다음을 실행합니다:

      sudo gitlab-ctl start

    3. 하나의 Puma 또는 Sidekiq 노드에서 다음을 실행합니다:

      sudo gitlab-rake gitlab:check SANITIZE=true

  6. 데이터베이스 값을 현재 비밀을 사용하여 해독할 수 있는지 확인합니다. 특히 /etc/gitlab/gitlab-secrets.json이 복원된 경우 또는 다른 서버가 복원의 대상인 경우:

    Puma 또는 Sidekiq 노드에서 다음을 실행합니다:

    sudo gitlab-rake gitlab:doctor:secrets

  7. 추가적인 보증을 위해 업로드된 파일에 대한 무결성 검사를 수행할 수 있습니다:

    Puma 또는 Sidekiq 노드에서 다음을 실행합니다:

    sudo gitlab-rake gitlab:artifacts:check
sudo gitlab-rake gitlab:lfs:check
sudo gitlab-rake gitlab:uploads:check

    누락되거나 손상된 파일이 발견되더라도 백업 및 복원 프로세스가 실패했다는 의미는 아닙니다. 예를 들어 파일이 원본 GitLab 인스턴스에서 누락되거나 손상될 수 있습니다. 이전 백업을 교차 참조해야 할 수 있습니다. GitLab을 새 환경으로 마이그레이션하는 경우 원본 GitLab 인스턴스에서 동일한 검사를 실행하여 무결성 검사 결과가 기존 것인지 백업 및 복원 프로세스와 관련된 것인지 확인할 수 있습니다.

  1. toolbox pod에 SSH로 접속합니다.

  2. 백업 버킷에서 복원한 PostgreSQL 및 오브젝트 스토리지 데이터와 타임스탬프를 기준으로 *_gitlab_backup.tar 파일을 선택합니다.

  3. /var/opt/gitlab/backups/에 tar 파일을 다운로드합니다.

  4. 복원하려는 백업의 ID를 지정하고 이름에서 _gitlab_backup.tar를 생략하여 백업을 복원합니다:

    # This command will overwrite the contents of Gitaly!
kubectl exec  -it -- backup-utility --restore -t 11493107454_2018_04_25_10.6.4-ce --skip db,builds,pages,registry,uploads,artifacts,lfs,packages,external_diffs,terraform_state,pages,ci_secure_files

    백업 tar 파일과 설치된 GitLab 버전 간에 GitLab 버전 불일치가 있는 경우 복원 명령이 오류 메시지와 함께 중단됩니다. 올바른 GitLab 버전을 설치한 다음 다시 시도합니다.

  5. GitLab을 재시작하고 확인합니다:

    1. 사전 요구사항에서 기록된 복제본 수를 사용하여 중지된 배포를 시작합니다:

      kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=<original value>
kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=<original value>
kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=<original value>

    2. Toolbox pod에서 다음을 실행합니다:

      sudo gitlab-rake gitlab:check SANITIZE=true

  6. 데이터베이스 값을 현재 비밀을 사용하여 해독할 수 있는지 확인합니다. 특히 /etc/gitlab/gitlab-secrets.json이 복원된 경우 또는 다른 서버가 복원의 대상인 경우:

    Toolbox pod에서 다음을 실행합니다:

    sudo gitlab-rake gitlab:doctor:secrets

  7. 추가적인 보증을 위해 업로드된 파일에 대한 무결성 검사를 수행할 수 있습니다:

    이러한 명령은 모든 행을 반복하기 때문에 시간이 오래 걸릴 수 있습니다. 따라서 Toolbox pod가 아닌 GitLab Rails 노드에서 다음 명령을 실행합니다:

    sudo gitlab-rake gitlab:artifacts:check
sudo gitlab-rake gitlab:lfs:check
sudo gitlab-rake gitlab:uploads:check

    누락되거나 손상된 파일이 발견되더라도 백업 및 복원 프로세스가 실패했다는 의미는 아닙니다. 예를 들어 파일이 원본 GitLab 인스턴스에서 누락되거나 손상될 수 있습니다. 이전 백업을 교차 참조해야 할 수 있습니다. GitLab을 새 환경으로 마이그레이션하는 경우 원본 GitLab 인스턴스에서 동일한 검사를 실행하여 무결성 검사 결과가 기존 것인지 백업 및 복원 프로세스와 관련된 것인지 확인할 수 있습니다.

복원이 완료되어야 합니다.