Skip to content

Commit

Permalink
chore: Update content for backup-utils
Browse files Browse the repository at this point in the history
  • Loading branch information
younsl committed Jul 20, 2024
1 parent 82e2956 commit 9c11c03
Showing 1 changed file with 78 additions and 42 deletions.
120 changes: 78 additions & 42 deletions content/blog/ghe-backup-utils/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,11 +32,9 @@ Github Enterprise Server에서 백업 유틸리티(backup-utils)와 고가용성

### github-backup-utils

Github Enterprise Server를 운영할 때 공식적으로 github-backup-utils를 사용해서 백업을 수행해야 합니다.
Github Enterprise Server를 운영할 때 공식적으로 backup-utils를 사용해서 백업을 수행해야 합니다.

Github Support 측 공식 답변으로는 GHE 서버의 백업은 AWS Backup의 경우 보조 개념으로 사용하고, github-backup-utils를 메인 백업으로 사용하는 걸 권장한다고 합니다.

이 경우 AWS Backup은 Optional한 선택지이므로 Github에서 공식적으로 제공하는 backup-utils만 사용해도 무방할 것 같습니다.
Github Support 측 공식 답변으로는 Github Enterprise Server의 백업은 AWS Backup의 경우 보조 개념으로 사용하고, backup-utils를 메인 백업으로 사용하는 걸 권장한다고 합니다. 이 경우 AWS Backup은 선택사항이므로 Github에서 공식적으로 제공하는 backup-utils만 사용해도 무방합니다.

 

Expand Down Expand Up @@ -71,15 +69,15 @@ Github Enterprise 시스템 구성은 다음과 같습니다.

### 백업 인스턴스 생성

#### OS
#### OS (AMI)

Github 측에서는 공식적으로 Ubuntu OS를 기준으로 백업 소프트웨어를 테스트 되었으므로 Ubuntu OS를 권장하고 있습니다.
Github에서는 공식적으로 Ubuntu OS에서 백업 소프트웨어를 테스트했기 때문에 Ubuntu를 사용하는 걸 권장합니다.

