RTO와 RPO란? 백업 정책을 세울 때 꼭 알아야 할 복구 기준

백업을 공부하다 보면 풀백업, 증분백업, 차등백업처럼 백업 방식 자체에 먼저 관심을 갖게 됩니다. 하지만 실제로 백업 정책을 만들 때는 “어떤 방식으로 백업할 것인가?”보다 먼저 정해야 할 기준이 있습니다.

바로 RTO와 RPO입니다.

RTO와 RPO는 장애나 랜섬웨어 감염, 서버 고장, 데이터 삭제 같은 사고가 발생했을 때 “얼마나 빨리 복구해야 하는지”와 “어느 시점까지의 데이터 손실을 허용할 수 있는지”를 정하는 복구 기준입니다.

백업 파일이 많아도 RTO와 RPO를 정하지 않으면 실제 사고가 났을 때 복구 우선순위가 흔들릴 수 있습니다. 반대로 RTO와 RPO를 먼저 정하면 백업 주기, 저장 위치, 복구 절차, 스토리지 구성, 클라우드 백업 여부를 훨씬 체계적으로 결정할 수 있습니다.

이번 글에서는 RTO와 RPO의 뜻, 차이점, 백업 정책에 적용하는 방법, 랜섬웨어 대비 시 고려할 점까지 쉽게 정리해보겠습니다.

RTO와 RPO를 먼저 알아야 하는 이유

백업의 목적은 단순히 데이터를 저장하는 것이 아니라 필요할 때 복구하는 것입니다. 그런데 복구에는 두 가지 질문이 따라옵니다.

• 서비스나 업무를 언제까지 다시 사용할 수 있어야 하는가?
• 데이터는 어느 시점까지 되돌릴 수 있어야 하는가?

첫 번째 질문이 RTO이고, 두 번째 질문이 RPO입니다.

예를 들어 쇼핑몰 주문 데이터가 1시간만 사라져도 큰 손실이 발생한다면 RPO를 짧게 잡아야 합니다. 반대로 개인 사진 보관함처럼 하루에 한 번만 백업해도 충분한 데이터라면 RPO가 길어도 괜찮을 수 있습니다.

또한 회사의 핵심 업무 시스템이 30분 이상 멈추면 업무가 마비된다면 RTO를 짧게 잡아야 합니다. 반면 오래된 문서 보관 서버처럼 하루 뒤에 복구되어도 큰 문제가 없다면 RTO를 길게 잡을 수 있습니다.

즉 RTO와 RPO는 백업 정책의 출발점입니다.

RTO란?

RTO는 Recovery Time Objective의 약자입니다. 한국어로는 보통 복구 시간 목표라고 합니다.

RTO는 장애가 발생한 뒤 서비스나 시스템을 다시 사용할 수 있는 상태로 복구하기까지 허용 가능한 최대 시간을 의미합니다.

쉽게 말하면 다음 질문에 대한 답입니다.

“장애가 발생했을 때 몇 시간 안에 다시 사용 가능해야 하는가?”

예를 들어 RTO가 4시간이라면, 서버 장애가 발생했을 때 4시간 안에는 서비스를 다시 사용할 수 있어야 합니다. RTO가 30분이라면 30분 안에 복구되어야 하므로 훨씬 빠른 복구 체계가 필요합니다.

RTO가 짧을수록 필요한 기술과 비용은 증가합니다. 단순 백업 파일을 수동으로 복원하는 방식으로는 10분 이내 복구가 어렵기 때문입니다. 짧은 RTO를 원한다면 자동화된 복구 절차, 대기 서버, 이중화, 클라우드 재해복구, 복구 테스트가 필요할 수 있습니다.

RPO란?

RPO는 Recovery Point Objective의 약자입니다. 한국어로는 보통 복구 시점 목표라고 합니다.

RPO는 장애가 발생했을 때 허용 가능한 최대 데이터 손실 시간을 의미합니다.

쉽게 말하면 다음 질문에 대한 답입니다.

“장애가 발생했을 때 몇 시간 전 데이터까지는 잃어도 되는가?”

예를 들어 RPO가 24시간이라면 하루 전 백업본으로 복구해도 된다는 의미입니다. 반대로 RPO가 10분이라면 장애 발생 직전 10분 이내 데이터까지만 손실을 허용한다는 뜻입니다.

RPO는 백업 주기와 직접 연결됩니다. RPO를 24시간으로 잡았다면 최소 하루에 한 번은 백업해야 합니다. RPO를 1시간으로 잡았다면 최소 1시간 간격의 백업이나 스냅샷, 복제 구성이 필요할 수 있습니다.

