PostgreSQL 물리적 백업: 재해 복구의 핵심 전략

안녕하세요, 데이터베이스 관리자 여러분! 데이터베이스가 갑자기 다운되거나 데이터가 손실되는 상황을 상상해 보신 적 있나요? 그럴 때, 고객 데이터가 날아가고 비즈니스가 멈추는 악몽 같은 시나리오가 현실이 될 수 있습니다. PostgreSQL을 운영하는 DBA라면, 데이터의 무결성과 가용성을 최우선으로 생각하실 텐데요. 그중에서도 백업과 복구 전략은 시스템의 생명줄입니다. 특히, 파일 시스템 수준의 물리적 백업은 재해 복구(Disaster Recovery)에서 빛을 발휘합니다. 이 글에서는 물리적 백업의 기본 개념부터 유형, 실전 팁, 그리고 복구 예시까지 자세히 알아보겠습니다. 함께 안정적인 PostgreSQL 환경을 구축해 보아요!

728x90

물리적 백업이란 무엇인가?

PostgreSQL의 물리적 백업은 데이터베이스를 구성하는 실제 파일들을 그대로 복사하는 방법입니다. 이는 논리적 백업(예: pg_dump로 스키마와 데이터를 SQL로 추출하는 방식)과 달리, 데이터 파일, WAL(Write-Ahead Logging) 파일, 구성 파일(postgresql.conf, pg_hba.conf 등)을 포괄적으로 다룹니다.

왜 물리적 백업이 중요한가요?

• 신속한 복원: 전체 클러스터를 한 번에 복구할 수 있어 다운타임을 최소화합니다.
• 재해 시 강력한 보호: 서버 크래시, 디스크 고장, 랜섬웨어 공격 등에서 전체 시스템을 되살릴 수 있습니다.
• 비즈니스 연속성: 99.99% 가용성을 목표로 하는 클라우드나 엔터프라이즈 환경에서 필수적입니다.

물리적 백업은 단순한 '파일 복사'가 아니라, PostgreSQL의 아키텍처를 이해한 전략적 접근입니다. 이제 주요 유형을 살펴보죠.

물리적 백업의 두 가지 주요 유형

PostgreSQL 물리적 백업은 크게 오프라인 백업과 온라인 백업으로 나뉩니다. 각 유형의 장단점을 비교해 보세요.

1. 파일 시스템 수준 백업 (오프라인 백업)

이 방식은 서버를 오프라인으로 전환한 후, OS 도구를 사용해 PostgreSQL 데이터 디렉터리(기본: /var/lib/postgresql/data)를 복사합니다. cp, rsync, 또는 tar 같은 명령어를 활용할 수 있어요.

장점:

• 구현이 간단하고, 비용이 들지 않습니다. (전문 도구 없이도 가능)
• 백업 크기가 작아 저장 공간을 절약합니다.

단점:

• 데이터베이스 서비스를 중지해야 하므로 다운타임이 발생합니다. (예: pg_ctl stop → 복사 → pg_ctl start)
• 24/7 운영 환경(예: e-commerce 사이트)에서는 부적합합니다.

실전 팁: 작은 개발 환경이나 주말 유지보수 시에 적합합니다. 예시 명령어:

sudo systemctl stop postgresql
sudo rsync -a /var/lib/postgresql/data/ /backup/path/
sudo systemctl start postgresql

2. pg_basebackup 유틸리티를 사용한 베이스 백업 (온라인 백업)

PostgreSQL의 내장 도구인 pg_basebackup는 데이터베이스가 온라인 상태에서도 일관된 스냅샷을 생성합니다. WAL 아카이빙과 연동되어 PITR(Point-In-Time Recovery)을 지원하죠.

장점:

• 서비스 중단 없이 백업 가능 – 프로덕션 환경의 최선의 선택입니다.
• WAL 파일을 자동으로 캡처해 백업 시점 이후 변경 사항까지 복구할 수 있습니다.

특징 및 단점:

• 네트워크나 스토리지 I/O가 높아질 수 있습니다.
• WAL 아카이빙을 미리 설정해야 합니다. (postgresql.conf에서 archive_mode = on, archive_command 지정)

실전 예시 명령어: tar 형식으로 백업 생성 (WAL 포함):

pg_basebackup -h localhost -U postgres -D /backup/path -F tar -z -P --wal-method=fetch

• -D: 백업 저장 경로
• -F tar: tar 형식 출력
• -z: 압축 적용
• --wal-method=fetch: WAL 파일을 백업에 포함

