백업은 '하고 있다' 가 아니라 '복원해 봤다' 가 기준입니다. 백업 파일이 있어도 복원 절차를 모르거나, 복원했더니 깨져 있거나, 복원에 하루가 걸린다면 그 백업은 없는 것과 같습니다. PostgreSQL 기준으로 두 가지 백업 방식과, 가장 중요한 복구 리허설을 정리합니다.
1. pg_dump — 대부분의 서비스는 이것으로 시작
# 매일 새벽, 압축 포맷으로
pg_dump -Fc -h localhost -U app -d appdb -f /backup/appdb-$(date +%F).dump
# 복원 (빈 DB 에)
createdb -U app appdb_restore
pg_restore -U app -d appdb_restore /backup/appdb-2026-06-16.dump-Fc(custom) 포맷은 압축되고, 테이블 단위로 골라 복원할 수 있으며, 병렬 복원(-j)도 됩니다. 하루 한 번이면 RPO(잃어도 되는 데이터 범위)가 최대 24시간이라는 뜻이니, 그게 허용되는 서비스인지 먼저 판단합니다. 백업 파일은 DB 서버 밖(다른 서버, 오브젝트 스토리지)으로 옮기고 보존 기간(예: 일 7·주 4·월 6)을 정합니다.
2. 시점 복구(PITR) — 분 단위로 되돌려야 할 때
물리 백업(pg_basebackup)에 WAL 아카이브를 더하면 '어제 14:05 직전' 처럼 특정 시각으로 되돌릴 수 있습니다. 잘못된 DELETE 가 나갔을 때 그 직전으로 가는 것이 이 방식입니다.
# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'cp %p /wal-archive/%f' # 실제로는 다른 서버·스토리지로
# 기본 백업
pg_basebackup -D /backup/base -Fp -Xs -P복구 때는 기본 백업을 풀고 recovery_target_time 을 지정해 기동합니다. 설정이 많은 만큼 연습 없이 실제 상황에서 처음 하면 거의 실패합니다. PITR 을 쓰기로 했다면 리허설은 선택이 아닙니다.
3. 복구 리허설 — 분기에 한 번
리허설의 산출물은 두 숫자입니다. 복원에 걸린 시간(RTO)과 잃은 데이터 범위(RPO). 이 숫자가 서비스가 허용하는 범위 안에 있는지 보고, 아니면 백업 주기나 방식을 바꿉니다. 복원한 DB 에 애플리케이션을 붙여 핵심 화면을 열어 보는 단계를 빼먹지 마세요 — 테이블은 있는데 권한·확장(extension)·시퀀스가 빠져 앱이 안 뜨는 경우가 흔합니다.
4. 자주 놓치는 것
- 백업 실패 알림 — 조용히 실패한 백업이 몇 달 쌓인 뒤 발견됩니다. cron 의 종료 코드를 알림으로 보내세요.
- 역할·확장·설정 — pg_dump 는 DB 안의 객체만 담습니다. 역할(roles)은
pg_dumpall --globals-only로 따로, 서버 설정 파일도 함께 보관합니다. - 비밀번호·접속 정보 — 복원 절차서에 접속 정보가 어디 있는지(비밀번호 자체가 아니라 위치)를 적어 둡니다.
백업의 완성은 파일이 아니라 복원 기록입니다. 분기마다 한 번, 빈 서버에 올려 보세요.
댓글