인스턴스에서 백업 구성

GitHub Enterprise Server Backup Utilities 정보

GitHub Enterprise Server Backup Utilities은(는) 별도의 호스트에 설치하는 백업 시스템으로, 보안 SSH 네트워크 연결을 통해 정기적으로 GitHub Enterprise Server 인스턴스의 백업 스냅샷을 만듭니다. 스냅샷을 사용하여 백업 호스트에서 기존 GitHub Enterprise Server 인스턴스를 이전 상태로 복원할 수 있습니다.

마지막 스냅샷 이후 추가된 데이터만 네트워크를 통해 전송되고 추가 물리적 스토리지 공간을 차지합니다. 성능 영향을 최소화하기 위해 백업은 가장 낮은 CPU/IO 우선 순위에 따라 온라인으로 수행됩니다. 백업을 수행하기 위해 유지 관리 기간을 예약할 필요는 없습니다.

GitHub Enterprise Server Backup Utilities의 주요 릴리스 및 버전 번호는 GitHub Enterprise Server의 기능 릴리스와 일치합니다. 두 제품 모두에 대해 최신 버전 4개를 지원합니다. 자세한 내용은 "GitHub Enterprise 서버 릴리스"을(를) 참조하세요.

기능, 요구 사항 및 고급 사용에 대한 자세한 내용은 GitHub Enterprise Server Backup Utilities 프로젝트 설명서의 GitHub Enterprise Server Backup Utilities 추가 정보를 참조하세요.

필수 조건

GitHub Enterprise Server Backup Utilities을(를) 사용하려면 GitHub Enterprise Server 인스턴스과(와)는 별도로 호스트 시스템이 있어야 합니다. 시스템을 구성하는 방법에 대한 자세한 내용은 ggithub/backup-utils 리포지토리의 요구 사항을 참조하세요.

GitHub Enterprise Server Backup Utilities를 기존 환경에 통합해 중요한 데이터를 장기적으로 영구 저장할 수도 있습니다.

백업 호스트와 GitHub Enterprise Server 인스턴스은(는) 지리적으로 서로 멀리 떨어져 있는 것이 좋습니다. 이렇게 하면 주 사이트에서 대규모 재해 또는 네트워크 중단이 발생할 경우 백업을 복구할 수 있습니다.

물리적 스토리지 요구 사항은 Git 리포지토리 디스크 사용량 및 예상 증가 패턴에 따라 달라집니다.

하드웨어	권장
vCPU	4
메모리	8GB
스토리지	주 인스턴스의 할당된 스토리지의 5배

사용자 활동 및 선택한 통합과 같은 사용량에 따라 더 많은 리소스가 필요할 수 있습니다.

자세한 내용은 GitHub Enterprise Server Backup Utilities 프로젝트 설명서의 GitHub Enterprise Server Backup Utilities 요구 사항을 참조하세요.

GitHub Enterprise Server Backup Utilities 설치

백업 호스트에 GitHub Enterprise Server Backup Utilities을(를) 설치하려면 GitHub Enterprise Server의 버전과 호환되는 github/backup-utils 리포지토리에서 최신 버전의 GitHub Enterprise Server Backup Utilities을(를) 다운로드합니다. 예를 들어 GitHub Enterprise Server의 버전 3.8.4를 실행하는 경우 3.10 시리즈에서 최신 버전의 GitHub Enterprise Server Backup Utilities을(를) 다운로드합니다. GitHub Enterprise Server Backup Utilities의 모든 버전이 2 버전과 호환되므로 GitHub Enterprise Server Backup Utilities 3.10 시리즈를 사용하여 버전 3.8, 3.9 또는 3.10을 실행하는 GitHub Enterprise Server 인스턴스를 백업하고 복원할 수 있습니다.

압축된 보관 파일을 다운로드한 후 콘텐츠를 추출하고 설치할 수 있습니다. 자세한 내용은 github/backup-utils 리포지토리에서 시작하기를 참조하세요.

