• 매일 백업 구성
  • PostgreSQL 데이터 백업 구성
  • 객체 리포지터리 데이터 백업 구성
  • Git 리포지터리 백업 구성
  • 설정 파일 백업 구성
• 백업 복원
  • 전제 조건
  • 객체 스토리지 데이터 복원
  • PostgreSQL 데이터 복원
  • Git 리포지터리 복원

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

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

• 매일 백업 구성
• 지금 바로 백업 수행(계획됨)
• 백업 복원

이 문서는 다음 환경을 사용하는 경우를 대상으로 합니다:

• 리눅스 패키지(Omnibus) 및 클라우드 네이티브 하이브리드 참조 아키텍처 60 RPS/3,000 사용자 이상
• Amazon RDS의 PostgreSQL 데이터
• Amazon S3의 객체 리포지터리
• 모든 가능한 것을 저장하려면 객체 리포지터리에 저장하는데, 여기에는 blob 및 컨테이너 레지스트리가 포함됩니다.

매일 백업 구성

PostgreSQL 데이터 백업 구성

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

객체 리포지터리 데이터 백업 구성

객체 리포지터리 (NFS 아님)은 blob 및 컨테이너 레지스트리를 포함한 GitLab 데이터를 저장하기 위해 권장됩니다.

Git 리포지터리 백업 구성

만약 확장된 참조 아키텍처 또는 클라우드 네이티브 하이브리드를 사용하는 경우, GitLab Linux 패키지를 실행하는 VM을 프로비저닝합니다.

1. 8 vCPU와 7.2GB 메모리를 사용하는 VM을 시작합니다. 이 노드는 Git 리포지터리를 백업하는 데 사용됩니다. backup-utility에 Gitaly 서버 측 백업 지원의 추가는 issue 438393에서 제안되었으며, 이로써 VM을 프로비저닝할 필요가 없어집니다.
2. 노드를 귀사의 참조 아키텍처에 정의된 다른 GitLab Rails 노드로 구성합니다. 다른 GitLab Rails 노드와 마찬가지로 이 노드는 주 PostgreSQL 데이터베이스, Redis, 객체 리포지터리 및 Gitaly 클러스터에 액세스해야 합니다. 리눅스 패키지 설치를 위한 동등한 Helm 차트 값으로 일부 Helm 차트 값을 번역해야 할 수 있습니다. Praefect 노드는 Git 데이터를 백업하는 데 사용될 수 없습니다. 반드시 GitLab Rails 노드이어야 합니다.

3. 이 노드에서 GitLab 애플리케이션이 작동 중이 아닌지 확인하기 위해 대부분의 서비스를 비활성화하여야 합니다:

   1. 다음 서비스가 비활성화되도록 /etc/gitlab/gitlab.rb를 편집합니다. roles(['application_role'])은 Redis, PostgreSQL 및 Consul을 비활성화하며 이는 참조 아키텍처 Rails 노드 정의의 기초입니다.

      roles(['application_role'])
      gitlab_workhorse['enable'] = false
      puma['enable'] = false
      sidekiq['enable'] = false
      gitlab_kas['enable'] = false
      gitaly['enable'] = false
      prometheus_monitoring['enable'] = false
      

   2. GitLab을 재구성합니다:

      sudo gitlab-ctl reconfigure
      

   3. 유일하게 남아 있는 서비스는 logrotate여야 합니다. logrotate가 유일하게 남아 있는지 확인하려면 다음을 실행합니다:

      gitlab-ctl status
      

   이슈 6823에 이 요구 사항을 충족하는 리눅스 패키지에 역할을 추가하는 제안이 있습니다.

Git 리포지터리를 백업하려면:

1. 모든 Gitaly 노드에 서버 측 백업 대상 구성합니다.
2. 객체 리포지터리 데이터의 백업을 추가합니다.

3. Git 데이터의 완전한 백업을 수행합니다. REPOSITORIES_SERVER_SIDE 변수를 사용하고 PostgreSQL 데이터를 건너뛰십시오:

   sudo gitlab-backup create REPOSITORIES_SERVER_SIDE=true SKIP=db
   

   이렇게 하면 Gitaly 노드가 Git 데이터 및 일부 메타데이터를 원격 리포지터리에 업로드합니다. 업로드, 아티팩트 및 LFS와 같은 블롭은 명시적으로 건너뛰지 않아도 됩니다. 왜냐하면 gitlab-backup 명령은 기본적으로 객체 리포지터리를 백업하지 않기 때문입니다.

4. 백업의 백업 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입니다.
5. 완전한 백업이 백업 버킷에 데이터를 생성했는지 확인합니다.

6. 백업 명령을 다시 실행하여 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을 참조하십시오.

7. 증분 백업이 성공적으로 수행되었는지 확인하고 객체 리포지터리에 데이터가 추가되었는지 확인합니다.

8. 크론을 구성하여 매일 백업하도록 설정합니다. root 사용자의 crontab을 수정합니다:

   sudo su -
   crontab -e
   

9. 거기에 매월 매일 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
   

설정 파일 백업 구성

만약 구성 및 비밀을 배포 외부에 정의하고 그 후 배포한다면, 백업 전략의 실행은 특정 설정 및 요구 사항에 따라 달라집니다. 예를 들어 AWS Secret Manager에서 비밀을 저장하고 여러 지역으로 복제하고 비밀을 자동으로 백업하기 위한 스크립트를 구성할 수 있습니다.

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

1. 구성 파일 저장에 구성 및 비밀 파일을 추출하는 방법에 대해 설명합니다.
2. 이러한 파일은 별도의, 더 제한된 객체 리포지터리 계정에 업로드해야 합니다.

백업 복원

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

전제 조건

