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

1. AWS 백업을 구성하여 RDS(및 S3) 데이터를 백업합니다. 최대 보호를 위해 연속 백업 및 스냅샷 백업을 구성합니다.
2. AWS 백업을 다른 지역으로 복사하도록 구성하십시오. AWS가 백업을 수행하면 백업은 해당 지역에서만 복원할 수 있습니다.
3. AWS 백업이 최소한 하나의 예약된 백업을 실행한 후에, 필요에 따라 온디맨드 백업을 생성할 수 있습니다.

Google Cloud SQL 데이터의 자동 매일 백업을 예약합니다. 매일 백업은 최대 1년까지 유지될 수 있으며, 기본적으로 트랜잭션 로그는 복구 지점 복원을 위해 7일간 유지됩니다.

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

1. GCS에 백업 버킷을 생성합니다.
2. 각 GitLab 객체 저장소 버킷을 백업 버킷으로 복사하는 Storage Transfer Service 작업을 생성합니다. 이러한 작업은 한 번 생성한 후 매일 실행하도록 예약할 수 있습니다. 그러나 이는 GitLab에서 삭제된 파일이 백업에 그대로 남아 저장 공간을 낭비하게 됩니다. 그러나 GitLab 사용자는 데이터베이스에 존재하지 않기 때문에 해당 파일에 액세스할 수 없게 됩니다. 복원 후 이러한 오작동 파일 중 일부를 삭제할 수 있지만, 이 클린업 Rake 작업은 파일의 일부에만 작용합니다.
   1. 덮어쓸 때에 대해 절대로를 선택합니다. GitLab의 객체 저장된 파일은 변경할 수 없도록 의도되었습니다. 이 선택은 GitLab 파일을 변조한 악의적인 사용자의 경우에 도움이 될 수 있습니다.
   2. 삭제할 때에 대해 절대로를 선택합니다. 백업 버킷을 소스로 동기화하는 경우 소스에서 파일이 실수로나 악의적으로 삭제된 경우 복구할 수 없습니다.

3. 또는 필요에 따라 객체 저장소를 일별로 분리된 버킷이나 하위 디렉터리로 백업하는 것이 가능합니다. 이는 복원 후 오작동 파일 문제를 피하고 필요한 경우 파일 버전을 백업하는 것을 지원합니다. 그러나 이는 백업 저장 비용이 크게 증가시키게 됩니다. Cloud Scheduler에 의해 트리거된 Cloud Function 또는 cronjob에 의해 스크립트를 실행함으로써 수행할 수 있습니다. 부분적인 예시:

   # GCP 프로젝트 설정하여 모든 명령어에서 프로젝트를 지정하지 않아도됨
   gcloud config set project example-gcp-project-name
   
   # Storage Transfer Service의 숨겨진 서비스 계정이 백업 버킷에 기록할 수 있도록 권한을 부여합니다. 정수 123456789012은 GCP 프로젝트의 ID입니다.
   gsutil iam ch serviceAccount:project-123456789012@storage-transfer-service.iam.gserviceaccount.com:roles/storage.objectAdmin gs://backup-bucket
   
   # Storage Transfer Service의 숨겨진 서비스 계정이 소스 버킷의 객체를 나열하고 읽을 수 있는 권한을 부여합니다. 정수 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 백업 이후나 동일한 시간 이후에 수행되도록하여 데이터 불일치를 줄입니다.

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와 같은 블롭들은 명시적으로 건너뛸 필요가 없습니다. 왜냐하면 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 값을이 명령어는 사용되지 않지만 명령에는 필요합니다. 이 불필요한 요구 사항을 제거하기 위한 문제가 있습니다. issue 429141를 참조하세요.

9. 증분 백업이 성공적으로 이루어지고 객체 저장소에 데이터가 추가되었는지 확인하세요.

10. 매일 백업을 만들도록 cron을 구성합니다. root 사용자의 crontab을 편집합니다:

    sudo su -
    crontab -e
    