RTO와 RPO 차이점 한눈에 보기

RTO와 RPO는 모두 복구 기준이지만 보는 방향이 다릅니다. RTO는 장애 이후의 복구 시간을 보고, RPO는 장애 이전의 데이터 손실 범위를 봅니다.

구분	RTO	RPO
의미	복구 시간 목표	복구 시점 목표
핵심 질문	얼마나 빨리 복구해야 하는가?	얼마나 적은 데이터 손실을 허용할 것인가?
기준 방향	장애 발생 이후의 시간	장애 발생 이전의 데이터 시점
영향 요소	복구 절차, 서버 준비 상태, 자동화, 인력	백업 주기, 복제 주기, 스냅샷 주기
예시	4시간 안에 서비스 복구	1시간 전 데이터까지만 손실 허용
짧아질수록	복구 인프라 비용과 운영 난이도 증가	백업 빈도와 저장 비용 증가

간단히 정리하면 RTO는 “복구 완료까지 걸리는 시간”이고, RPO는 “복구했을 때 데이터가 얼마나 과거 시점으로 돌아가는지”입니다.

RTO와 RPO 예시로 이해하기

예를 들어 회사의 파일 서버가 오후 3시에 랜섬웨어에 감염되었다고 가정해보겠습니다.

• 마지막 정상 백업 시점: 오후 1시
• 복구 완료 시점: 오후 7시
• 장애 발생 시점: 오후 3시

이 경우 데이터는 오후 1시 시점으로 복구됩니다. 오후 1시부터 오후 3시까지의 데이터는 손실될 수 있습니다. 이 데이터 손실 범위가 RPO와 관련됩니다.

그리고 오후 3시에 장애가 발생해 오후 7시에 복구가 끝났다면 복구에 4시간이 걸린 것입니다. 이 복구 시간이 RTO와 관련됩니다.

따라서 같은 사고라도 RTO와 RPO는 서로 다른 문제를 설명합니다.

• RTO: 오후 3시부터 오후 7시까지, 즉 복구에 걸린 4시간
• RPO: 오후 1시부터 오후 3시까지, 즉 손실될 수 있는 2시간 분량의 데이터

RPO는 백업 주기를 결정한다

RPO를 정하면 백업 주기를 정하기 쉬워집니다. 허용 가능한 데이터 손실 시간이 짧을수록 백업을 더 자주 해야 합니다.

RPO 목표	필요한 백업 방식	적합한 데이터 예시
24시간	일 1회 백업	개인 문서, 블로그 자료, 자주 바뀌지 않는 파일
12시간	일 2회 백업	소규모 업무 파일, 일반 사내 공유 폴더
1시간	시간 단위 증분백업 또는 스냅샷	업무 문서 서버, 게시판, 내부 시스템
15분 이하	짧은 주기의 백업, 로그 백업, 복제	주문 데이터, 예약 데이터, 업무 핵심 DB
거의 0	실시간 복제, 고가용성 구성	금융, 결제, 핵심 거래 시스템

백업 방식이 헷갈린다면 풀백업과 증분백업 차이점 글을 함께 보면 이해하기 쉽습니다. RPO가 짧아질수록 전체 데이터를 매번 복사하는 방식보다 증분백업, 차등백업, 스냅샷, 복제 같은 방식을 조합해야 할 가능성이 높아집니다.

RTO는 복구 방식을 결정한다

RTO는 장애 발생 후 얼마나 빨리 다시 사용할 수 있어야 하는지를 정합니다. 따라서 RTO는 복구 방식과 인프라 구조에 큰 영향을 줍니다.

RTO 목표	가능한 복구 방식	특징
1~2일	수동 복구	비용은 낮지만 복구 시간이 길 수 있음
8시간	준비된 백업 장비와 절차 기반 복구	소규모 회사에서 현실적인 목표
4시간	자동화된 복구 절차, 사전 준비된 서버	업무 핵심 시스템에 적합
1시간 이하	대기 서버, 복제, 빠른 장애 전환	운영 비용과 관리 난이도가 높음
수분 이내	고가용성, 이중화, 자동 failover	중요 서비스에 필요하지만 비용이 큼

RTO를 짧게 잡으면 백업 파일만으로는 부족할 수 있습니다. 서버 운영체제, 애플리케이션 설치 파일, 계정 정보, 네트워크 설정, 데이터베이스 복구 절차까지 미리 준비해야 합니다.