이 도구를 사용하면 백업 후에도 실시간으로 WAL을 아카이브할 수 있어, 재해 시 정확한 시점 복구가 가능합니다.

유형	다운타임	복잡도	추천 환경
오프라인 백업	있음 (서비스 중지)	낮음	개발/테스트
온라인 백업 (pg_basebackup)	없음	중간	프로덕션/고가용성

물리적 백업 시 고려해야 할 중요 사항

백업은 '생성'하는 데 그치지 않고, '효과적으로 관리'하는 것이 핵심입니다. 아래 체크리스트를 참고하세요.

1. 데이터베이스 상태 관리
   오프라인 백업 시 트랜잭션을 완전히 중지하세요. 온라인 백업의 경우 pg_basebackup가 자동으로 락을 걸어 일관성을 보장하지만, 장기 실행 쿼리를 모니터링하세요. (불일치 시 pg_resetwal로 WAL 재설정 가능, 하지만 데이터 손실 위험!)
2. WAL 파일 관리
   PITR을 위해 마지막 베이스 백업 이후 WAL 세그먼트를 보관하세요. wal_keep_size나 archive_command를 통해 아카이브 스토리지를 설정하고, 최소 7일 치 WAL을 유지하는 게 표준입니다. WAL이 부족하면 복구가 불가능해집니다.
3. 백업 빈도와 자동화
   데이터 변경량에 따라 결정하세요. 트랜잭션이 많은 OLTP 시스템이라면 매일 백업, OLAP라면 주 1회. cron job이나 Ansible로 자동화하세요. 예: 매일 자정에 pg_basebackup 실행 스크립트.
4. 복원 테스트 (가장 중요!)
   백업은 100%지만 복원은 0%일 수 있습니다. 매 분기마다 스테이징 서버에서 전체 복원 테스트를 하세요. 이 과정에서 구성 파일 호환성, WAL 적용 오류 등을 확인합니다. "백업이 있어도 복원이 안 되면 백업이 아니다"라는 격언을 기억하세요!
5. 스토리지와 보안
   로컬 디스크에만 의존하지 마세요. AWS S3, Google Cloud Storage, 또는 오프사이트 서버로 3-2-1 규칙(3개 복사본, 2개 미디어, 1개 오프사이트)을 적용하세요. 암호화(예: gpg)와 접근 제어(IAM)를 잊지 마세요. 재해 시(화재, 지진) 복구율을 90% 이상으로 끌어올립니다.

이러한 고려사항을 무시하면 백업이 '죽은 데이터'가 될 수 있으니, DRP(Disaster Recovery Plan)에 명시적으로 포함시키세요.

실제 복구 예시: pg_basebackup을 활용한 복구

이론은 좋지만, 실전이 진짜입니다. 디스크 전체가 포맷된 치명적 장애를 가정하고, /backup/2025-10-30-base.tar.gz에 백업이 있다고 해보죠. 복구 과정은 간단합니다.

1. PostgreSQL 서비스 중지
2. sudo systemctl stop postgresql
3. 기존 데이터 디렉터리 제거
4. sudo rm -rf /var/lib/postgresql/data/*
5. 베이스 백업 복원
   tar 파일을 풀고 데이터 디렉터리에 적용:WAL 아카이브가 있다면 recovery.conf (또는 postgresql.conf의 restore_command)로 WAL 적용:
6. # recovery.conf 예시 restore_command = 'cp /archive/%f %p' recovery_target_time = '2025-10-30 14:00:00'
7. tar -xzf /backup/2025-10-30-base.tar.gz -C /var/lib/postgresql/data/
8. PostgreSQL 서비스 재시작 및 확인
9. sudo systemctl start postgresql psql -U postgres -c "SELECT now(); SELECT count(*) FROM your_table;"

이 과정으로 30분 이내에 시스템을 복구할 수 있습니다. PITR을 사용하면 백업 시점 이후 특정 시간(예: 오후 2시)으로 롤백도 가능하죠. 실제 테스트에서 WAL 적용 시간을 측정해 보세요 – 대용량 DB라면 몇 시간 걸릴 수 있습니다!

결론: 안정적인 미래를 위한 첫걸음

PostgreSQL의 물리적 백업은 단순한 파일 복사가 아니라, 재해로부터 비즈니스를 지키는 '보험'입니다. 오프라인/온라인 유형을 적절히 선택하고, WAL 관리, 정기 테스트를 통해 DR 전략을 강화하세요. 결국, 좋은 DBA는 '문제가 발생할 때'가 아니라 '문제가 발생하지 않도록' 준비하는 사람입니다.