기존 백업 구성 파일(backup.config)이 있는 경우 파일을 새로 추출하여 설치한 GitHub Enterprise Server Backup Utilities 버전의 위치에 복사해야 합니다.

GitHub Enterprise Server Backup Utilities에서 만든 백업 스냅샷은 backup.config 파일의 GHE_DATA_DIR 데이터 디렉터리 변수에 의해 설정된 디스크 경로에 기록됩니다. 이러한 스냅샷은 기호와 하드 링크를 지원하는 filesystem에 저장되어야 합니다.

1. github/backup-utils 리포지토리의 릴리스 페이지에서 관련 GitHub Enterprise Server Backup Utilities 릴리스를 다운로드합니다.

2. tar를 사용하여 리포지토리를 추출하려면 다음 명령을 실행합니다.

   tar -xzvf /path/to/github-backup-utils-vMAJOR.MINOR.PATCH.tar.gz
   

3. 로컬 리포지토리 디렉터리로 변경하려면 다음 명령을 실행합니다.

   cd backup-utils
   

4. 포함된 backup.config-example 파일을 backup.config로 복사하려면 다음 명령을 실행합니다.

   cp backup.config-example backup.config
   

5. 구성을 사용자 지정하려면 텍스트 편집기에서 backup.config를 편집합니다.

   1. 이전에 Git을 사용하여 GitHub Enterprise Server Backup Utilities을(를) 업그레이드한 경우 backup.config의 기존 구성을 새 파일로 복사해야 합니다. 자세한 내용은 “GitHub Enterprise Server Backup Utilities 업그레이드”를 참조하세요.

   2. GHE_HOSTNAME 값을 기본 GitHub Enterprise Server 인스턴스의 호스트 이름 또는 IP 주소로 설정합니다.

      참고: GitHub Enterprise Server 인스턴스이(가) 부하 분산 장치를 사용하여 클러스터 또는 고가용성 구성으로 배포된 경우 GHE_HOSTNAME은(는) 포트 122를 통해 GitHub Enterprise Server 인스턴스에 대한 SSH 액세스가 허용되는 한 부하 분산 장치 호스트 이름이 될 수 있습니다.

      복구된 인스턴스를 즉시 사용할 수 있도록 하려면 지역 복제 구성에서도 주 인스턴스를 대상으로 하는 백업을 수행합니다.

   3. GHE_DATA_DIR 값을 백업 스냅샷을 저장할 파일 시스템 위치로 설정합니다. 백업 호스트와 동일한 파일 시스템의 위치를 선택하는 것이 좋습니다.

6. 인스턴스에 대한 백업 호스트 액세스 권한을 부여하려면 http(s)://HOSTNAME/setup/settings에서 주 인스턴스의 설정 페이지를 열고 백업 호스트의 SSH 키를 권한 있는 SSH 키 목록에 추가합니다. 자세한 내용은 "관리 셸(SSH)에 액세스"을(를) 참조하세요.

7. 백업 호스트에서 ghe-host-check 명령으로 GitHub Enterprise Server 인스턴스와의 SSH 연결을 확인합니다.

   ./bin/ghe-host-check
   

8. 초기 전체 백업을 만들려면 다음 명령을 실행합니다.

   ./bin/ghe-backup
   

고급 사용에 대한 자세한 내용은 GitHub Enterprise Server Backup Utilities 프로젝트 설명서의 GitHub Enterprise Server Backup Utilities 추가 정보를 참조하세요.

GitHub Enterprise Server Backup Utilities 업그레이드

GitHub Enterprise Server Backup Utilities을(를) 업그레이드할 때는 GitHub Enterprise Server의 현재 버전으로 작업할 릴리스를 선택해야 합니다. GitHub Enterprise Server Backup Utilities의 설치는 GitHub Enterprise Server 인스턴스 버전과 적어도 동일해야 하며 두 버전 이상을 앞서서는 안 됩니다. 자세한 내용은 GitHub Enterprise Server Backup Utilities 프로젝트 설명서의 GitHub Enterprise Server 버전 요구 사항을 참조하세요.