리눅스 서버와 윈도우 서버의 차이를 기준으로 복구 환경을 고민하고 있다면 리눅스 서버와 윈도우 서버 차이점 글도 참고하면 좋습니다.

RTO와 RPO를 동시에 봐야 하는 이유

RTO와 RPO는 따로 정하는 것 같지만 실제로는 함께 봐야 합니다.

예를 들어 RPO가 10분으로 매우 짧아도 RTO가 2일이라면 데이터 손실은 적지만 서비스를 오래 사용할 수 없습니다. 반대로 RTO가 30분으로 짧아도 RPO가 24시간이라면 빠르게 복구되더라도 하루치 데이터가 사라질 수 있습니다.

따라서 중요한 시스템일수록 다음 두 가지를 함께 판단해야 합니다.

• 업무가 멈춰도 되는 시간은 얼마인가?
• 잃어도 되는 데이터 시간은 얼마인가?

이 두 질문에 대한 답이 백업 정책과 재해복구 전략의 기준이 됩니다.

RTO와 RPO에 따른 백업 정책 예시

아래는 데이터 중요도에 따라 RTO와 RPO를 나누는 예시입니다. 실제 환경에서는 회사 규모, 업무 중요도, 예산, 규정, 고객 영향도를 함께 고려해야 합니다.

구분	데이터 예시	RPO 예시	RTO 예시	관리 수준
낮음	오래된 참고 자료, 아카이브 문서	1주일	2~3일	저비용 보관
보통	일반 업무 문서, 부서 공유 폴더	24시간	1일	일 단위 백업
중요	업무 시스템, 파일 서버, 그룹웨어	1~4시간	4~8시간	증분백업과 복구 절차 준비
매우 중요	주문 DB, 결제 DB, 고객 서비스	수분~15분	1시간 이하	복제, 이중화, 빠른 장애 전환

처음부터 모든 데이터를 가장 높은 수준으로 보호하려고 하면 비용이 지나치게 커질 수 있습니다. 따라서 데이터 중요도에 따라 등급을 나누고, 각 등급별로 RTO와 RPO를 다르게 설정하는 것이 현실적입니다.

RTO와 RPO를 정하는 방법

RTO와 RPO는 단순히 IT 담당자가 임의로 정하는 숫자가 아닙니다. 실제 업무 영향도를 기준으로 정해야 합니다.

1. 데이터와 시스템 목록을 만든다

먼저 보호해야 할 데이터와 시스템을 목록으로 정리합니다. 예를 들어 파일 서버, 홈페이지, 데이터베이스, 회계 자료, 고객 자료, 이미지 파일, 백업 서버 등을 구분합니다.

2. 업무 영향도를 평가한다

각 시스템이 멈췄을 때 어떤 문제가 생기는지 확인합니다. 매출 손실, 고객 불편, 법적 문제, 업무 중단, 이미지 손상 등을 기준으로 중요도를 나눌 수 있습니다.

3. 허용 가능한 데이터 손실 시간을 정한다

이 단계에서 RPO를 정합니다. 하루치 데이터가 사라져도 되는지, 1시간치만 허용되는지, 거의 손실이 없어야 하는지를 판단합니다.

4. 허용 가능한 중단 시간을 정한다

이 단계에서 RTO를 정합니다. 몇 시간 안에 시스템이 다시 사용 가능해야 하는지 정합니다.

5. 비용과 현실성을 검토한다

RTO와 RPO를 짧게 잡을수록 비용과 운영 난이도는 증가합니다. 그래서 모든 시스템에 같은 기준을 적용하기보다 중요도에 따라 목표를 다르게 잡는 것이 좋습니다.

6. 실제 복구 테스트로 검증한다

문서상 RTO가 4시간이어도 실제 복구에 8시간이 걸리면 의미가 없습니다. 반드시 복구 테스트를 통해 목표 시간이 현실적인지 확인해야 합니다.

RTO와 RPO가 백업 저장소 선택에 미치는 영향

RTO와 RPO는 백업 데이터를 어디에 저장할지에도 영향을 줍니다.

RTO가 길고 RPO도 길어도 되는 데이터라면 저렴한 장기 보관 스토리지나 아카이브 스토리지를 사용할 수 있습니다. 반대로 RTO가 짧아야 하는 데이터라면 복구 속도가 빠른 스토리지나 대기 서버가 필요할 수 있습니다.

