특정 시점 복구(PITR)란?

업데이트: 2026년 11월

특정 시점 복구는 베이스 백업 위에 변경 로그를 재생해 데이터베이스를 원하는 임의의 초 시점으로 재구성하는 복원 방식입니다. 이 기능이 대비하는 시나리오는 하드웨어 장애가 아닙니다. 그것은 복제가 처리합니다. 대비하는 것은 사람의 실수입니다. 14:32에 행을 손상시킨 마이그레이션, 엉뚱한 테넌트를 삭제한 스크립트 같은 것들입니다. PITR이 내놓는 답은 유일하게 도움이 되는 것, 즉 14:31:59 시점 그대로의 데이터베이스입니다.

핵심 요약

질문답변
스냅샷사진 – 복원은 촬영한 순간에 도달
PITR베이스 백업 + 재생된 변경 로그 – 복원은 임의의 초에 도달
RPO잃어도 되는 최근 데이터의 양 – 수집 빈도로 결정
RTO복원에 걸려도 되는 시간 – 크기와 방식으로 결정
역할 분담BaaS가 메커니즘을 운영하고, 목표와 훈련은 여전히 사용자의 몫

한 번의 작업 세션으로 보는 메커니즘

-- 변경 로그가 원재료입니다: 커밋된 모든 쓰기가 순서대로 담깁니다.
-- 위험한 작업 전에는 이름 붙은 마커를 로그에 남길 수 있습니다:
SELECT pg_create_restore_point('before_pricing_migration');

-- 복구 = 베이스 백업 + 재생, 지정한 지점에서 중지:
--   02:00에 만든 베이스 백업을 복원하고
--   로그를 앞으로 재생한 뒤…
--   …손상 직전에서 멈춥니다:
--     recovery_target_time = '2026-08-05 14:31:59+00'
--     (또는 recovery_target_name = 'before_pricing_migration')

-- 대상 이전에 커밋된 것은 모두 존재하고, 이후의 것은 존재하지 않습니다.

여기서 선행 기록 로그(WAL)는 두 가지 역할을 합니다. 트랜잭션에 지속성을 부여하는 바로 그 순서 있는 기록이, 지속적으로 아카이빙되면 타임머신이 됩니다. 문서 데이터베이스는 oplog로 똑같은 방식을 씁니다. 연산 스트림을 수집하고, 스냅샷 위에 재생하고, 원할 때 멈춥니다(PostgreSQL은 이를 continuous archiving이라고 부르며, MongoDB는 파일 시스템 스냅샷 위에서 같은 아키텍처를 문서화합니다).

어떤 복원이든 그 뒤의 훈련 검증 단계는 애플리케이션 수준입니다. 타임라인이 의도한 곳에 도달했는지 확인합니다:

// JavaScript / Node.js — Back4app JS SDK
// Restore drill: verify the restored data lines up with the incident timeline
const incident = new Date('2026-08-05T14:32:00Z'); // when the bad deploy hit

const latest = new Parse.Query('Order');
latest.lessThan('createdAt', incident);
latest.descending('createdAt');
const lastGood = await latest.first();   // newest order before the incident

const after = new Parse.Query('Order');
after.greaterThanOrEqualTo('createdAt', incident);
const leaked = await after.count();      // must be 0 on a clean PITR restore

console.log(`last good write: ${lastGood?.get('createdAt')}`);
console.log(`rows past the recovery target: ${leaked}`);

복원이 14:31:59에 도달하는 방식

특정 시점 복구 흐름야간 베이스 백업을 복원한 다음, 아카이빙된 변경 로그를 장애 직전으로 설정된 복구 대상까지 순서대로 앞으로 재생해, 선택한 초 시점의 데이터베이스 상태를 만듭니다.

대상에서 중지:
14:31:59

재생되지 않음

베이스 백업
(02:00 스냅샷)

아카이빙된 로그 재생
02:00 → …

