초보 서비스의 백업은 pg_dump와 스냅샷 중 무엇부터 고를지 비교한 기준

스냅샷이 있으면 백업도 충분할까

처음에는 VPS 스냅샷이 있으니 DB도 안전하다고 생각했다. 하지만 특정 테이블만 되돌리려니 운영체제와 앱 파일, 데이터가 한 덩어리였다. 이후에는 파일이 있느냐보다 무엇을 얼마나 빨리 복구해야 하는지로 도구를 골랐다.

pg_dump는 DB를 독립적으로 옮긴다

논리 백업은 다른 PostgreSQL 인스턴스로 복원하기 좋고, 개발 환경에서 복구를 연습하기도 쉽다.

pg_dump -Fc -d appdb -f /var/backups/appdb-2026-07-17.dump
pg_restore -d appdb_restore --clean --if-exists /var/backups/appdb-2026-07-17.dump

커질수록 덤프와 복원 시간이 길어질 수 있고, 같은 서버 디스크에만 두면 서버 장애에는 소용없다.

스냅샷은 서버 전체 복구에 맞는다

시스템 업데이트나 프록시 설정 변경 전에는 서버 스냅샷이 편하다. 반면 개별 레코드를 꺼내는 데는 별도 환경에서 확인할 절차가 필요할 수 있다.

상황	먼저 볼 방법
데이터 일부 삭제	pg_dump 또는 PITR
운영체제 설정 손상	서버 스냅샷
다른 환경으로 DB 이동	pg_dump

내가 정한 최소선

매일 논리 백업을 만들고 서버 밖 저장소에도 복사한다. 큰 변경 전에는 스냅샷을 추가하고, 월 1회 별도 DB에 복원한다.

pg_restore --list /var/backups/latest.dump
psql -d appdb_restore -c 'SELECT count(*) FROM users;'

한 번은 권한 오류로 빈 파일이 생겼는데 생성 날짜만 봐서는 몰랐다. 백업의 핵심 검사는 생성이 아니라 복원이다.

체크

• 서버 밖에도 복사되는가?
• 보관 기간과 접근 권한이 있는가?
• 실제 복원을 해 봤는가?

작은 서비스에서는 데이터의 독립 복구를 먼저 가능하게 하고, 스냅샷을 서버 전체 복구의 보완책으로 두는 흐름이 가장 이해하기 쉬웠다.