저장소	장점	주의점
외장 HDD/SSD	비용이 낮고 개인 사용자가 쓰기 쉬움	분실, 고장, 오프라인 관리 필요
NAS	여러 사용자가 함께 백업하기 좋음	랜섬웨어 감염 시 함께 공격받을 수 있음
클라우드 백업	외부 보관과 확장성이 좋음	복구 속도와 비용, 계정 보안 확인 필요
오브젝트 스토리지	대용량 백업과 이뮤터블 보관에 적합	설정과 권한 관리가 중요함
테이프/오프라인 보관	장기 보관과 랜섬웨어 격리에 유리	복구 속도가 느릴 수 있음

백업 저장소별 차이는 백업 스토리지 기술 글에서 더 자세히 정리했습니다.

RTO, RPO와 3-2-1 백업 원칙

3-2-1 백업 원칙은 중요한 데이터의 복사본을 3개 유지하고, 2가지 저장 매체에 나누어 보관하며, 1개는 외부 장소에 두는 백업 전략입니다.

RTO와 RPO는 3-2-1 백업 원칙을 실제 정책으로 바꾸는 기준이 됩니다.

• RPO가 짧으면 백업 주기를 더 자주 가져가야 합니다.
• RTO가 짧으면 복구 가능한 환경을 미리 준비해야 합니다.
• 중요 데이터는 외부 보관 백업과 이뮤터블 백업을 함께 고려해야 합니다.
• 백업이 실제로 복구되는지 정기적으로 테스트해야 합니다.

백업 복사본을 어떻게 배치할지 정할 때는 3-2-1 백업 원칙을 함께 적용하면 좋습니다.

랜섬웨어 대비에서 RTO와 RPO가 중요한 이유

랜섬웨어 사고에서는 RTO와 RPO가 특히 중요합니다. 랜섬웨어는 원본 파일만 암호화하는 것이 아니라 백업 파일, 스냅샷, 네트워크 공유 폴더까지 공격할 수 있기 때문입니다.

랜섬웨어 감염 후에는 단순히 가장 최근 백업으로 복구하면 되는 것이 아닙니다. 그 백업 시점이 이미 감염된 상태였을 수도 있고, 백업 계정이 탈취되어 백업본이 삭제되었을 수도 있습니다.

따라서 랜섬웨어 대비 백업 정책에서는 다음을 함께 고려해야 합니다.

• 감염 이전의 정상 복구 지점을 확보해야 합니다.
• 백업본이 삭제되지 않도록 이뮤터블 백업을 고려해야 합니다.
• 오프라인 또는 외부 보관 백업을 유지해야 합니다.
• 복구 후 재감염을 막기 위해 원인 분석과 보안 점검이 필요합니다.
• 복구 시간이 업무 허용 범위 안에 들어오는지 테스트해야 합니다.

랜섬웨어의 기본 흐름은 랜섬웨어 대응 전략 글에서 확인할 수 있고, 백업 삭제 방지 개념은 변경 불가 백업 글과 함께 보면 좋습니다.

스냅샷과 RPO의 관계

스냅샷은 특정 시점의 데이터 상태를 빠르게 저장하는 기술입니다. 스토리지나 가상화 환경에서 자주 사용되며, 짧은 RPO를 만들 때 도움이 될 수 있습니다.

예를 들어 1시간마다 스냅샷을 생성하면 장애 발생 시 최대 1시간 전 상태로 되돌릴 수 있습니다. 이 경우 RPO를 1시간에 가깝게 구성할 수 있습니다.

하지만 스냅샷이 백업을 완전히 대체하는 것은 아닙니다. 스냅샷이 원본 스토리지에만 존재한다면 스토리지 장애나 랜섬웨어 공격에 함께 영향을 받을 수 있습니다.

스냅샷의 원리와 한계는 스냅샷의 원리 글을 참고하면 좋습니다.

백업과 아카이브에서 RTO와 RPO는 다르게 적용된다

백업과 아카이브는 목적이 다릅니다. 백업은 장애나 삭제 상황에서 복구하기 위한 것이고, 아카이브는 오래 보관해야 하는 데이터를 장기 저장하는 목적이 강합니다.

따라서 백업 데이터는 RTO와 RPO가 중요하지만, 아카이브 데이터는 보존 기간, 검색 가능성, 비용, 규정 준수가 더 중요할 수 있습니다.

구분	백업	아카이브
목적	장애 발생 시 복구	장기 보관과 기록 유지
RTO	중요하게 고려	상대적으로 길어도 되는 경우가 많음
RPO	업무 중요도에 따라 설정	보관 정책과 생성 시점이 중요
저장소	복구 속도와 안정성 중요	보관 비용과 내구성 중요

