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

Tier: Free, Premium, Ultimate Offering: Self-managed

이 문서는 다음을 설명합니다:

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

일일 백업 구성하기

PostgreSQL 데이터 백업 구성하기

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

AWS
  1. AWS Backup 구성하기하여 RDS (및 S3) 데이터를 백업하십시오. 최대 보호를 위해 지속적인 백업 및 스냅샷 백업 모두 구성하세요.
  2. AWS Backup에서 백업을 별도의 지역으로 복사하도록 구성하세요. AWS가 백업을 수행할 때, 백업은 저장된 지역에서만 복원될 수 있습니다.
  3. AWS Backup이 최소한 한 번 이상 예약된 백업을 수행한 후, 필요에 따라 온디맨드 백업을 생성하세요.
Google

Google Cloud SQL 데이터의 자동 일일 백업을 예약하세요.
일일 백업은 1년 동안 유지될 수 있습니다, 트랜잭션 로그는 기본적으로 7일 동안 유지됩니다.

객체 저장소 데이터 백업 구성하기

객체 저장소, (NFS가 아님)는 GitLab 데이터를 저장하는 데 권장됩니다, 블롭 및 컨테이너 레지스트리를 포함합니다.

AWS

AWS Backup을 구성하여 S3 데이터를 백업합니다. 이는 PostgreSQL 데이터의 백업 구성하기와 동시에 수행할 수 있습니다.

Google
  1. GCS에 백업 버킷 생성하기.
  2. 스토리지 전송 서비스 작업 생성하기하여 각 GitLab 객체 저장소 버킷을 백업 버킷으로 복사합니다. 이 작업들은 한 번만 생성할 수 있으며, 일일 실행을 예약할 수 있습니다. 그러나 이는 새로운 데이터와 오래된 데이터가 혼합되어, GitLab에서 삭제된 파일도 백업에 남아 있게 됩니다. 이는 복원 후 스토리지를 낭비하지만, 그 외에는 문제가 되지 않습니다. 이 파일들은 GitLab 데이터베이스에 존재하지 않기 때문에 GitLab 사용자에게는 접근할 수 없습니다. 복원 후 이 고아 파일들을 제거할 수 있습니다, 하지만 이 정리 Rake 작업은 파일의 하위 집합에 대해서만 작동합니다.
    1. When to overwrite에서 Never를 선택하세요. GitLab 객체 저장된 파일은 불변 상태로 의도되어 있습니다. 이 선택은 악의적인 행위자가 GitLab 파일을 변형하는 데 성공했을 경우 도움이 될 수 있습니다.
    2. When to delete에서 Never를 선택하세요. 백업 버킷을 소스와 동기화하면, 소스에서 파일이 실수로 또는 악의적으로 삭제되면 복구할 수 없습니다.

  3. 또는 객체 저장소를 각 날짜별로 구분된 버킷이나 하위 디렉토리에 백업할 수도 있습니다. 이는 복원 후 고아 파일 문제를 피하고 필요한 경우 파일 버전의 백업을 지원합니다. 하지만 이는 백업 스토리지 비용을 크게 증가시킵니다. 이는 Cloud Scheduler에 의해 트리거되는 Cloud Function이나 크론잡에서 실행되는 스크립트를 통해 수행할 수 있습니다. 부분적인 예는 다음과 같습니다:

    # 매 명령어에서 GCP 프로젝트를 지정하지 않도록 설정  
gcloud config set project example-gcp-project-name  

# 스토리지 전송 서비스의 숨겨진 서비스 계정에 백업 버킷에 쓸 수 있는 권한 부여. 정수 123456789012는 GCP 프로젝트 ID입니다.  
gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.objectAdmin gs://backup-bucket  

# 스토리지 전송 서비스의 숨겨진 서비스 계정에 소스 버킷의 객체를 나열하고 읽을 수 있는 권한 부여. 정수 123456789012는 GCP 프로젝트 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  

# 각 버킷에 대해 전송 작업을 생성하여 백업 버킷의 하위 디렉토리를 대상으로 설정합니다.  
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 서버 측 백업을 수행하도록 cronjob을 설정하세요:

리눅스 패키지 (Omnibus)
  1. 모든 Gitaly 노드에 서버 측 백업 대상을 구성합니다.
  2. 원격(클라우드) 저장소에 백업 업로드를 구성합니다. Gitaly가 모든 Git 데이터를 자체 객체 저장소 버킷에 백업하더라도, gitlab-backup 명령은 백업 메타데이터를 포함하는 tar 파일도 생성합니다. 이 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와 같은 Blob은 명시적으로 건너뛸 필요가 없습니다. 왜냐하면 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. 거기에 매달 매일 2 AM에 백업을 예약하기 위해 다음 행을 추가하세요. 백업 복구에 필요한 증분 수를 제한하기 위해, 매월 첫 번째 날에 Git 리포지토리의 전체 백업을 수행하고, 나머지 날들은 증분 백업을 수행합니다:

    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
헬름 차트 (Kubernetes)
  1. 모든 Gitaly 노드에 서버 측 백업 대상을 구성합니다.
  2. 백업 유틸리티에 대한 객체 저장소 버킷을 구성합니다. Gitaly가 모든 Git 데이터를 자체 객체 저장소 버킷에 백업하더라도, backup-utility 명령은 백업 메타데이터를 포함하는 tar 파일도 생성합니다. 이 tar 파일은 복구 명령에 필요합니다.
  3. 두 버킷 모두를 객체 저장소 데이터의 백업에 추가하세요.

  4. Git 데이터의 전체 백업을 수행하세요. --repositories-server-side 옵션을 사용하고, 모든 다른 데이터는 건너뜁니다:

    kubectl exec <Toolbox pod name> -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 데이터 및 일부 메타데이터를 원격 저장소에 업로드합니다. 툴박스 포함 도구를 참조하세요.

  5. 전체 백업이 Gitaly 백업 버킷과 일반 백업 버킷 모두에 데이터를 만들었는지 확인합니다. 증분 리포지토리 백업은 서버 측 리포지토리 백업과 함께 backup-utility에서 지원되지 않습니다. 차트 문제 3421를 참조하세요.

  6. 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 차트(Kubernetes) 설치:

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

        sudo gitlab-ctl reconfigure