지속적인 로그 수집
(WAL / oplog)

선택한 초 시점의
데이터베이스

14:32 장애
(잘못된 마이그레이션)

야간 베이스 백업을 복원한 다음, 아카이빙된 변경 로그를 장애 직전으로 설정된 복구 대상까지 순서대로 앞으로 재생해, 선택한 초 시점의 데이터베이스 상태를 만듭니다.

이 메커니즘에서 두 가지 속성이 나옵니다. 첫째, RPO는 수집 빈도로 정해집니다. 로그를 몇 초마다 전송하면 마지막 스냅샷이 언제 실행되었든 최대 손실은 몇 초입니다. 둘째, RTO는 재생 거리로 정해집니다. 02:00 베이스에서 23:00으로 복원하려면 21시간 분량의 쓰기를 재생해야 합니다. PITR 시스템이 여전히 스냅샷을 자주 찍는 이유가 이것입니다. 세분성 때문이 아니라 재생 거리를 줄이기 위해서입니다.

스냅샷 vs. PITR

기준스냅샷만 사용PITR(베이스 + 로그 재생)
복원 세분성스냅샷이 실행된 순간보존 기간 안의 임의의 초
일반적인 RPO몇 시간(일정 간격)몇 초에서 몇 분
스토리지 비용낮음 – n개의 사본더 높음 – 사본 + 지속적인 로그 아카이브
복원 속도빠름 – 다시 복사더 느림 – 복사 + 재생
사람의 실수 대응마지막 스냅샷 이후 전부 손실오류 이전의 데이터는 거의 손실 없음
복잡성최소상당함 – 아카이빙, 순서, 대상

실제로 필요한 복구 보장은 무엇일까?

이만큼 잃어도 버틸 수 있다면…필요한 것주의할 점
하루치 쓰기야간 스냅샷보존 기간
한 시간스냅샷 + 잦은 증분 백업일정이 실제로 실행되는지
몇 분 이하지속적인 로그 수집(PITR)아카이브 지연 – 그것이 곧 RPO
절대 아무것도PITR + 동기식 복제비용과 쓰기 지연 시간, 솔직하게 책정

일반적인 사용 사례

  • 잘못된 배포. 마이그레이션이나 핫픽스가 오후 중간에 데이터를 손상시킵니다. 배포 직전의 초로 복원합니다.
  • 실수로 인한 삭제. 엉뚱한 테넌트, 컬렉션, WHERE 절. 해당 문이 실행되기 직전으로 복구하며, 잃어버린 것만 추출하기 위해 임시 데이터베이스로 복원하는 경우가 많습니다.
  • 랜섬웨어와 계정 침해. 침입이 데이터에 닿기 전으로 되감습니다. 아카이브 사본 자체는 저장 데이터 암호화가 보호합니다.
  • 컴플라이언스 보존. 규제 대상 제품은 복구 가능성을 증명해야 합니다. 문서화된 보존 기간, 테스트된 복원, 감사 가능한 훈련이 필요합니다.
  • 출시 전 리허설. 기능 게이트로서의 복원 훈련입니다. 특정 타임스탬프로 한 번이라도 복원해 본 팀은 정말 중요한 밤에도 침착하게 해냅니다.

기본 제공 백업에 의존해도 될까? 결정 매트릭스

기본값으로 충분할 때…그 이상에 투자해야 할 때…
하루치 데이터를 잃는 것이 치명적이지 않고 번거로운 정도일 때쓰기가 곧 돈일 때 – 주문, 원장, 예약
제품이 출시 전이거나 내부용일 때한 시간의 손실이 고객 지원의 재앙일 때
다른 출처에서 데이터를 다시 만들 수 있을 때데이터베이스가 유일한 진실의 원천일 때
아무도 복구 보장을 요구하지 않았을 때계약이나 규제 기관이 RPO/RTO 수치를 명시할 때
복원이 필요했던 적이 한 번도 없을 때필요했던 적이 있고, 그때 긴박했을 때