1. GitHub Enterprise Server Backup Utilities에 대한 설치 방법을 확인합니다. 이전 버전의 GitHub Enterprise Server Backup Utilities은(는) 로컬 Git 리포지토리에서 설치 및 업데이트를 지원했지만 이 방법은 더 이상 지원되지 않습니다.

   1. 백업 호스트에서 일반적으로 backup-utils인 GitHub Enterprise Server Backup Utilities 디렉터리로 이동합니다.

   2. 유효한 작업 디렉터리가 Git 리포지토리 내에 있는지 확인하려면 다음 명령을 실행합니다.

      git rev-parse --is-inside-work-tree
      

2. GitHub Enterprise Server Backup Utilities을(를) 업그레이드하는 방법을 확인하려면 git rev-parse --is-inside-work-tree의 출력을 검토합니다.

   • 출력이 true이면 프로젝트의 Git 리포지토리를 복제하여 GitHub Enterprise Server Backup Utilities가 설치되었습니다. 업그레이드하려면 backup.config에서 기존 구성을 복사하고 “GitHub Enterprise Server Backup Utilities 설치"의 지침을 따릅니다.
   • 출력에 fatal: not a git repository (or any of the parent directories)가 포함된 경우 압축된 보관 파일에서 GitHub Enterprise Server Backup Utilities이(가) 추출된 것입니다. 업그레이드하려면 "GitHub Enterprise Server Backup Utilities 설치"의 지침을 따릅니다.

백업 예약

cron(8) 명령 또는 유사한 명령 예약 서비스를 사용하여 백업 호스트에서 일반 백업을 예약할 수 있습니다. 구성된 백업 빈도에 따라 복구 계획에서 최악의 RPO(복구 지점 목표)가 결정됩니다. 예를 들어 매일 자정에 실행되도록 백업을 예약한 경우 재해 시나리오에서 최대 24시간의 데이터가 손실될 수 있습니다. 시간별 백업 일정부터 시작하여 기본 사이트 데이터가 삭제되는 경우 최대 1시간의 데이터가 손실되는 최악의 경우를 보장하는 것이 좋습니다.

백업 시도가 겹치면 동시 백업이 있음을 나타내는 오류 메시지와 함께 ghe-backup 명령이 중단됩니다. 이 경우 예약된 백업의 빈도를 줄이는 것이 좋습니다. 자세한 내용은 GitHub Enterprise Server Backup Utilities 프로젝트 설명서의 GitHub Enterprise Server Backup Utilities 추가 정보에서 “백업 예약” 섹션을 참조하세요.

백업 복원

기본 사이트에서 장기간 중단되거나 치명적인 이벤트가 발생하는 경우 다른 인스턴스를 프로비저닝하고 백업 호스트에서 복원을 수행하여 GitHub Enterprise Server 인스턴스을(를) 복원할 수 있습니다. 인스턴스 복원 전에 백업 호스트의 SSH 키를 대상 GitHub Enterprise 인스턴스에 권한 있는 SSH 키로 추가해야 합니다.

GitHub Enterprise Server 인스턴스에 백업 복원을 수행할 때는 최대 두 개의 기능 릴리스에서만 데이터를 복원할 수 있습니다. 예를 들어 GitHub Enterprise Server 3.0.x에서 백업을 수행하는 경우 GitHub Enterprise Server 3.2.x를 실행하는 인스턴스로 백업을 복원할 수 있습니다. GitHub Enterprise Server 2.22.x의 백업에서 3.2.x를 실행하는 인스턴스로 데이터를 복원할 수 없는 이유는 버전 간에 세 번의 점프(2.22에서 3.0에서 3.1에서 3.2로)가 되기 때문입니다. 3.1.x를 실행하는 인스턴스로 먼저 복원한 다음, 3.2.x로 복원할 수 있습니다.

