매일 백업 파일이 생기고 작업 로그가 성공으로 끝나도, 장애 때 서비스를 다시 열 수 있는지는 별도 질문이다. 작은 팀이라면 백업 도구를 추가하기 전에 어느 시점의 데이터를, 얼마나 걸려, 어떤 상태까지 복구할지부터 정하는 편이 낫다. 이 글은 단순한 단일 PostgreSQL 환경을 위한 점검안이다.
먼저 복구의 합격 조건을 적는다
RPO는 허용할 데이터 손실의 시간 범위, RTO는 서비스 복구까지 허용할 시간 목표로 사용한다. 주문을 다시 입력할 수 있는 내부 도구와 고객 거래를 받는 서비스는 같은 숫자를 쓰기 어렵다. 담당자는 업무 책임자와 허용 범위를 정하고, “데이터베이스가 켜짐”보다 구체적인 합격 조건을 적어야 한다. 예를 들어 최근 주문 조회, 사용자 권한별 접근, 주문과 상세 내역의 연결 확인까지 포함하는 방식이다.
pg_dump는 데이터베이스 하나를 내보내며 역할과 테이블스페이스 같은 클러스터 공통 객체는 별도 관리가 필요하다. 공식 pg_dump 문서를 기준으로 백업 범위를 확인하자. 공식 문서도 단순한 경우를 제외하면 pg_dump가 운영용 정기 백업에 적합하지 않다고 안내한다. 데이터베이스 밖의 업로드 파일, 설정, 필요한 확장 기능도 목록에 적는다. 덤프 파일 하나를 전체 서비스의 복구 묶음으로 취급하지 않는 것이 출발점이다.
하루 한 번 백업의 손실 범위를 계산한다
SQL Dump 문서에 따르면 덤프는 작업이 시작된 시점의 일관된 스냅샷을 나타낸다. 완료 시각을 데이터 기준 시각으로 적으면 손실 범위를 짧게 계산하게 된다. 아래는 매일 오전 2시에 시작해 2시 30분에 복구용 저장소에서 사용할 수 있게 된다는 가정이다. 모든 시각은 한국시간이며, 실제 사고 기록이 아니다.
- 2026년 10월 13일 02:00 시작한 백업이 최신 사용 가능본이고, 14일 01:50에 장애가 나면 되돌아가는 시간 범위는 23시간 50분이다.
- 14일 백업이 아직 완료되지 않은 02:20에 장애가 나면 같은 백업을 사용하므로 범위는 24시간 20분이 된다.
- 당일 작업 실패나 저장소 전송 지연까지 생기면 범위는 더 길어진다. “매일 실행”만으로 최대 24시간 손실을 보장할 수 없다.
RPO 목표가 24시간이면 두 번째 경우는 목표를 넘긴다. 기록할 값은 실행 주기와 함께 최신 복구 가능본의 데이터 기준 시각이다. 이 차이는 손실 가능 시간창이며, 실제로 사라지는 주문 수나 금액을 뜻하지는 않는다. 업무량과 재처리 수단도 판단한다.
복구 시험은 세 단계로 기록한다
- 준비: 운영과 분리된 시험 환경에서 대상 주소와 데이터베이스 이름을 확인한다. 백업 식별자, 시작·종료·전송 완료 시각, 크기, 도구와 서버 버전, 필요한 역할과 확장 기능을 기록한다. 시험 데이터에도 운영 수준의 접근 통제를 적용하고 외부 발송이나 결제 연동은 차단한다.
- 복원: 파일 목록을 읽는 데서 끝내지 말고 실제 데이터베이스를 재구성한다. 일반 SQL 덤프와 아카이브 형식의 복구 도구가 다르므로 형식을 먼저 확인한다. 종료코드와 오류 로그를 남기고, 오류가 있으면 합격으로 처리하지 않는다.
- 업무 확인: 미리 정한 핵심 조회와 권한 검사를 실행한다. 백업 기준 시점에 맞춘 기준값과 주요 테이블 건수, 업무 합계, 데이터 간 연결을 비교한다. 현재 운영 데이터는 이미 바뀌었을 수 있으므로 무조건 일치해야 한다는 기준을 쓰지 않는다.
pg_restore 문서는 기본 동작에서 SQL 오류 뒤에도 처리를 계속하고 마지막에 오류 개수를 보여 준다고 설명한다. 따라서 마지막 진행 메시지만 확인하는 자동화는 피한다. 아카이브 목록 확인도 모든 데이터의 복구 성공을 입증하지 못한다.
복구 시간에는 준비와 확인도 포함한다
다음은 RTO를 120분으로 정한 팀의 계획용 가정이다. 장애 인지·판단 15분, 환경 준비·백업 가져오기 20분, 데이터베이스 복원 45분, 업무 검증 20분, 서비스 연결 전환 10분을 더하면 110분이다. 목표까지 남은 여유는 10분뿐이다. 어느 단계든 지연되면 목표를 넘길 수 있으며, 이 숫자는 측정값이 아니다.
시험에서는 각 단계의 시작과 종료를 따로 측정하고 가정을 실제 값으로 교체한다. 인덱스 생성, 데이터 증가, 저장소에서 파일을 가져오는 속도도 결과에 영향을 준다. 가장 빠른 한 번을 약속 시간으로 삼지 말고, 실패와 재시도에 걸린 시간도 함께 남긴다. 복원 명령만 45분에 끝났다고 서비스가 45분 만에 복구됐다고 보고해서는 안 된다.
목표에 못 미치면 백업 방식을 다시 고른다
손실 허용 범위가 하루보다 훨씬 짧다면 실행 빈도 조정과 함께 물리 백업·WAL 보관을 이용하는 시점 복구를 검토한다. 공식 PITR 문서는 기반 백업과 연속된 WAL이 필요하며 pg_dump 결과는 WAL 재생의 기반이 될 수 없다고 설명한다. 설정을 켰다는 사실보다 필요한 로그가 이어져 있고 목표 시점까지 실제 복구되는지가 중요하다.
또한 pg_verifybackup은 pg_basebackup으로 만든 백업을 검사하는 도구다. 덤프 파일용 검사기로 혼동하면 안 된다. 공식 문서도 이 검사를 통과하더라도 시험 복구와 데이터 확인을 수행하라고 권고한다.
이번 주에 남길 결과물
백업별 기준 시각, 복구 시험 결과, 단계별 소요 시간, 미해결 오류, 다음 확인 담당자를 한 장에 모으자. 도입 시점과 주요 변경 뒤에 시험하고, 반복 주기는 데이터 증가와 업무 중요도에 맞춰 정한다. 저장 비용을 계산할 때는 R2 저장 비용 점검 글도 참고할 수 있다.
AI 작성·검토: 2026년 10월 14일 PostgreSQL 공식 문서를 직접 확인해 구성했다. 확인 당시 current 문서는 PostgreSQL 18로 표시됐다. 시간 계산과 점검표는 설명을 위한 자체 예시이며 실제 복구 시험은 수행하지 않았다. 적용 시 운영 버전에 맞는 공식 문서를 다시 확인해야 한다.