백업을 만들고 복원으로 확인하기

결론부터

백업의 성공은 파일 생성으로 끝나지 않고 원하는 데이터로 복원할 수 있을 때 확인된다.

디스크 전체 장애, 일부 테이블 이행, 실수한 시점 직전으로 돌아가기는 요구가 서로 다르다. 어떤 손실에서 얼마 전까지 복원할지 정한 다음 백업 방식을 고른다.

이 장에서 처음 나오는 말3개

논리 백업Logical backup

테이블 정의와 행을 다시 만들 수 있는 형태로 추출한다. 대표 도구가 pg_dump다.

베이스 백업Base backup

물리 복구의 출발점이 되는 데이터 디렉터리 등의 일관된 백업.

PITRPoint-In-Time Recovery

베이스 백업 뒤의 WAL을 재생해 목표 시점으로 복구한다.

무엇을 되살릴 수 있나

방식	얻는 것	범위와 조건
pg_dump	특정 DB의 논리 백업	선택 복원·이행에 유용. 임의 시점 PITR의 출발 파일은 아님
물리 베이스 백업	서버 데이터의 물리 복원 기반	버전·확장·필요한 WAL 등 일관된 복구 조건 필요
베이스 백업 + 연속 WAL 아카이브	복구 가능한 구간 안의 시점 선택	중간 WAL이 끊기면 그 뒤 목표까지 도달할 수 없음

pg_dump는 한 DB의 일관된 스냅샷을 추출한다. 여러 DB와 전역 role·tablespace를 한 번에 모두 보존하는 도구는 아니다. 전역 객체는 별도 관리가 필요하다. (pg_dump, pg_dumpall)

로컬 백업과 별도 DB 복원

공통 예제의 projects 3행·tasks 3행이 있는 상태에서 진행한다. 아래는 psql이 아닌 호스트 셸에서 실행한다. /tmp/pg-study-backup은 실습 파일 위치다.

mkdir -p /tmp/pg-study-backup
docker exec pg-study pg_dump -U postgres -d studydb -Fc \
  > /tmp/pg-study-backup/studydb.dump

docker exec pg-study createdb -U postgres study_restore
docker exec -i pg-study pg_restore -U postgres -d study_restore \
  --no-owner --no-acl --exit-on-error \
  < /tmp/pg-study-backup/studydb.dump

docker exec pg-study psql -X -U postgres -d study_restore \
  -c 'SELECT count(*) FROM public.projects;' \
  -c 'SELECT count(*) FROM public.tasks;'

두 결과 모두 3이어야 한다. -Fc는 pg_restore가 읽는 custom 형식이다. 이 실습은 관리자 한 명으로 복원하므로 소유자·권한 복원을 생략했다. 실제 복원에서는 role·권한·확장과 앱 접근까지 검증해야 한다. (pg_restore)

정리할 때 원본 studydb는 남기고 복원한 실습 DB와 파일만 지운다.

docker exec pg-study dropdb -U postgres study_restore
rm /tmp/pg-study-backup/studydb.dump
rmdir /tmp/pg-study-backup

이 파일은 원본과 같은 PC에 있다. 복원 방법을 익히는 예제이며 PC 장애에 대비한 보관 설계가 아니다.

PITR에서 목표 시점 고르기

10시 베이스 백업 뒤 WAL이 계속 보관됐고 11시 30분에 잘못된 DELETE가 확정됐다고 하자. 11시 29분으로 복구하려면 그 시점을 포함하는 복구 가능 구간과 필요한 WAL이 있어야 한다. 원본 위에 덮어쓰지 않고 별도 인스턴스에 복원해 필요한 행과 앱 상태를 검증한다. (연속 아카이브와 PITR)

**RPO(Recovery Point Objective)**는 허용할 데이터 손실 구간, **RTO(Recovery Time Objective)**는 서비스 복구에 허용할 시간이다. 백업 간격만으로 둘을 보장할 수는 없다. WAL 업로드 지연과 보관 범위, 다운로드·재생 시간, 검증·앱 전환까지 실제로 측정한다.

백업에서 빠지기 쉬운 것

DB 백업은 외부 오브젝트 파일이나 애플리케이션 비밀을 자동으로 포함하지 않는다. 암호화 키를 잃거나 백업 저장소 자격증명을 사용할 수 없으면 파일이 있어도 복구하지 못할 수 있다. 데이터·설정·권한·외부 의존성 중 무엇을 따로 보관하는지 명확히 한다.

이해 확인: 백업 작업이 completed인데 복구를 보장할 수 없는 이유는? 목표 시점까지의 WAL 누락, 권한·키 문제, 호환되지 않는 실행 환경, 미확인 데이터가 남아 있을 수 있다. CNPG에서 이 확인을 수행하는 흐름은 백업 구성과 시점 복구로 이어진다.