플랫폼이 무엇을 제공하든 세 가지 결정은 사용자의 몫으로 남습니다. 제품이 버틸 수 있는 RPO, 사용자가 견딜 수 있는 RTO, 그리고 두 숫자를 정직하게 유지하는 훈련 주기입니다. NIST의 비상 계획 지침은 이 규율을 목표를 정의하고 그 목표에 맞춰 테스트하는 것으로 공식화합니다.

한계와 트레이드오프

  • 복제는 복구가 아닙니다. 복제본은 몇 초 안에 실수까지 복제하며, 오직 백업만이 실수 이전에 도달합니다. 도구가 다르고, 대응하는 장애 유형도 다릅니다.
  • 보존 기간에는 끝이 있습니다. PITR은 보존 기간 안의 어떤 초에도 도달합니다. 기간이 끝난 뒤에 발견된 손상은 영구적이므로, 보존 기간은 스토리지 가격만이 아니라 감지에 걸리는 시간에 맞춰 정해야 합니다.
  • 재생에는 시간이 걸립니다. 로그가 많은 복원은 오래 걸릴 수 있습니다. 실제 RTO는 대시보드가 제시하는 수치가 아니라 훈련으로 측정됩니다.
  • 복원은 통째로 이루어집니다. 전통적인 PITR은 데이터베이스 전체를 특정 타임스탬프로 재구성합니다. 한 테이블의 잃어버린 행만 추출하려면 임시 인스턴스로 복원한 뒤 복사해 와야 하므로, 그 워크플로를 미리 계획해야 합니다.
  • 테스트하지 않은 백업은 소문일 뿐입니다. 조용한 내보내기 실패, 만료된 자격 증명, 누락된 런북은 모두 훈련이나 재해가 찾아낼 때까지 보이지 않습니다. 훈련이 더 저렴합니다.

Back4app에서의 PITR과 백업

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 관리형 데이터베이스의 백업은 별도 설정 없이 일정에 따라 실행되고, 복원은 밤새 로그를 발굴하는 작업이 아니라 대시보드에서 하는 작업입니다. 이 글에서 다룬 스냅샷과 메커니즘의 절반을 플랫폼이 흡수하는 것입니다. 사용자에게 남는 절반은 결정입니다. RPO와 RTO 목표, 보존 기간 요구 사항, 그리고 위의 코드 탭으로 복원된 타임라인이 요청한 바로 그 시점인지 검증하는 분기별 훈련입니다.

자주 묻는 질문

특정 시점 복구를 쉽게 설명하면 무엇입니까?

예약된 백업 시각뿐 아니라 어떤 순간에도 도달할 수 있는 복원입니다. 엔진은 베이스 백업에서 시작해 변경 로그, 즉 커밋된 모든 쓰기를 순서대로 재생하고, 지정한 초에서 멈춥니다. 어젯밤 스냅샷 이후의 모든 것을 잃는 대신, 장애 직전의 초인 14:31:59 이후에 일어난 일만 잃습니다.

스냅샷과 PITR의 차이는 무엇입니까?

세분성입니다. 스냅샷은 사진입니다. 복원하면 사진을 찍은 순간에 정확히 도달하고, 그 이후의 모든 것은 사라집니다. PITR은 영화입니다. 베이스 백업과 지속적인 로그 수집 덕분에 보존 기간 안의 어디에서든 재생을 멈출 수 있습니다. 스냅샷은 더 단순하고 보관 비용이 저렴하며, PITR은 복구의 질문을 "어느 날 밤?"에서 "몇 초?"로 바꿉니다.

RPO와 RTO란 무엇입니까?

