[DB-011][실무] 백업이 진짜 복원되는지 확인하는 법 > IT 기술 공유

• 목록

[이번 수업]
백업 파일이 생겼다고 복구가 보장되지는 않습니다. 파일이 손상됐거나 필요한 역할·확장 기능이 빠졌고, 복원 시간이 예상보다 길 수도 있습니다. 이번에는 PostgreSQL의 논리 백업을 별도 데이터베이스에 복원하고 결과를 확인하며, 장애에 대비한 목표와 점검표를 만듭니다.

[선수지식]
PostgreSQL 설치와 `psql` 사용법, 데이터베이스·테이블·역할의 차이, 기본 SQL을 알고 있어야 합니다.

[학습목표]
1. RPO·RTO를 정하고 백업 방식을 선택한다.
2. `pg_dump` 백업을 새 데이터베이스에 복원한다.
3. 데이터·스키마·권한·복원 시간을 검증하는 훈련을 설계한다.

[핵심개념]
RPO(복구 시점 목표)는 장애 때 허용할 수 있는 최대 데이터 손실 구간입니다. 1시간 RPO라면 최대 1시간 분량의 변경을 잃을 수 있습니다. RTO(복구 시간 목표)는 서비스를 다시 사용할 수 있게 만들기까지 허용하는 시간입니다. 먼저 두 목표를 정해야 백업 주기, 저장 위치, 복구 자동화 수준을 결정할 수 있습니다.

`pg_dump`는 한 데이터베이스의 스키마와 데이터를 일관된 시점으로 내보내는 논리 백업 도구입니다. 사용자 역할과 테이블스페이스 같은 클러스터 전역 객체는 포함하지 않으므로 필요하면 `pg_dumpall --globals-only`를 별도로 계획합니다. 짧은 RPO나 특정 시점 복구가 필요하면 기본 백업과 WAL(변경 기록 파일) 연속 보관을 결합한 PITR을 검토합니다. 논리 백업과 PITR은 목적·절차가 다릅니다.

백업 검증은 파일 존재와 크기 확인에서 끝나지 않습니다. 격리된 복구 환경에 실제로 복원하고, 오류 없이 끝났는지, 핵심 행 수와 제약조건이 맞는지, 애플리케이션이 읽고 쓰는지, RTO 안에 끝나는지를 기록해야 합니다.

[따라하기]
본인 소유의 로컬 PostgreSQL에서 다음 명령을 순서대로 실행합니다. macOS·Linux 터미널과 Windows PowerShell에서 명령은 같으며, Windows에서 찾지 못하면 PostgreSQL의 bin 폴더를 PATH에 추가합니다.
```text
createdb lesson_db
psql lesson_db -c "CREATE TABLE notes(id integer PRIMARY KEY, body text NOT NULL); INSERT INTO notes VALUES (1, '첫 메모'), (2, '둘째 메모');"
pg_dump --format=custom --file=lesson.dump lesson_db
pg_restore --list lesson.dump
createdb lesson_restore
pg_restore --exit-on-error --dbname=lesson_restore lesson.dump
psql lesson_restore -c "SELECT count(*) AS restored_rows FROM notes;"
```
`--format=custom`은 `pg_restore`로 선택 복원할 수 있는 압축 아카이브를 만듭니다. `--list` 결과에는 TABLE과 TABLE DATA 항목이 보여야 합니다. 마지막 예상 결과는 `restored_rows`가 2인 표입니다. 같은 이름의 데이터베이스가 이미 있다면 충돌하므로 새 이름을 사용하세요. 복원 시간도 함께 재어 RTO와 비교합니다.

[흔한 실수]
운영 서버와 같은 저장장치에 백업 한 벌만 두면 장치 장애 때 함께 잃습니다. 성공 종료 코드와 경고를 확인하지 않거나, 데이터만 세고 인덱스·제약조건·역할을 확인하지 않는 것도 위험합니다. `pg_dump` 한 파일이 서버 전체의 역할과 모든 데이터베이스를 담는다고 오해하지 마세요. 보존 기간과 삭제 절차도 문서화해야 합니다.

[보안 주의]
덤프에는 개인정보와 비밀 데이터가 들어갈 수 있으므로 전송·보관 중 암호화하고 최소 권한으로 접근을 제한합니다. 비밀번호를 명령줄이나 스크립트에 직접 쓰지 마세요. PostgreSQL 공식 문서는 신뢰하지 않는 원본의 덤프를 복원하면 원본 관리자가 넣은 코드가 실행될 수 있다고 경고합니다. 출처와 무결성을 확인하고, 운영망과 분리된 환경에서 먼저 검사하세요. 실습은 본인 소유의 로컬·격리 환경에서만 합니다.

[직접 해볼 과제]
복원된 `notes`의 행 수·기본키·NOT NULL 제약을 확인하는 SQL을 작성하고, 백업 시작부터 검증 완료까지 걸린 시간을 기록하세요. 목표 RPO와 RTO, 담당자, 백업 위치, 복원 명령, 성공 기준을 한 장의 복구 점검표로 만듭니다.

[확인문제]
1. RPO와 RTO는 각각 어떤 손실과 시간을 뜻하나요?
2. `pg_dump`만으로 사용자 역할까지 완전히 백업할 수 없는 이유는 무엇인가요?
3. 백업 파일의 존재 확인만으로 복구 가능성을 증명할 수 없는 이유는 무엇인가요?

[다음 학습]
DB-012에서 주문 데이터 모델을 만들고 트랜잭션·인덱스·분석 쿼리·백업 검증을 묶은 프로젝트를 진행합니다.

[공식 참고 자료]
https://www.postgresql.org/docs/current/backup-dump.html
https://www.postgresql.org/docs/current/app-pgdump.html
https://www.postgresql.org/docs/current/app-pgrestore.html
https://www.postgresql.org/docs/current/continuous-archiving.html
https://csrc.nist.gov/glossary/term/recovery_point_objective
https://csrc.nist.gov/glossary/term/recovery_time_objective