PostgreSQL 18에서 삭제 직전으로 돌아가려면 목표 시각보다 먼저 끝난 베이스 백업과 필요한 WAL이 끊김 없이 있어야 합니다. 백업 검증 도구의 성공 기록과 별도로, 격리된 복원본에서 삭제 전 데이터와 목표 시각 이후의 변경을 대조해야 합니다.
가장 최근 백업을 선택하기 전에 종료 시각부터 보세요
예를 들어 베이스 백업이 오전 9시 45분에 시작해 10시 5분에 끝났고, 실수로 데이터가 삭제된 시각이 오전 10시라고 가정해 보겠습니다. 목표가 오전 9시 59분이면 이 베이스 백업은 사용할 수 없습니다. 백업이 진행 중인 시각을 목표로 삼으려면 그 전에 끝난 베이스 백업과, 그 백업의 시작부터 복구에 필요한 구간까지 이어지는 WAL이 있어야 합니다. P1
| 보유한 자료 | 삭제 직전 시점 복구에서의 역할 |
|---|---|
pg_dump 논리 덤프 |
덤프에 담긴 데이터를 별도로 가져올 수 있다. WAL을 적용하는 시작점으로는 사용할 수 없다. |
| 목표보다 먼저 끝난 베이스 백업 | 물리 복원의 출발점이다. 필요한 WAL을 함께 확인한다. |
| 중간이 빠진 WAL 아카이브 | 복구에 필요한 중간 WAL이 빠졌다면 뒤쪽 파일로 건너뛸 수 없다. |
PITR은 물리 백업을 이용해 클러스터 전체를 복원합니다. 삭제된 테이블만 필요하더라도 별도 환경에 복구본을 띄워 필요한 데이터를 확인하고 추출하는 방식으로 계획을 세우세요. P1
복구 목표에는 시간대와 커밋 경계가 필요합니다
사고를 보고받은 시간과 삭제 트랜잭션이 커밋된 시간은 다를 수
있습니다. 애플리케이션·DB 기록의 시간대부터 맞춘 뒤 목표 시각을
정하세요. PostgreSQL의 recovery_target_time에는 예를 들어
+09:00처럼 UTC 오프셋을 명시할 수 있습니다. 해당 시각과
정확히 같은 커밋의 포함 여부는 recovery_target_inclusive가
정하며 기본값은 포함입니다. P3
사고 시각이 분 단위로만 남아 있다면 초 단위 정밀도를 가정하지 마세요. 격리 복원본의 데이터를 조회해 삭제 전 상태인지 확인하고, 목표 시각의 근거와 확인한 레코드를 작업 기록에 함께 남깁니다.
파일 검사를 통과한 뒤 복원본에서 데이터를 확인하세요
pg_verifybackup은 지원되는 백업과 매니페스트를 검사하는
데 도움이 됩니다. PostgreSQL 문서는 실제 서버가 백업을 사용할 때
수행하는 모든 검사를 이 도구가 대신할 수 없다고 설명합니다. 별도의 복원
리허설을 통해 목표 시점까지 재생되는지와 결과 데이터가 의도한 상태인지
확인하세요. 목표를 지정한 상태에서 그 시점에 도달하기 전에 아카이브
복구가 끝나면 서버는 오류를 내고 종료됩니다. P2 · P3
테스트 기록에는 백업 시작·종료 시각, 대상 WAL 보관 위치, 목표 시각과 시간대, 실제 복원 소요 시간, 업무 데이터 확인 결과를 남깁니다. 예를 들어 삭제 전에 존재하던 샘플 주문은 복원본에서 조회되고, 목표 시점 뒤에 생성한 테스트 주문은 조회되지 않아야 합니다. 이 두 방향을 확인하면 복원 서버의 기동 여부와 목표 시점의 정확성을 따로 판단할 수 있습니다.
