DB 백업·WAL·시점 복구
PITR · Point-in-Time Recovery · 데이터베이스 백업
DB 백업은 데이터베이스의 구조와 자료를 일관된 복원 재료로 보관하는 작업이다. 시점 복구는 기본 백업에 연속 변경 로그를 적용하여 목표 지점에서 멈추는 방식으로, 잘못된 작업만 단순히 역실행하는 기능과 다르다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 자료 손실·오조작·장애에 대비한 독립 복원 재료를 확보한다.
- 기본 백업과 로그 위치를 연결해 복구 가능한 시간 범위를 넓힌다.
- 복원·검증·서비스 전환 시간을 측정해 목표와 비교한다.
02어떤 순서로 동작하나
- 일관된 기준 확보
로그 기반 시점 복구에는 제품이 지원하는 기본 백업을 준비한다. WAL 재생은 호환되는 물리 기본 백업이 필요하며 pg_dump의 논리 덤프를 그 자리에 넣을 수 없다.
- 로그 연속 보관
기준 이후 변경을 재생하는 데 필요한 로그를 빠짐없이 보관한다.
- 격리 복원
별도 환경에 기준을 복원하고 호환되는 로그를 정해진 목표까지 적용한다.
- 업무 검증·전환
구조·행·업무 합계·권한·애플리케이션 요청을 검사하고 서비스 전환을 포함한 전체 복구 시간을 측정한다.
03먼저 알아둘 용어와 구성요소
- 테이블 정의와 행 데이터를 또는 논리 형식으로 내보내는 방식이다. 의 pg_dump·pg_dumpall은 WAL 재생에 필요한 정보가 없어 연속 WAL 복구의 기본 백업을 대신하지 않는다.
- 은 DB 파일·페이지를 엔진의 복구 규칙에 맞게 보관하므로 빠를 수 있지만 엔진·버전·포맷 호환성과 일관성 조건이 더 직접적으로 연결된다.
- 데이터 페이지의 변경 내용을 디스크에 내보내기 전에 그 변경을 재구성할 WAL 기록을 먼저 안전하게 저장한다. 페이지를 즉시 모두 쓰지 않아도 충돌 복구가 가능한 근거다.
- 는 복구에 필요한 작업량을 제한하는 기준을 만든다. 이후 WAL과 기본 백업의 연결 관계가 있어야 올바른 상태로 재생할 수 있다.
- 이후 변경 로그를 연속 보관하고 백업과 로그 시작 위치의 관계를 기록하면 지정 시점까지 변경을 다시 적용하는 을 구성할 수 있다. 예를 들어 오전 기본 백업 뒤 오후에 잘못된 삭제가 발생했다면 삭제 직전까지의 로그를 적용하는 목표를 세운다.
- 는 허용 가능한 데이터 손실 범위를 시간 등으로 표현하고 는 복구 완료까지 허용하는 시간을 뜻한다.
복제 수신과 적용 스레드가 서로 다른 상태가 되는 과정
복제 상태의 Connecting·Yes·No와 로그 위치· 오류를 연결해 중단 지점을 설명한다.
실습 구성과 전제
- 사진은 의 SHOW SLAVE STATUS 형식이다. 현재 버전에서는 REPLICA 용어의 별칭을 제공할 수 있으나 화면의 필드 이름으로 해석한다.
- 세 상태를 수신→적용의 역할에 맞춰 비교한다. 암호·원본 서버 주소·발급된 자격 정보는 본문에 재현하지 않는다.
수신 연결이 아직 성립하지 않은 상태를 읽는다
- IO 스레드는 원본 서버의 변경 로그를 받아 relay log로 저장하고 스레드는 받은 이벤트를 적용한다. 두 상태 필드는 서로 다른 작업의 진행 여부다.
- IO가 Connecting이고 이 Yes이면 적용 스레드가 동작해도 새 변경을 정상 수신 중이라고 할 수 없다. 접속·인증·로그 파일 위치 문제는 IO 오류와 함께 확인해야 한다.
SHOW SLAVE STATUS\G화면과 같은 구문이다. 세로 출력에서 수신·적용 상태와 마지막 오류를 구분한다.
원본 크기로 보기 ↗- Slave_IO_Running은 Connecting, Slave_SQL_Running은 Yes다.
- Read_Master_Log_Pos=1071과 Relay_Log_Pos=4가 보이며 같은 종류의 위치 값이 아니다.
확인 기준두 필드 중 하나만 Yes인 상태를 복제 정상으로 요약하지 않는다. 마지막 IO 오류와 지연·로그 위치도 함께 읽는다.
연결 뒤 정상 대기 상태를 확인한다
- 다음 화면은 두 스레드가 Yes이며 IO 상태가 원본의 새 이벤트를 기다리는 상태다. 네트워크 수신과 적용 작업이 모두 실행 가능한 단계임을 보여 준다.
- Read_Master_Log_Pos와 Relay_Log_Pos는 서로 다른 로그 좌표이므로 숫자를 빼서 지연 바이트로 계산하지 않는다. 적용 완료 위치와 원본 위치도 파일명·좌표 체계를 맞춰 비교한다.
원본 크기로 보기 ↗- Slave_IO_Running=Yes, Slave_SQL_Running=Yes가 함께 보인다.
- Slave_IO_State는 새 이벤트를 기다리는 문구이고 Read_Master_Log_Pos=2245, Relay_Log_Pos=555가 표시된다.
확인 기준Yes/Yes만으로 모든 테이블의 일치나 영구 무지연을 보장하지 않는다. 업무 데이터 검증과 적용 좌표를 별도로 확인한다.
수신은 계속되지만 SQL 적용이 멈춘 상태를 해석한다
- 마지막 화면은 IO Yes· No다. 변경 로그를 계속 받을 수 있어도 누락된 test.t1 테이블에 이벤트를 적용하지 못해 스레드가 중단된다.
- 초기 데이터와 복제 시작 좌표가 일치해야 한다. 오류를 무조건 건너뛰면 정합성 차이를 숨길 수 있으므로 기본 백업·스키마·실패 이벤트의 관계를 복원해야 한다.
원본 크기로 보기 ↗- Slave_IO_Running=Yes인데 Slave_SQL_Running=No로 바뀐다.
- Last_SQL_Errno=1146과 test.t1이 존재하지 않는다는 오류가 표시된다.
확인 기준오류 원인을 해결한 뒤 스레드 상태뿐 아니라 누락 데이터·스키마를 대조한다. 복제본에도 삭제와 잘못된 변경이 전파될 수 있어 독립 백업이 필요하다.
실습에서 확인한 동작 원리
- 복제 수신과 적용은 별도 작업이므로 IO 상태· 상태·마지막 오류를 같이 읽는다.
- 기본 데이터와 시작 좌표의 일치가 복제의 전제이며, 복제 성공은 시점 복구용 백업을 대체하지 않는다.
동작·명령 참고 문서
04예제로 따라가기
- 02:00 기준과 연속 로그로 02:11까지 복구하면 02:12의 잘못된 삭제를 제외할 수 있지만 02:11 이후 정상 변경도 함께 제외된다.
- 복원 준비 12분·로그 재생 8분·검증 10분·전환 5분이면 총 복구 시간은 35분이며 재생 시간 8분만 보고하면 안 된다.
- 복제본이 삭제를 즉시 따라 적용했다면 최신 replica가 있다는 이유만으로 삭제 이전 자료를 복원할 수 있는 것은 아니다.
05혼동하기 쉬운 점과 확인 기준
- 다른 클러스터의 WAL이나 호환되지 않는 물리 파일을 섞으면 순서가 맞아도 복구 재료가 아니다. 백업 식별 정보·버전·타임라인을 함께 보관한다.
- 02:05 부근에 필요한 WAL 파일이 빠졌다면 02:10 로그가 있어도 그 사이를 건너뛰어 복구할 수 없다. 최초 누락 위치와 아카이브 저장 실패를 연결한다.
- WAL은 서버 설정 파일이나 외부 비밀 저장소 전체를 백업하지 않는다. 접속 정책·확장 모듈·암호화 자료가 없으면 데이터가 복구되어도 서비스가 열리지 않을 수 있다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
함께 보는 학습 자료
아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.
PostgreSQL 기본 백업과 WAL 시점 복구
장 첫머리의 Note에서 pg_dump가 WAL 재생용 기본 백업이 아닌 이유를 읽고 Making a Base Backup·Recovering Using a Continuous Archive 순으로 이동한다. 복구 재료와 목표 시점을 나누는 데 유용하다.
- 물리 기본 백업과 연속 WAL이 함께 필요한 이유
- pg_dump·pg_dumpall을 같은 복구 입력으로 사용할 수 없는 조건
- 복구 목표 이후의 정상 변경도 제외될 수 있는 범위
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.