PostgreSQL 백업 파일을 복원하기 전 확인한 운영 체크리스트

백업 성공 알림만 믿지 않았다

운영 DB의 백업 작업이 성공했다고 표시됐지만, 복구 테스트를 하려니 파일 크기가 평소의 절반이었다. 압축률이 달라졌을 수도 있지만 확인하지 않고 넘어갈 수는 없었다. 복구는 장애가 난 뒤 처음 해보면 늦기 때문에 별도 DB에 복원하는 연습을 체크리스트로 만들었다.

파일과 대상 환경 확인

먼저 파일 자체의 생성 시각, 소유자, 압축 해제 가능 여부를 확인한다. 운영 데이터베이스에 바로 넣는 명령은 체크리스트에서 제외했다.

stat backup.dump
sha256sum backup.dump
pg_restore --list backup.dump > /tmp/backup-contents.txt

해시를 기록해 전송 중 파일이 바뀌지 않았는지 확인하고, pg_restore --list 결과에 기대한 스키마와 테이블이 있는지 눈으로 본다. --clean 옵션은 편리하지만 대상 DB의 기존 객체를 지울 수 있으므로 복구 테스트에서는 사용하지 않았다.

복구 절차를 분리한다

• 테스트용 데이터베이스와 전용 역할을 만든다.
• 복원 전에 대상 PostgreSQL 버전과 확장 목록을 비교한다.
• 외부 서비스가 연결되지 않는 격리된 환경에서 복원한다.
• 행 개수, 최근 레코드, 핵심 조회 쿼리를 확인한다.
• 애플리케이션을 붙이기 전에 마이그레이션 상태를 확인한다.

복원 후에는 단순히 명령이 성공했는지만 보지 않고 업무에 필요한 조회를 실행했다. 특히 시퀀스 값이 데이터의 최대 ID보다 작은지 확인하지 않으면 복원 직후 새 입력에서 충돌할 수 있다.

SELECT last_value FROM orders_id_seq;
SELECT COALESCE(MAX(id), 0) FROM orders;

두 값이 어긋났을 때 수정할 SQL은 데이터베이스별로 다르므로, 그 자리에서 임의로 실행하지 않고 서비스 스키마 문서에 절차를 남겼다.

완료 조건을 숫자로 적는다

이번 체크리스트의 완료 조건은 “복원 명령 종료 코드 0”이 아니다. 핵심 테이블의 예상 범위가 맞고, 대표 조회가 정상이며, 복구에 걸린 시간과 백업 시점이 기록되어야 완료로 표시한다. 다음에는 이 과정을 임시 환경에서 주기적으로 자동 실행해 백업의 복구 가능성을 검증할 계획이다.