그러나 저는 이번 기회에 Amazon Linux 2023을 써보고 싶어서 백업 서버의 AMI로 Amazon Linux 2023을 선정했습니다.
하지만 저는 AWS 환경을 사용하고 있어서 백업 서버의 AMI로 Amazon Linux 2023을 선택했습니다. 이유는 [Amazon Linux 2 FAQ](https://aws.amazon.com/ko/amazon-linux-2/faqs/) 문서에 의하면 Amazon Linux 2가 2025년 6월 30일에 완전 지원이 종료되기 때문입니다.

 

제 경우 백업 서버의 OS로 Amazon Linux 2023 + ARM64 아키텍처를 사용했는데 운영에 전혀 영향이 없었습니다.
제 경우 백업 서버의 OS로 Amazon Linux 2023 + ARM64 아키텍처를 사용했는데 백업서버 운영에 전혀 영향이 없었습니다.

```bash
$ cat /etc/os-release
Expand All @@ -101,7 +99,8 @@ SUPPORT_END="2028-03-01"

#### 리소스 스펙

CPU 및 메모리 요구 사항은 GitHub Enterprise Server 어플라이언스의 크기에 따라 다릅니다.
CPU 및 메모리 요구 사항은 GitHub Enterprise Server 어플라이언스의 크기에 따라 다릅니다.

GitHub Enterprise Backup Utilities를 실행하는 호스트에는 최소 4개의 코어와 8GB의 RAM이 권장됩니다.

 
Expand Down Expand Up @@ -135,21 +134,18 @@ tmpfs tmpfs 783M 0 783M 0% /run/user/1000

### 백업 인스턴스에 접속

Github Enterprise 백업 인스턴스에 SSH로 접속합니다.
Github Enterprise 백업 인스턴스에 SSH 또는 [SSM Session Manager](https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/session-manager.html) 접속합니다.

```bash
# SSH access command example
$ ssh -i my-ec2-ssh-key.pem -p 22 -l ec2-user 10.190.33.44
ssh -i my-ec2-ssh-key.pem -p 22 -l ec2-user 10.190.33.44
```

2023년 7월 기준으로 Amazon Linux 2023은 Session Manager를 사용할 수 없고 SSH만 지원합니다.
[Amazon Linux 2023 공식문서](https://docs.aws.amazon.com/linux/al2023/ug/connecting-to-instances.html)

 

#### 필수 유틸리티

백업 서버에 git을 설치합니다. 백업 수행에 필요한 유틸리티입니다.
백업 서버에 `git` 명령어을 설치합니다. 백업 수행에 필요한 유틸리티입니다.

```bash
$ sudo yum install -y git
Expand All @@ -174,8 +170,9 @@ Amazon Linux 2023 기준으로 대부분이 이미 설치되어 있지만 git과
[github-backup-utils v3.8.1](https://github.com/github/backup-utils/releases/tag/v3.8.1) 패키지를 `/opt/` 밑에 다운로드 받습니다.

```bash
$ wget https://github.com/github/backup-utils/releases/download/v3.8.1/github-backup-utils-v3.8.1.tar.gz \
-O /opt/github-backup-utils-v3.8.1.tar.gz
VERSION="v3.8.1"
wget https://github.com/github/backup-utils/releases/download/$VERSION/github-backup-utils-$VERSION.tar.gz \
-O /opt/github-backup-utils-$VERSION.tar.gz
```

위 명령어가 실행되기 위해서 백업서버가 NAT Gateway를 경유해서 인터넷 아웃바운드 가능한 네트워크 환경이어야 합니다.
Expand Down Expand Up @@ -475,18 +472,19 @@ $ sudo mv backup.config-example /etc/github-backup-utils/backup.config

### cronie 설치

Amazon Linux 2023에는 기본적으로 crontab이 설치되어 있지 않습니다.
스케줄 백업을 지정하기 위해 cron 데몬(cronie)을 설치합니다.
스케줄 백업을 수행하기 위해 cron 데몬<sup>cronie</sup>을 설치합니다.

```bash
$ sudo yum install -y cronie
```

Amazon Linux 2023은 내부 반복 작업을 [systemd 타이머](https://www.freedesktop.org/software/systemd/man/systemd.timer.html)로 마이그레이션했기 때문에 의도적으로 cron이 제외되었습니다. [#300](https://github.com/amazonlinux/amazon-linux-2023/issues/300#issuecomment-1481592973)
Amazon Linux 2023에는 기본적으로 crontab이 설치되어 있지 않습니다. Amazon Linux 2023은 내부 반복 작업을 [systemd 타이머](https://www.freedesktop.org/software/systemd/man/systemd.timer.html)로 마이그레이션했기 때문에 의도적으로 cron 패키지가 제외되어 있습니다.

> Amazon Linux 2023에서 cron deprecation 관련으로는 [deprecated cron](https://docs.aws.amazon.com/linux/al2023/ug/deprecated-al2023.html#deprecated-cron)[Github issue #300](https://github.com/amazonlinux/amazon-linux-2023/issues/300#issuecomment-1481592973)을 참고합니다.
&nbsp;

백업서버가 재부팅될 경우에도 cron 데몬을 자동시작하도록 enable 설정합니다.
백업서버가 재부팅된 후에도 cron 데몬<sup>crond</sup>을 자동시작하도록 enable 설정합니다.

```bash
$ sudo systemctl enable crond.service
Expand Down Expand Up @@ -554,10 +552,10 @@ crontab에 백업 스케줄 작성 시 참고하세요.
* * * * * command to be executed
┬ ┬ ┬ ┬ ┬
│ │ │ │ └───────────── Day of Week (0=Sun .. 6=Sat)
│ │ │ └─────────────── Month (1..12)
│ │ └───────────────── Day of Month (1..31)
│ └─────────────────── Hour (0..23)
└───────────────────── Minute (0..59)
│ │ │ └─────────────── Month (1 .. 12)
│ │ └───────────────── Day of Month (1 .. 31)
│ └─────────────────── Hour (0 .. 23)
└───────────────────── Minute (0 .. 59)
```

&nbsp;
Expand All @@ -569,11 +567,15 @@ crontab에 백업 스케줄 작성 시 참고하세요.
백업 서버에서 새로운 SSH 키페어를 생성합니다.

```bash
$ ssh-keygen -t ed25519 -C "[email protected]"
ssh-keygen \
-t ed25519 \
-C "[email protected]" \
-P ""
```

- `-t` (Type) : 어떠한 암호화 방식을 사용할 것인지를 지정합니다. 사용 가능한 타입으로는 rsa, dsa, ecdsa, ed25519 등이 있습니다.
- `-C` (Comment) : 생성한 키에 주석 달기. 일반적으로는 Github Enterprise 관리자의 이메일 주소를 입력합니다.
- `-t` (Type): 어떠한 암호화 방식을 사용할 것인지를 지정합니다. 사용 가능한 타입으로는 `rsa`, `dsa`, `ecdsa`, `ed25519` 등이 있습니다.
- `-C` (Comment): 생성한 키에 주석 달기. 일반적으로는 Github Enterprise 관리자의 이메일 주소를 입력합니다.
- `-P` (Passphrase): 패스프레이즈 없이 SSH 키를 생성합니다.

&nbsp;

Expand All @@ -593,10 +595,8 @@ authorized_keys id_ed25519 id_ed25519.pub known_hosts
또는 아래와 같이 Primary 서버의 `~/.ssh/authorized_keys` 파일에 추가해도 콘솔에서 설정한 것과 동일한 효과를 나타냅니다.

```bash
$ cat ~/.ssh/authorized_keys
...
# 백업서버의 공개키 id_ed25519.pub
ssh-ed25519 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [email protected]
# Add public key in your GHE instance as backup target
echo "ssh-ed25519 <your-public-key> [email protected]" | tee -a /home/admin/.ssh/authorized_keys
```

&nbsp;
Expand Down Expand Up @@ -775,14 +775,14 @@ Backup progress: 138.00 % (25 / 18 ) ghe-backup-es-rsync took 1s

&nbsp;

### 정리
### 주요 핵심파일들

백업 서버에서 사용하는 핵심 파일 경로는 다음과 같습니다.
EC2 기반의 `backup-utils` 서버에서 사용하는 중요파일 경로는 다음과 같습니다.

- **설정파일 기본경로** : /etc/github-backup-utils/backup.config
- **패키지 경로** : /opt/backup-utils/
- **스냅샷이 저장되는 경로** : /opt/backup-utils/data/
- **백업 로그 경로** : /opt/backup-utils/backup.log
- **설정파일 기본경로** : `/etc/github-backup-utils/backup.config`
- **패키지 경로** : `/opt/backup-utils/`
- **스냅샷이 저장되는 경로** : `/opt/backup-utils/data/`
- **백업 로그 경로** : `/opt/backup-utils/backup.log`

&nbsp;

Expand All @@ -799,7 +799,18 @@ Backup progress: 138.00 % (25 / 18 ) ghe-backup-es-rsync took 1s
그래서 백업서버 인프라를 쿠버네티스 클러스터에 CronJob 형태로 운영하는 결정을 했습니다. gp3 타입의 EBS 볼륨에 백업 데이터를 증적하는 메커니즘은 동일합니다.
다만 백업을 수행하는 주체가 EC2 대신 `CronJob`이 주기적으로 스케줄링하는 `Pod`로 바뀐다는 점이 가장 큰 차이점입니다.

이에 대한 설치 방법은 이 글의 주제를 벗어나므로 생략하겠습니다. 더 관심 있으신 분들은 제가 개발한 [backup-utils-chart](https://github.com/younsl/charts/tree/main/charts/backup-utils) 레포지터리를 확인하세요.
backup-utils 설치는 SSH Key에 대한 Secret을 생성한 이후, 헬름 차트로 손쉽게 가능합니다.

```bash
helm upgrade \
--install \
--namespace backup-utils \
--create-namespace \
backup-utils . \
-f values.yaml
```

더 관심 있으신 분들은 제가 개발한 [backup-utils](https://github.com/younsl/charts/tree/main/charts/backup-utils) 헬름차트를 확인하세요.

&nbsp;

Expand All @@ -812,12 +823,20 @@ Primary & Replica로 HA 구성을 했지만 둘다 깨지는 사단에 이르렀
![backup-utils를 사용한 복구절차](./8.png)

1. 복구할 새 Github Enterprise Server 인스턴스 생성: 반드시 **새로 생성된 인스턴스**에 복구를 해야만 합니다.
2. GHE 새 인스턴스의 `/home/admin/.ssh/authorized_keys` 경로에 id_ed25519 공개키 등록
2. GHE 새 인스턴스의 `/home/admin/.ssh/authorized_keys` 경로에 SSH 공개키<sup>id_ed25519.pub</sup> 등록
3. 복구용 backup-utils deployment 파드 생성
4. **메인터넌스 모드 켜기**: `ghe-restore` 명령어를 수행하려면 `ghe-maintenance -s`를 사용해서 반드시 메인터넌스 모드가 켜져 있어야 합니다.
5. Actions S3 설정: 이 단계는 내가 복구할 스냅샷에 Actions 데이터가 포함되어 있어서 필요했습니다. 자세한 설정 방법은 [Github Enterprise Server 공식문서](https://docs.github.com/en/enterprise-server/admin/managing-github-actions-for-your-enterprise/advanced-configuration-and-troubleshooting/backing-up-and-restoring-github-enterprise-server-with-github-actions-enabled#restoring-a-backup-of-github-enterprise-server-when-github-actions-is-enabled)에서 확인할 수 있습니다.

```bash
# Enable maintenance mode in new primary GHE instance
ghe-maintenance -q
ghe-maintenance -s
```

5. **Actions S3 설정**: 이 단계는 내가 복구할 스냅샷에 Actions 데이터가 포함되어 있어서 필요했습니다. 자세한 설정 방법은 [Github Enterprise Server 공식문서](https://docs.github.com/en/enterprise-server/admin/managing-github-actions-for-your-enterprise/advanced-configuration-and-troubleshooting/backing-up-and-restoring-github-enterprise-server-with-github-actions-enabled#restoring-a-backup-of-github-enterprise-server-when-github-actions-is-enabled)에서 확인할 수 있습니다.

```bash
# Run these commands in new primary GHE instance
# Actions S3 관련 설정
ghe-config secrets.actions.storage.blob-provider "s3"

Expand All @@ -832,15 +851,32 @@ Primary & Replica로 HA 구성을 했지만 둘다 깨지는 사단에 이르렀
ghe-config-apply
```

6. 복구용 파드 → 새 인스턴스 SSH 포트<sup>TCP/122</sup>로 연결 가능여부 확인 `ghe-host-check`
6. 복구용 파드 → 새 인스턴스 SSH 포트<sup>TCP/122</sup>로 연결 가능여부 확인

```bash
ghe-host-check
```

7. 복구용 파드에서 스냅샷 복구 `ghe-restore`

&nbsp;

## 정리

- Github Enterprise Server를 운영할 때 백업과 고가용성을 위한 Replica를 같이 혼합해서 사용하는 것이 모범사례입니다.
- 백업 구성은 지루한 작업이지만 그 무엇보다 중요합니다. Github Enterprise Server에 재난이 닥쳤을 때에 후회하면 이미 늦습니다.
- 최근 15시간 동안 Github Enterprise Server 서버를 복구한 후 포스트모템을 쓰면서 업무가 중단된 개발자들에게 미안하기도 하고 많은 생각이 스쳤습니다.

> 초기에 Github Enterprise Server 구축할 때 `backup-utils`로 데이터 백업 구성 해놓길 잘했다. VCS를 self-hosted로 직접 운영하는 건 매우 고된 작업이구나.. 가끔은 Failover 이후에 Replica 서버까지도 고장나는 경우가 있구나.. 만약 데이터 백업하지 않았더라면? 모든 회사의 소스코드가 날라간 상황에서 나는 어떻게 되었을까?
&nbsp;

## 참고자료

[GitHub Enterprise Server Backup Utilities - Documentation](https://github.com/github/backup-utils#documentation)
github-backup-utils 공식문서에 전체적인 설명이 잘 나와 있습니다.

[Installing CronTab on Amazon Linux 2023 EC2](https://jainsaket-1994.medium.com/installing-crontab-on-amazon-linux-2023-ec2-98cf2708b171)
Amazon Linux 2023에서 CronTab 설치 시에 참고한 글

[Deprecated in AL2023](https://docs.aws.amazon.com/linux/al2023/ug/deprecated-al2023.html#deprecated-cron)

0 comments on commit 9c11c03

Please sign in to comment.