InfoGrab DocsInfoGrab 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. When to overwrite에서는 Never를 선택합니다. GitLab이 오브젝트 스토리지에 저장한 파일은 변경 불가능한 것으로 취급합니다. 악의적인 행위자가 GitLab 파일을 변조하는 데 성공한 경우 이 선택이 도움이 될 수 있습니다.
    2. When to delete에서는 Never를 선택합니다. 백업 버킷을 소스와 동기화하면, 소스에서 파일이 실수로 또는 악의적으로 삭제된 경우 복구할 수 없습니다.

  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 데이터와 일부 메타데이터를 원격 스토리지에 업로드합니다. gitlab-backup 명령은 기본적으로 오브젝트 스토리지를 백업하지 않으므로 업로드, 아티팩트, LFS 같은 블롭은 명시적으로 건너뛰지 않아도 됩니다.

  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시에 백업을 예약합니다. 백업 복원에 필요한 증분 수를 제한하기 위해 매월 1일에는 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

  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 인스턴스가 백업 데이터를 생성한 GitLab과 정확히 같은 버전과 유형(CE 또는 EE)을 사용하는지 확인합니다. 예를 들어 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 버전을 설치한 다음 다시 시도합니다.

  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 버전을 설치한 다음 다시 시도합니다.

  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 인스턴스에서 같은 검사를 실행해 무결성 검사 결과가 기존부터 있던 것인지 백업 및 복원 프로세스와 관련된 것인지 판단할 수 있습니다.

이것으로 복원이 완료됩니다.

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

GitLab v19.4
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. When to overwrite에서는 Never를 선택합니다. GitLab이 오브젝트 스토리지에 저장한 파일은 변경 불가능한 것으로 취급합니다. 악의적인 행위자가 GitLab 파일을 변조하는 데 성공한 경우 이 선택이 도움이 될 수 있습니다.
    2. When to delete에서는 Never를 선택합니다. 백업 버킷을 소스와 동기화하면, 소스에서 파일이 실수로 또는 악의적으로 삭제된 경우 복구할 수 없습니다.

  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 데이터와 일부 메타데이터를 원격 스토리지에 업로드합니다. gitlab-backup 명령은 기본적으로 오브젝트 스토리지를 백업하지 않으므로 업로드, 아티팩트, LFS 같은 블롭은 명시적으로 건너뛰지 않아도 됩니다.

  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시에 백업을 예약합니다. 백업 복원에 필요한 증분 수를 제한하기 위해 매월 1일에는 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

  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 인스턴스가 백업 데이터를 생성한 GitLab과 정확히 같은 버전과 유형(CE 또는 EE)을 사용하는지 확인합니다. 예를 들어 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 버전을 설치한 다음 다시 시도합니다.

  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 버전을 설치한 다음 다시 시도합니다.

  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 인스턴스에서 같은 검사를 실행해 무결성 검사 결과가 기존부터 있던 것인지 백업 및 복원 프로세스와 관련된 것인지 판단할 수 있습니다.

이것으로 복원이 완료됩니다.