• 목록

데이터베이스를 두 대로 복제하고 있으니 백업도 해결되었다고 생각할 수 있습니다. 하지만 현재 상태를 다른 서버에 유지하는 목적과 과거의 정상 상태로 돌아가는 목적은 다릅니다.

서버 장애와 잘못된 데이터 변경을 구분해 보면 복제와 백업을 왜 함께 검토하는지 이해하기 쉽습니다.

AI 생성 삽화 · 실사풍 연출 이미지입니다. 실제 고객 현장이나 실제 작업 결과를 촬영한 사진이 아닙니다.

핵심 정리
복제는 다른 서버에 데이터를 전달해 가용성 등의 요구를 지원하고, 백업은 복구에 사용할 자료를 보존합니다. 사본의 개수보다 어떤 시점으로 얼마나 빨리 돌아갈 수 있는지를 확인해야 합니다.

1. 서버 고장과 잘못된 변경을 나누어 봅니다

가상의 게시판 서비스를 생각해 보겠습니다. 주 서버의 장비가 고장 난 상황과 관리자가 게시글을 잘못 삭제한 상황은 모두 장애처럼 보이지만 필요한 대응이 다릅니다.

첫 상황에서는 다른 서버가 업무를 이어받을 수 있는지가 중요합니다. 두 번째 상황에서는 삭제 이전의 내용을 찾을 수 있는지가 중요합니다.

현재 상태를 계속 반영하는 복제본에 삭제도 전달되었다면 서버가 정상이어도 찾으려는 과거 데이터는 남아 있지 않을 수 있습니다. 이 예시는 특정 복제 제품의 모든 동작을 설명하는 것이 아니라 사고 유형을 분리하기 위한 것입니다.

설계 문서에 데이터 사본이 두 개라고만 적기보다 각각 어떤 실패를 대비하는지 적으면 빠진 복구 요구를 찾기 쉽습니다. 장비 수와 복구 가능성은 같은 지표가 아닙니다.

2. 복제는 어떤 변경을 어디까지 전달하는지 봅니다

PostgreSQL의 대기 서버 문서는 주 서버의 WAL을 다른 서버에서 적용하며 장애 시 업무를 이어받는 구성을 설명합니다. 비동기 방식에서는 아직 전달되지 않은 변경이 있을 수 있어 복제 지연과 데이터 손실 가능성을 함께 이해해야 합니다.

복제는 제품과 방식에 따라 보장 범위가 다르므로 단순히 실시간이라는 표현으로 모든 조건을 덮지 않는 것이 좋습니다. 학습용 구성도에는 원본 서버, 전달되는 변경, 적용하는 서버, 장애 시 전환 과정을 나누어 표시할 수 있습니다.

중요한 질문은 사본이 있다는 사실보다 어느 시점의 어떤 데이터가 사본에 반영되어 있는지입니다. 복제 지연이 우연히 잘못된 변경을 아직 반영하지 않은 상황도 있을 수 있지만 그것을 계획된 과거 복구 수단으로 보장받았다고 생각해서는 안 됩니다.

3. 백업은 되돌아갈 자료와 절차를 함께 봅니다

백업 파일을 만들었다는 사실과 복원이 가능한 상태는 다릅니다. 어떤 데이터를 언제의 상태로 보관했는지, 필요한 파일과 설정이 함께 있는지, 복원할 권한과 환경이 준비되어 있는지 확인해야 합니다.

가상의 서비스에서 데이터베이스만 복원했는데 사용자가 첨부한 이미지 파일이 없다면 게시글 화면은 완전히 돌아오지 않을 수 있습니다. 이처럼 복구 대상은 서비스가 실제로 의존하는 자료를 기준으로 정합니다.

백업 목록에는 파일 이름뿐 아니라 대상과 생성 시점, 보관 위치, 확인 결과를 남기는 편이 좋습니다. 최신 파일 하나가 있다는 이유로 필요한 과거 시점이 모두 남아 있다고 판단하지 않습니다.

백업 방식마다 복원 단위와 소요 작업이 다르므로 서비스에서 요구하는 복구 상황에 맞는지 확인해야 합니다.

4. 시점 복구의 전제 조건을 이해합니다

PostgreSQL의 PITR 문서는 기본 백업과 연속적으로 보관한 WAL을 조합해 목표 시점까지 변경을 재생하는 방식을 설명합니다. 여기서 핵심은 로그 파일 몇 개가 있다는 사실이 아니라 복구에 필요한 연속된 기록과 올바른 시작 자료가 준비되어 있다는 점입니다.

일반적인 논리 덤프를 같은 물리 복구 흐름의 시작점으로 사용할 수 있다고 생각해서도 안 됩니다. 이 글에서는 실제 복구 명령이나 운영 설정을 제시하지 않으며 사용 중인 버전의 공식 절차를 따라 별도 검증해야 합니다.

개념적으로는 현재 상태까지 모두 따라가는 목적과 원하는 과거 지점에서 멈추는 목적을 구분하면 좋습니다. 특정 시점 복구가 가능하다는 설명을 듣더라도 보관 범위 밖의 시점이나 필요한 로그가 없는 구간까지 자동으로 복구된다는 의미는 아닙니다.