백업과 아카이브의 차이는 백업과 아카이브 전략의 통합 글과 함께 보면 이해하기 쉽습니다.

개인 사용자 기준 RTO와 RPO 예시

개인 사용자는 기업처럼 복잡한 재해복구 체계를 만들기 어렵습니다. 하지만 중요한 자료별로 간단한 RTO와 RPO 기준을 정해두면 백업 습관을 만들기 좋습니다.

자료	RPO 예시	RTO 예시	추천 방식
블로그 글 초안	1일	반나절	클라우드 문서 + 외장 백업
가족 사진	1주일	1~2일	외장 HDD + 클라우드
업무 문서	1일 이하	반나절	클라우드 동기화 + 별도 백업
영상 원본	작업 당일	1~2일	외장 SSD + NAS 또는 클라우드

개인 사용자라면 처음부터 완벽한 시스템을 만들기보다, 중요한 자료부터 “어느 정도까지 잃어도 되는지”와 “언제까지 복구되어야 하는지”를 정해보는 것이 좋습니다.

소규모 회사 기준 RTO와 RPO 예시

소규모 회사는 백업 담당자나 전문 보안 인력이 부족한 경우가 많습니다. 그래서 너무 복잡한 정책보다 실제로 지킬 수 있는 기준이 중요합니다.

시스템	RPO 예시	RTO 예시	추천 구성
파일 서버	4~24시간	4~8시간	NAS + 외부 백업
회계 자료	1일 이하	1일	일 단위 백업 + 월 단위 장기 보관
홈페이지	1일	4~8시간	웹 파일 + DB 백업
주문/예약 DB	15분~1시간	1~4시간	DB 백업 + 로그 백업 + 복제 검토
메일 자료	1일	1일	메일 서비스 백업 또는 보관 정책

소규모 회사에서 특히 중요한 것은 백업 담당자를 명확히 정하고, 백업 실패 여부를 주기적으로 확인하는 것입니다. 백업은 설정만 해두고 잊어버리면 사고 때 사용할 수 없는 경우가 많습니다.

RTO와 RPO 설정 시 자주 하는 실수

1. 모든 데이터를 같은 기준으로 백업한다

모든 데이터를 똑같이 매시간 백업하면 비용이 커지고 관리가 어려워집니다. 반대로 모든 데이터를 하루 한 번만 백업하면 중요한 데이터의 손실이 커질 수 있습니다. 데이터 중요도별로 등급을 나누는 것이 좋습니다.

2. RPO만 보고 RTO를 무시한다

백업을 자주 해도 복구 절차가 느리면 서비스 중단 시간이 길어집니다. 백업 주기뿐 아니라 실제 복구 시간이 얼마나 걸리는지도 확인해야 합니다.

3. 백업 성공 여부만 확인하고 복구 테스트를 하지 않는다

백업 작업이 성공했다고 해서 실제 복구가 성공한다는 보장은 없습니다. 일부 파일이 빠졌거나, 암호가 없거나, 복구 절차가 문서화되어 있지 않으면 사고 때 문제가 생길 수 있습니다.

4. 너무 낮은 RTO와 RPO를 목표로 잡는다

RTO와 RPO를 0에 가깝게 잡으면 비용과 복잡도가 크게 증가합니다. 핵심 시스템이 아니라면 업무 영향도와 비용을 고려해 현실적인 목표를 잡는 것이 좋습니다.

5. 랜섬웨어 감염 시점을 고려하지 않는다

랜섬웨어는 감염 후 바로 드러나지 않을 수 있습니다. 가장 최근 백업도 이미 감염된 상태일 수 있으므로 여러 시점의 백업을 보관하고, 정상 복구 지점을 확인할 수 있어야 합니다.

RTO와 RPO 체크리스트

백업 정책을 만들거나 점검할 때 아래 항목을 확인해보면 좋습니다.

• 보호해야 할 데이터와 시스템 목록이 있는가?
• 데이터별 중요도 등급을 나누었는가?
• 각 시스템의 RTO를 정했는가?
• 각 데이터의 RPO를 정했는가?
• RPO에 맞는 백업 주기가 설정되어 있는가?
• RTO 안에 복구 가능한 절차가 준비되어 있는가?
• 백업 저장소가 원본 시스템과 분리되어 있는가?
• 랜섬웨어 대비용 오프라인 또는 이뮤터블 백업이 있는가?
• 복구 테스트를 정기적으로 수행하고 있는가?
• 복구 담당자와 연락 체계가 정리되어 있는가?
• 백업 계정과 관리자 계정에 다중 인증을 적용했는가?
• 복구에 필요한 암호와 문서가 안전하게 보관되어 있는가?