sudo gitlab-ctl start

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

        kubectl get pods -lrelease=RELEASE_NAME,app=toolbox

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

        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 차트 (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

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

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

    • AWSBackupServiceRolePolicyForBackup
    • AWSBackupServiceRolePolicyForRestores
    • AWSBackupServiceRolePolicyForS3Restore
    • AWSBackupServiceRolePolicyForS3Backup

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

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

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

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

PostgreSQL 데이터 복원

AWS

  1. 내장 도구를 사용하여 AWS RDS 데이터베이스를 복원합니다, 이는 새로운 RDS 인스턴스를 생성합니다.

  2. 새로운 RDS 인스턴스가 다른 엔드포인트를 갖기 때문에, 새 데이터베이스를 가리키도록 GitLab 인스턴스를 재구성해야 합니다:

  3. 계속 진행하기 전에 새로운 RDS 인스턴스가 생성되고 사용할 준비가 될 때까지 기다리세요.

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

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

  3. 계속 진행하기 전에 Cloud SQL 인스턴스가 사용할 준비가 될 때까지 기다리세요.

Git 리포지토리 복원

먼저, 오브젝트 저장소 데이터 복원의 일환으로 이미 다음의 작업을 수행했어야 합니다:

  • Git 리포지토리의 Gitaly 서버 측 백업이 포함된 버킷을 복원했습니다.
  • *_gitlab_backup.tar 파일이 포함된 버킷을 복원했습니다.
Linux 패키지 (Omnibus)

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

  2. 백업 버킷에서 PostgreSQL 및 오브젝트 저장소 데이터와 정렬된 타임스탬프 기준으로 *_gitlab_backup.tar 파일을 선택합니다.

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

  4. 복원을 수행하되, 복원할 백업의 ID를 지정하고 이름에서 _gitlab_backup.tar를 생략합니다:

    # 이 명령은 GitLab 데이터베이스의 내용을 덮어씁니다!
sudo gitlab-backup restore BACKUP=11493107454_2018_04_25_10.6.4-ce SKIP=db

    백업 tar 파일과 설치된 GitLab 버전 간의 불일치가 있을 경우, 복원 명령이 오류 메시지와 함께 중단됩니다.

    올바른 GitLab 버전을 설치한 후 다시 시도하세요.

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

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

      sudo gitlab-ctl restart

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

      sudo gitlab-rake gitlab:check SANITIZE=true

  6. 데이터베이스 값이 복호화될 수 있는지 확인합니다 특히 /etc/gitlab/gitlab-secrets.json이 복원되었거나 다른 서버가 복원의 대상으로 지정된 경우:

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

   sudo gitlab-rake gitlab:doctor:secrets

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

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

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

    누락되거나 손상된 파일이 발견되었을 경우, 항상 백업 및 복원 과정이 실패했다는 의미는 아닙니다.

    예를 들어, 해당 파일이 소스 GitLab 인스턴스에서 누락되거나 손상되었을 수 있습니다. 이전 백업을 교차 확인해야 할 수도 있습니다.

    GitLab을 새로운 환경으로 마이그레이션하는 경우, 소스 GitLab 인스턴스에서 동일한 검사를 실행하여 무결성 검사 결과가 기존의 것인지 아니면 백업 및 복원 과정과 관련된 것인지 확인할 수 있습니다.

Helm 차트 (Kubernetes)

  1. 툴박스 팟에 SSH로 접속합니다.

  2. 백업 버킷에서 PostgreSQL 및 오브젝트 저장소 데이터와 정렬된 타임스탬프 기준으로 *_gitlab_backup.tar 파일을 선택합니다.

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

  4. 복원을 수행하되, 복원할 백업의 ID를 지정하고 이름에서 _gitlab_backup.tar를 생략합니다:

    # 이 명령은 Gitaly의 내용을 덮어씁니다!
kubectl exec <Toolbox pod name> -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 버전을 설치한 후 다시 시도하세요.

  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. 툴박스 팟에서 다음을 실행합니다:

      sudo gitlab-rake gitlab:check SANITIZE=true

  6. 데이터베이스 값이 복호화될 수 있는지 확인합니다 특히 /etc/gitlab/gitlab-secrets.json이 복원되었거나 다른 서버가 복원의 대상으로 지정된 경우:

툴박스 팟에서 다음을 실행합니다:

   sudo gitlab-rake gitlab:doctor:secrets

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

    이러한 명령은 모든 행을 반복 처리하기 때문에 오랜 시간이 걸릴 수 있습니다. 따라서 툴박스 팟 대신 GitLab Rails 노드에서 다음 명령을 실행합니다:

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

    누락되거나 손상된 파일이 발견되었을 경우, 항상 백업 및 복원 과정이 실패했다는 의미는 아닙니다.

    예를 들어, 해당 파일이 소스 GitLab 인스턴스에서 누락되거나 손상되었을 수 있습니다. 이전 백업을 교차 확인해야 할 수도 있습니다.

    GitLab을 새로운 환경으로 마이그레이션하는 경우, 소스 GitLab 인스턴스에서 동일한 검사를 실행하여 무결성 검사 결과가 기존의 것인지 아니면 백업 및 복원 과정과 관련된 것인지 확인할 수 있습니다.

복원이 완료되었습니다.