백업을 복원하기 전에:

1. 작동 중인 대상 GitLab 인스턴스를 선택합니다.
2. 대상 GitLab 인스턴스가 AWS 백업이 저장된 지역에 있는지 확인합니다.
3. 백업 데이터가 생성된 GitLab의 정확히 동일한 버전 및 유형 (CE 또는 EE)의 인스턴스를 사용하는지 확인합니다. 예를 들어, CE 15.1.4.
4. 백업된 비밀을 대상 GitLab 인스턴스로 복원합니다.
5. 대상 GitLab 인스턴스에 동일한 리포지터리 스토리지가 구성되어 있는지 확인합니다. 추가 리포지터리는 괜찮습니다.
6. 백업된 GitLab 인스턴스에 객체 리포지터리에 저장된 블롭이 있다면, 해당 종류의 블롭을 위해 객체 리포지터리가 구성되어 있는지 확인합니다.
7. 백업된 GitLab 인스턴스에 파일 시스템에 저장된 블롭이 있다면, NFS가 구성되어 있는지 확인합니다.

8. 새로운 비밀이나 구성을 사용하고 복원 중에 예상치 못한 구성 변경을 피하기 위해:

   • 모든 노드에서 리눅스 패키지 설치:
     1. 대상 GitLab 인스턴스를 다시 구성합니다.
     2. 대상 GitLab 인스턴스를 다시 시작합니다.

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

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

   • health check endpoints로 요청을 수행합니다.
   • Run GitLab check Rake tasks을 실행합니다.

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

    • 모든 노드에서 Puma 또는 Sidekiq를 실행하는 리눅스 패키지 설치:

      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
         

객체 스토리지 데이터 복원

PostgreSQL 데이터 복원

Git 리포지터리 복원

복원할 노드 선택 또는 생성:

• Linux 패키지 설치의 경우 보통 Puma나 Sidekiq을 실행하는 노드인 Rails 노드를 선택합니다.

• Helm 차트(Kubernetes) 설치의 경우 Git 리포지터리 백업 노드를 구성하지 않았다면 다음을 수행하세요:

  1. 8 vCPU 및 7.2 GB 메모리로 VM을 가동시킵니다. 이 노드는 Praefect 노드가 Git 데이터를 백업하는 데 사용할 수 없기 때문에 Git 리포지터리를 백업하고 복원하는 데 사용됩니다.
  2. 노드를 참조 아키텍처에 정의된 대로 또 다른 GitLab Rails 노드로 구성합니다. 다른 GitLab Rails 노드와 마찬가지로 이 노드는 주 PostgreSQL 데이터베이스 및 Gitaly 클러스터에 액세스해야 합니다.
  3. 백업된 암호를 대상 GitLab에 복원합니다.

Git 리포지터리를 복원하려면:

1. 노드에는 Git 리포지터리의 .tar 파일과 해당 파일의 추출된 데이터를 저장할 충분한 추가 스토리지가 있어야 합니다.
2. GitLab Rails 노드에 SSH로 연결합니다.
3. 객체 스토리지 데이터 복원의 일환으로 GitLab 백업 .tar 파일이 들어있는 버킷을 복원해야 합니다.

4. 백업 디렉터리에 있는 gitlab.rb 구성의 gitlab_rails['backup_path']에서 백업 .tar 파일을 다운로드합니다. 기본값은 /var/opt/gitlab/backups입니다. 백업 파일의 소유자는 git 사용자여야 합니다.

   sudo cp 11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar /var/opt/gitlab/backups/
   sudo chown git:git /var/opt/gitlab/backups/11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar
   

5. 복구할 백업을 지정하여 백업을 복원합니다:

   복원 명령은 추가 매개변수가 필요할 수 있습니다. 동일한 성능적 이유거나 Patroni 클러스터를 사용할 때 PGBouncer를 사용하는 설치에 대해

   # 이 명령은 GitLab 데이터베이스의 내용을 덮어쓸 수 있습니다!
   # 참고: 백업파일 이름에서 "_gitlab_backup.tar"이 생략됐습니다
   sudo gitlab-backup restore BACKUP=11493107454_2018_04_25_10.6.4-ce
   

   백업 tar 파일과 설치된 GitLab 버전간의 불일치가 있으면 복원 명령이 오류 메시지와 함께 중지됩니다. 올바른 GitLab 버전을 설치한 다음 다시 시도하세요.

6. GitLab을 다시 시작하고 확인해 주세요:

   • Linux 패키지 설치:

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

        sudo gitlab-ctl restart
        

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

        sudo gitlab-rake gitlab:check SANITIZE=true
        

   • Helm 차트(Kubernetes) 설치:

     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
        

7. 특히 /etc/gitlab/gitlab-secrets.json가 복원되었거나 복원 대상 서버가 다른 경우 데이터베이스 값이 해독될 수 있는지 확인합니다:

   • Linux 패키지 설치의 경우 Puma 또는 Sidekiq 노드에서 다음을 실행합니다:

     sudo gitlab-rake gitlab:doctor:secrets
     

   • Helm 차트(Kubernetes) 설치의 경우 Toolbox pod에서 다음을 실행합니다:

     sudo gitlab-rake gitlab:doctor:secrets
     

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

   • Linux 패키지 설치의 경우 Puma 또는 Sidekiq 노드에서 다음을 실행합니다:

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

   • Helm 차트(Kubernetes) 설치의 경우 모든 행을 반복하기 때문에 실행 시간이 오래 걸릴 수 있으므로 이러한 명령은 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 인스턴스에서 동일한 확인을 실행하여 무결성 검사 결과가 기존에 있던지 백업 및 복원 프로세스와 관련된 것인지 확인할 수 있습니다.

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