네트워크 설정은 백업 스냅샷에서 제외됩니다. 복원 후 대상 GitHub Enterprise Server 인스턴스에서 네트워킹을 수동으로 구성해야 합니다.

필수 조건

1. 유지 관리 모드는 주 인스턴스에서 사용하도록 설정되어 있고 모든 활성 프로세스가 완료되었는지 확인합니다. 자세한 내용은 "유지 관리 모드 사용 설정 및 예약"을(를) 참조하세요.
2. 고가용성 구성의 모든 복제본 노드에서 복제를 중지합니다. 자세한 내용은 "고가용성 구성 정보"을(를) 참조하세요.
3. 새 GitHub Enterprise Server 인스턴스를 프로비저닝하여 백업 복원 대상으로 사용합니다. 자세한 내용은 "GitHub Enterprise Server 인스턴스 설정"을(를) 참조하세요.
4. GitHub Enterprise Server 인스턴스에 GitHub Actions이(가) 활성화된 경우 교체 인스턴스에서 GitHub Actions에 대한 외부 스토리지 공급자를 구성해야 합니다. 자세한 내용은 "GitHub Actions를 사용할 수 있는 GitHub Enterprise 서버 백업 및 복원"을(를) 참조하세요.

복원 작업 시작

마지막으로 성공한 스냅샷을 사용하여 백업 호스트에서 GitHub Enterprise Server 인스턴스을(를) 복원하려면 ghe-restore 명령을 사용합니다. 또한 ghe-restore을(를) 포함하여 다음과 같은 추가 옵션을 설정할 수 있습니다.

• -c 플래그는 이미 구성된 경우에도 대상 호스트의 설정, 인증서 및 라이선스 데이터를 덮어씁니다. 테스트 목적으로 스테이징 인스턴스를 설정하고 대상에서 기존 구성을 유지하려는 경우 이 플래그를 생략합니다. 자세한 내용은 github/backup-utils 리포지토리의 GitHub Enterprise Server Backup Utilities README의 "백업 및 복원 명령 사용" 섹션을 참조하세요.
• -s 플래그를 사용하면 다른 백업 스냅샷을 선택할 수 있습니다.

ghe-restore을(를) 실행한 후 명령은 복원을 확인한 다음 작업 중에 세부 정보 및 상태 출력합니다.

$ ghe-restore -c 169.154.1.1
> Checking for leaked keys in the backup snapshot that is being restored ...
> * No leaked keys found
> Connect 169.154.1.1:122 OK (v2.9.0)

> WARNING: All data on GitHub Enterprise appliance 169.154.1.1 (v2.9.0)
>          will be overwritten with data from snapshot 20170329T150710.
> Please verify that this is the correct restore host before continuing.
> Type 'yes' to continue: yes

> Starting restore of 169.154.1.1:122 from snapshot 20170329T150710
# ...output truncated
> Completed restore of 169.154.1.1:122 from snapshot 20170329T150710
> Visit https://169.154.1.1/setup/settings to review appliance configuration.

필요에 따라 복원의 유효성을 검사하려면 지정된 IP 주소 목록에 대한 액세스를 허용하도록 IP 예외 목록을 구성합니다. 자세한 내용은 "유지 관리 모드 사용 설정 및 예약"을(를) 참조하세요.

고가용성 구성의 인스턴스에서 기존 또는 빈 인스턴스의 새 디스크로 복원한 후 ghe-repl-status은(는) 부실 서버 UUID로 인해 Git 또는 Alambic 복제본이 동기화되지 않음을 보고할 수 있습니다. 이러한 부실 UUID는 고가용성 구성에서 사용 중지된 노드가 애플리케이션 데이터베이스에 여전히 존재하지만 복원된 복제본 구성에는 없는 결과일 수 있습니다.

복원이 완료된 후 수정하고 복제를 시작하기 전에 ghe-repl-teardown을(를) 사용하여 부실 UUID를 분해할 수 있습니다. 추가 지원이 필요한 경우 GitHub Enterprise 지원을(를) 방문하세요.