당신의 PostgreSQL 백업은 아마도 손상되었습니다 (확실히 확인하는 방법)

Source: Dev.to

문제: 겉보기엔 괜찮아 보이지만 필요할 때 실패하는 백업

• 백업 복구의 73 %가 프로덕션에서 실패합니다.
• 실패는 보통 백업 소프트웨어가 망가졌기 때문이 아니라, 복구를 한 번도 테스트해 보지 않았기 때문입니다.

팀은 흔히 다음과 같이 합니다:

1. pg_dump를 매시간 실행한다.
2. 덤프를 압축한다 (gzip).
3. S3에 업로드한다.
4. 초록색 체크마크를 보고 모든 것이 정상이라고 생각한다.

재해가 발생했을 때 복구가 깨지는 이유는 다음과 같습니다:

• 손상된 덤프 파일
• 잘못된 파일 권한
• 누락된 확장 기능
• 스키마 드리프트

백업은 성공했지만 복구는 실패했으며, 이 문제는 가장 필요할 때 비로소 드러납니다.

“✓ Done” 체크마크가 오해를 불러일으키는 이유

체크마크는 파일이 업로드됐다는 것만 확인합니다. 이는 다음 사항을 알려주지 않습니다:

• 덤프를 실제로 복구할 수 있는지 여부
• 데이터가 온전한지 여부
• 행 개수가 원본과 일치하는지 여부
• 인덱스가 유효한지 여부

실제로 복구를 시도해 보기 전까지는 알 수 없으며, 대부분의 팀은 너무 늦을 때까지 이를 하지 않습니다.

더 나은 접근법: 자동 복구 검증

나는 “덤프하고 기도하기”를 넘어서는 시스템을 만들었습니다. 매일 다음을 수행합니다:

1. 다운로드 최신 백업을 S3에서 가져옵니다.
2. 복구를 격리된 검증용 데이터베이스에 수행합니다.
3. 무결성 검사를 실행합니다(테이블 카운트, 행 검증, 사용자 정의 쿼리).
4. 성공/실패를 보고합니다.
5. 자동 정리를 수행합니다.

복구가 실패하면 즉시 알 수 있습니다—프로덕션이 불타오를 때가 아니라.

시스템 아키텍처

Backup Service

• 일정에 따라 pg_dump를 실행합니다(기본: 매시간).
• gzip으로 압축합니다.
• S3‑호환 스토리지에 업로드합니다.
• 보존 정책을 자동으로 처리합니다.

Verify Service

• 매일 백업을 다운로드합니다.
• 별도의 PostgreSQL 인스턴스로 복구합니다.
• 정상성 검사를 실행합니다.
• 백업이 정상 작동함을 확인합니다.

두 서비스 모두 가벼운 컨테이너로 실행되며 다음과 함께 사용할 수 있습니다:

• AWS S3
• Backblaze B2
• Cloudflare R2
• DigitalOcean Spaces
• Wasabi
• MinIO

Railway(또는 어디든)에서 배포하기

1. 데이터베이스 URL과 S3 자격 증명을 환경 변수로 추가합니다.
2. 두 컨테이너 서비스를 배포합니다.

서비스는 즉시 작동을 시작합니다.

제공 내용

• 시간당 백업을 S3에 저장(설정 가능)
• 일일 복구 검증
• 보존(기본 7 일, 설정 가능)
• AES‑256 암호화(선택 사항)
• Slack/Discord 알림(실패 시)
• 설정 후 유지보수 필요 없음

오픈소스 저장소

프로젝트는 완전 오픈소스입니다:

github.com/Kjudeh/railway-postgres-backups

Docker, docker‑compose 또는 어떤 컨테이너 플랫폼에서도 동작합니다—Railway에만 국한되지 않습니다.

요점

한 번도 복구해 보지 않은 백업은 신뢰할 수 없는 백업입니다.
자동 검증을 한 번 설정하고 영원히 안심하세요.

질문이 있나요? 댓글을 남기거나 GitHub에 이슈를 열어 주세요.