이 체크리스트에서 빈 항목이 많다면 백업 파일이 있더라도 실제 장애 상황에서는 복구가 어려울 수 있습니다. 특히 RTO와 RPO는 숫자로 정해두고, 복구 테스트로 검증하는 것이 중요합니다.

자주 묻는 질문

Q1. RTO와 RPO 중 무엇이 더 중요한가요?

둘 다 중요합니다. RTO는 복구 시간, RPO는 데이터 손실 범위를 의미합니다. 서비스 중단이 더 큰 문제인지, 데이터 손실이 더 큰 문제인지에 따라 우선순위가 달라질 수 있습니다.

Q2. RPO가 짧으면 무조건 좋은가요?

항상 그렇지는 않습니다. RPO가 짧을수록 백업 주기와 저장 비용, 운영 복잡도가 증가합니다. 중요한 데이터는 짧게 잡되, 중요도가 낮은 데이터는 현실적인 기준을 정하는 것이 좋습니다.

Q3. RTO가 짧으면 백업만 잘하면 되나요?

아닙니다. RTO는 복구 시간과 관련되므로 백업 파일뿐 아니라 복구 장비, 서버 설정, 네트워크, 계정, 복구 절차, 담당자까지 준비되어 있어야 합니다.

Q4. 개인 사용자도 RTO와 RPO를 정해야 하나요?

전문 용어로 문서화할 필요까지는 없지만, 중요한 자료가 있다면 기준을 정해두는 것이 좋습니다. 예를 들어 사진은 주 1회 백업, 업무 문서는 매일 백업처럼 간단히 정해도 도움이 됩니다.

Q5. RPO와 백업 주기는 같은 뜻인가요?

비슷하게 연결되지만 완전히 같은 뜻은 아닙니다. RPO는 허용 가능한 데이터 손실 목표이고, 백업 주기는 그 목표를 달성하기 위한 방법입니다. RPO가 1시간이면 최소 1시간 이내 간격의 백업이나 복제 구성이 필요할 수 있습니다.

Q6. 랜섬웨어 대비에는 RTO와 RPO를 어떻게 잡아야 하나요?

업무 핵심 데이터는 RPO를 짧게 잡고, 여러 시점의 백업을 보관하는 것이 좋습니다. 또한 RTO 안에 복구하기 위해 정상 백업본 식별, 악성코드 제거, 시스템 재설치, 데이터 복구 절차를 미리 준비해야 합니다.

Q7. RTO와 RPO는 한 번 정하면 끝인가요?

아닙니다. 시스템 규모, 데이터 중요도, 서비스 이용자 수, 보안 위협, 예산이 바뀌면 RTO와 RPO도 다시 검토해야 합니다. 최소 분기별 또는 반기별로 점검하는 것이 좋습니다.

마무리

RTO와 RPO는 백업 정책을 세울 때 꼭 알아야 하는 복구 기준입니다. RTO는 장애 발생 후 얼마나 빨리 복구해야 하는지를 나타내고, RPO는 어느 시점까지의 데이터 손실을 허용할 수 있는지를 나타냅니다.

RPO는 백업 주기를 결정하고, RTO는 복구 방식과 인프라 준비 수준을 결정합니다. 따라서 백업 방식, 저장소, 스냅샷, 이뮤터블 백업, 클라우드 백업을 선택하기 전에 먼저 RTO와 RPO를 정하는 것이 좋습니다.

특히 랜섬웨어 시대에는 백업이 있다는 것만으로 충분하지 않습니다. 정상 복구 지점이 있는지, 백업본이 삭제되지 않는지, 실제로 목표 시간 안에 복구되는지를 함께 확인해야 합니다.

결국 좋은 백업 정책은 “많이 저장하는 것”이 아니라 “필요한 시점에 필요한 시간 안에 복구할 수 있는 것”입니다. 오늘 기준으로 중요한 데이터부터 RTO와 RPO를 정리해보는 것이 백업 전략의 첫 단계입니다.

참고 자료

• Microsoft Learn - Business Continuity, High Availability, and Disaster Recovery
• AWS Well-Architected - Disaster Recovery Objectives
• AWS Cloud Operations Blog - Establishing RPO and RTO Targets