모든 백업 논의가 사실은 다루고 있는 두 숫자입니다. RPO(복구 시점 목표)는 최근 데이터를 얼마나 잃어도 감당할 수 있는지를 나타내며, 백업이나 로그 전송 빈도로 정해집니다. RTO(복구 시간 목표)는 복원에 얼마나 걸려도 되는지를 나타내며, 데이터 크기와 복원 방식으로 정해집니다. 일일 스냅샷의 RPO는 몇 시간이고, 지속적인 로그 수집은 이를 몇 초 수준까지 줄입니다.

복제가 백업을 대체합니까?

아니요. 복제는 가용성을 위한 것이지 복구를 위한 것이 아닙니다. 복제본은 실수로 실행한 DROP TABLE까지 포함해 프라이머리가 하는 모든 일을 충실히 복사하며, 몇 초 안에 모든 사본에 같은 손상이 반영됩니다. 백업과 PITR은 바로 오류 이전의 상태에 도달하기 위해 존재하며, 복제를 아무리 늘려도 그 상태는 보존되지 않습니다. 서로 다른 장애 유형을 위해 둘 다 필요합니다.

백업은 얼마나 자주 실행해야 합니까?

RPO에서 거꾸로 계산해야 합니다. 하루치 쓰기를 잃어도 버틸 수 있다면 야간 스냅샷으로 충분하고, 한 시간도 아프다면 더 잦은 증분 백업을 추가해야 하며, 몇 분이 중요하다면 지속적인 로그 수집이 필요합니다. 그 단계에서는 스냅샷 빈도가 데이터 손실이 아니라 복원 속도를 좌우합니다. 일정이 어떻든, 실수를 얼마나 먼 과거까지 바로잡을 수 있는지는 보존 기간이 결정합니다.

복원 훈련은 왜 중요합니까?

테스트하지 않은 백업은 계획이 아니라 가설이기 때문입니다. 훈련은 실제로 해 봐야만 드러나는 실패를 찾아냅니다. 조용히 깨진 내보내기, RTO는 한 시간인데 아홉 시간이 걸리는 복원, 누락된 자격 증명, 문서화되지 않은 단계 같은 것들입니다. 임시 환경으로 복원하고, 데이터를 검증하고, 과정에 걸린 시간을 재는 분기별 훈련이 가설을 연습된 절차로 바꿉니다.

데이터베이스를 복원한 뒤에는 무엇을 확인해야 합니까?

먼저 타임라인을 검증합니다. 가장 최근 레코드가 복구 대상 시점 바로 앞에 있어야 하고, 그 이후의 것은 없어야 합니다. 다음으로 무결성을 검증합니다. 예상과 비교한 행 수, 핵심 불변 조건, 끊기지 않고 연결되어야 하는 참조를 확인합니다. 마지막으로 애플리케이션을 검증합니다. 로그인하고, 핵심 흐름을 실행하고, 백그라운드 작업이 깔끔하게 재개되는지 확인합니다. "완료된" 복원도 이 세 가지 모두에서 틀릴 수 있습니다.

BaaS에서 백업은 누가 담당합니까? 플랫폼입니까, 사용자입니까?

메커니즘은 플랫폼의 몫입니다. 스냅샷, 로그 수집, 스토리지, 복원 도구가 그것입니다. 목표는 여전히 사용자의 몫입니다. 제품에 맞는 RPO와 RTO를 정하고, 보존 기간을 파악하고, 복원 훈련을 실행하고, 정책이 요구한다면 독립적인 내보내기를 보관하는 일입니다. 관리형 백엔드는 연결 작업을 없애 줄 뿐, 감당 가능한 손실이 어느 정도인지 결정할 책임까지 없애 주지는 않습니다.

관련 용어

비교 대상

참고 자료

백엔드를 구축할 준비가 되셨나요?

몇 분 안에 Back4app에서 프로젝트를 시작하세요. 데이터베이스, 인증, API, Cloud Code가 포함되어 있으며 신용카드는 필요 없습니다.

작성 및 검수: Back4app Engineering, Back4app Engineering · 게시일 2026-11-03