Kai 52 2
게시물 메뉴

thumbnail.png.jpg

오늘 서버가 뻗었습니다

오늘 바이브크루 서버가 두 시간 정도 죽어 있었습니다.

원인은 메모리 과부하였습니다.
모니터링 알림은 바로 왔는데 문제는 SSH까지 안 붙었다는 것.

서버가 죽는 것도 무섭지만
알림은 왔는데 내가 아무것도 할 수 없는 상황이 더 무섭더군요.

다행히 서버는 다시 살렸습니다.

그런데 복구하고 나니 제일 먼저 든 생각이 있었습니다.

"만약 이번에 서버가 아예 안 살아났으면?"

백업은 같은 서버에 있으면 안 되겠더군요

서버 안에 /backup 폴더를 만들어놓는 것도 백업이긴 합니다.

그런데 디스크가 깨지거나
클라우드 계정에 문제가 생기거나
서버 자체에 다시 접근할 수 없게 되면 원본과 백업을 같이 잃습니다.

결국 중요한 건

서버를 통째로 잃어도 다른 곳에서 다시 살릴 수 있느냐.

그래서 저는 예전에 만들어놓은 Google Drive 백업을 이번에 다시 점검했습니다.

별도 백업 서버 없이 Google Drive로

작은 서비스라면 백업 때문에 서버를 하나 더 운영하는 것도 부담입니다.

특히 DB와 설정 파일처럼 용량이 크지 않고
몇 분 전 시점까지 복구해야 하는 서비스가 아니라면 Google Drive도 꽤 쓸 만합니다.

구조는 단순합니다.

서버에서 DB 덤프 생성
→ GnuPG 공개키로 암호화
→ 평문 삭제
→ rclone으로 Google Drive 업로드
→ 일정 기간이 지난 백업 자동 삭제

그리고 매일 새벽 cron으로 자동 실행합니다.

여기서 개인키는 백업 서버에 두지 않습니다.

서버에는 암호화할 수 있는 공개키만 두고
복호화에 필요한 개인키는 서버 밖에 따로 보관합니다.

서버가 털리더라도 Google Drive에 올라간 DB 내용을 바로 열어볼 수 없게 하기 위해서입니다.

백업보다 더 중요한 건 복구였습니다

이번에 다시 점검하면서 가장 중요하다고 느낀 부분입니다.

백업 파일이 Google Drive에 있다고 끝이 아니었습니다.

직접 내려받고
개인키로 복호화하고
새 DB를 만든 다음 실제로 복원해봐야 합니다.

복구해보지 않은 백업은 정말 복구되는 백업인지 모릅니다.

오늘 장애 덕분에(?) 예전에 만들어둔 백업 구조를 처음부터 다시 점검했고,

rclone 설치부터 Google Drive 연결, GnuPG 공개키 암호화, 자동 백업 스크립트, cron 등록, 오래된 백업 삭제, 실제 PostgreSQL 복구까지 초보자도 따라할 수 있게 정리해봤습니다.

백업은 재미가 없습니다.

기능 하나 더 만드는 게 훨씬 재밌고
UI 하나 고치는 게 훨씬 눈에 보입니다.

그런데 서버가 죽는 순간 우선순위가 완전히 바뀝니다.

서버가 멀쩡할 때 해두세요.
죽고 나서 시작하면 늦습니다.

https://goodtek.xyz/blog/rcloneeuro-google-drivee-rinugseu-seobeo-jadong-baegeobhagi-gnupg-amhohwa-bogguggaji/