5. 복구 시점과 복구 시간을 따로 적습니다

가상 서비스에서 어제 밤 백업으로 돌아갈 수 있다는 사실과 한 시간 안에 서비스를 다시 열 수 있다는 사실은 서로 다릅니다. 전자는 어느 시점의 데이터를 되찾는지에 관한 질문이고 후자는 복원과 검증에 걸리는 시간에 관한 질문입니다.

요구 사항을 정할 때 두 가지를 따로 적으면 단순히 백업 주기만 줄이는 것으로 충분한지 판단하기 쉽습니다. 복원 자체가 끝나도 애플리케이션 연결과 데이터 확인, 누락 작업의 처리에 시간이 필요할 수 있습니다.

예를 들어 복구된 주문 기록과 외부 시스템의 처리 결과를 맞추는 단계가 남을 수 있습니다. 이 사례의 시간은 목표값을 권하는 것이 아니라 서로 다른 기준을 설명하기 위한 것입니다.

팀에서는 기술적인 복원 완료와 사용자가 다시 서비스를 이용할 수 있는 완료를 구분해 기록하는 편이 좋습니다.

6. 복원 연습은 격리된 환경에서 확인합니다

백업 검증은 파일 크기가 정상처럼 보이는지 확인하는 수준을 넘어 실제로 복원할 수 있는지 살펴보는 과정이 필요합니다. 운영 서비스에 바로 덮어쓰는 방식 대신 분리된 검증 환경에서 절차를 확인하는 방법을 계획합니다.

복원 후에는 데이터가 열리는지만 보지 말고 필요한 시점과 주요 자료가 맞는지 점검합니다. 원본의 민감 정보가 포함된 자료라면 검증 환경의 접근 권한과 사용 범위도 함께 관리해야 합니다.

검증 기록에는 사용한 백업과 절차, 걸린 시간, 실패한 단계, 보완할 항목을 남길 수 있습니다. 한 번 성공했다고 이후의 모든 백업이 유효하다고 단정하지 않고 시스템이나 절차가 바뀌었을 때 다시 확인할 수 있게 합니다.

복원 연습은 사고를 흉내 내는 행위 자체보다 실제로 부족한 자료와 권한을 발견하는 데 의미가 있습니다.

7. 사본마다 보호 목적을 이름 붙입니다

설계를 정리할 때 운영 데이터, 복제본, 보관 백업, 복원 검증 결과를 구분해 적어 봅니다. 각 항목 옆에는 어떤 사고를 대비하는지와 어떤 시점까지 복구할 수 있는지, 누가 사용할 수 있는지를 남깁니다.

같은 계정의 실수나 장애가 모든 사본에 영향을 줄 수 있는지도 검토하고 요구에 맞게 보관과 접근을 분리하는 방안을 선택합니다. 특정 저장소 하나를 쓰면 모든 위험이 해결된다는 식으로 이해하지 않는 것이 좋습니다.

비용과 보관 기간, 복원 속도 사이에는 운영상의 선택이 필요합니다. 학습 단계에서 기억할 핵심은 복제와 백업 중 하나를 고르는 문제가 아니라는 점입니다.

현재 업무를 이어 가는 요구와 과거 상태를 되찾는 요구를 나눈 뒤 각각을 충족하는 자료와 절차가 있는지 확인해야 합니다. 복구 계획을 읽는 연습으로 장애 시나리오별 질문을 적어 볼 수 있습니다.

서버 한 대가 사라진 경우, 잘못된 수정이 이미 복제된 경우, 백업 저장소에 접근할 수 없는 경우를 나누고 사용할 자료와 담당자를 연결합니다. 대답할 수 없는 칸은 사본을 더 만든다고 자동으로 채워지지 않습니다.

필요한 권한과 연락 절차, 검증 환경을 함께 준비해야 실제 복구 과정으로 이어질 수 있습니다.

8. 자주 묻는 질문

Q1. 복제 서버가 있으면 백업을 생략해도 되나요?

복제만으로 필요한 과거 상태를 복구할 수 있는지 별도 확인해야 합니다. 잘못된 변경도 전달될 수 있으므로 보존과 복구 요구를 따로 검토합니다.

Q2. 백업 파일이 있으면 복구는 보장되나요?

필요한 자료가 모두 있고 실제 절차가 동작하는지 검증해야 합니다. 파일 생성 성공과 서비스 복원 성공은 다른 확인입니다.

Q3. PITR은 어느 과거 시점으로든 돌아갈 수 있나요?

보관한 기본 백업과 필요한 로그의 범위 등 조건을 충족해야 합니다. 보존 범위 밖의 시점까지 자동으로 복구할 수 있다는 뜻은 아닙니다.

Q4. 복원 테스트에서는 무엇을 기록하나요?

사용한 백업과 목표 시점, 소요 시간, 주요 데이터 확인 결과를 남깁니다. 부족한 권한이나 누락 자료처럼 다음 복구를 막을 수 있는 항목도 기록합니다.

참고 자료

• PostgreSQL 공식 문서: Continuous Archiving and PITR
• PostgreSQL 공식 문서: Log-Shipping Standby Servers