11. 거기에 다음 줄을 추가하여 매월 1일에 매일 새벽 2시에 백업을 스케줄링합니다. 백업 복원에 필요한 증분의 수를 제한하기 위해, 매월 첫째 날에는 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 노드에서 서버 측 백업 대상을 구성합니다.
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 데이터와 일부 메타데이터를 원격 저장소에 업로드하도록 합니다. 포함된 Toolbox 도구를 참조하십시오.

5. 전체 백업이 Gitaly 백업 버킷과 일반 백업 버킷에 데이터를 생성했는지 확인하세요. 서버 측 리포지토리 백업에서는 증분 리포지토리 백업을 지원하지 않습니다. charts issue 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 내에서 별도의 백업으로 존재하며, 각 백업은 기존 버킷 또는 새 버킷으로 복원할 수 있습니다.

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

   • AWSBackupServiceRolePolicyForBackup
   • AWSBackupServiceRolePolicyForRestores
   • AWSBackupServiceRolePolicyForS3Restore
   • AWSBackupServiceRolePolicyForS3Backup
2. 기존 버킷을 사용하는 경우 접근 제어 목록을 활성화해야 합니다.
3. 내장된 도구를 사용하여 S3 버킷을 복원합니다.
4. 복원 작업이 실행 중일 때 PostgreSQL 데이터를 복원으로 이동할 수 있습니다.

1. 저장소 전송 서비스 작업을 생성하여 백업된 데이터를 GitLab 버킷으로 전송합니다.
2. 전송 작업이 실행 중일 때 PostgreSQL 데이터를 복원으로 이동할 수 있습니다.

1. 내장된 도구를 사용하여 AWS RDS 데이터베이스를 복원합니다. 이 작업은 새 RDS 인스턴스를 만듭니다.

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

   • Linux 패키지 설치의 경우 패키지되지 않은 PostgreSQL 데이터베이스 관리 서버 사용를 따릅니다.

   • Helm 차트(Kubernetes) 설치의 경우 외부 데이터베이스로 GitLab 차트 구성를 따릅니다.

3. 다음 단계로 진행하기 전에 새 RDS 인스턴스가 생성되어 사용할 수 있을 때까지 기다리세요.

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

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

   • Linux 패키지 설치의 경우 패키지되지 않은 PostgreSQL 데이터베이스 관리 서버 사용를 따릅니다.

   • Helm 차트(Kubernetes) 설치의 경우 외부 데이터베이스로 GitLab 차트 구성를 따릅니다.

3. 다음 단계로 진행하기 전에 Cloud SQL 인스턴스를 사용할 수 있을 때까지 기다리세요.

1. Puma 또는 Sidekiq를 실행하는 GitLab Rails 노드에 SSH로 연결합니다.
2. 복원한 백업 버킷에서 PostgreSQL 및 객체 저장소 데이터와 일치하는 타임스탬프를 기반으로 *_gitlab_backup.tar 파일을 선택합니다.
3. /var/opt/gitlab/backups/에 백업 파일을 다운로드합니다.

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
   

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 팟에 SSH로 연결합니다.
2. 복원한 백업 버킷에서 PostgreSQL 및 객체 저장소 데이터와 일치하는 타임스탬프를 기반으로 *_gitlab_backup.tar 파일을 선택합니다.
3. /var/opt/gitlab/backups/에 백업 파일을 다운로드합니다.

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. Prerequisites에서 확인한 복제본 수를 사용하여 중지된 배포를 시작합니다:

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

      sudo gitlab-rake gitlab:check SANITIZE=true
      

6. 특히 /etc/gitlab/gitlab-secrets.json이 복원되었을 경우나 다른 서버가 복원 대상인 경우, 데이터베이스 값이 복호화될 수 있는지 확인하세요:

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

   sudo gitlab-rake gitlab:doctor:secrets
   

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

   이러한 명령은 모든 행을 반복하기 때문에 수행 시간이 오래 걸릴 수 있으므로, Toolbox 팟이 아닌 GitLab Rails 노드에서 다음 명령을 실행합니다:

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

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