RTO와 RPO : 차이점 이해

RTO 대 RPO – 차이점은 무엇입니까?

귀하의 생산 시스템과 필수 기능이 제대로 작동하는 한 귀하의 부서에서는 성공입니다. 그러나 특정 시점에서 허용할 수 없는 운영 중단이 발생하면 심각한 위협이 됩니다. 종종 경고가 거의 또는 전혀 없이 재난이 예기치 않게 발생합니다. 이는 위험 계산을 수행하고 복구 우선 순위를 설정하도록 촉구합니다. 이는 두 가지 모두의 필수 요소입니다. 비즈니스 연속성 과 재해 복구 (DR) 계획 프로세스.

중대한 장애 발생 시 시스템을 복구해야 하며 이를 무시할 수 없습니다. 잠재적인 중단 동안 회사의 데이터 손실 허용치를 반영하는 두 가지 중요한 결정은 다음과 같습니다. RTO (복구 시간 목표) 과 RPO (복구 지점 목표). RPO 대 RTO 목표는 비즈니스 연속성에 맞춰 설정되어야 합니다. 이러한 매개변수는 백업 실행 예약 빈도를 결정하는 데 핵심적인 역할을 하는 필수 비즈니스 메트릭입니다.

RPO와 RTO 의미는 서로 관련되어 있지만 회사의이 두 구성 요소는 참사 복구 계획 및 비즈니스 연속성 전략은 핵심 목표, 목적, 데이터 우선 순위 및 사용이 다릅니다. 재해가 발생하는 동안 가동 중지 시간이 XNUMX분마다 수천 달러의 수익 손실이 발생하고 비즈니스에 대한 고객의 신뢰가 서서히 저하될 수 있습니다. 이제부터 견고한 재해 복구 RTO 대 RPO 전략을 구축하려면 RTO, RPO 및 그 차이점을 이해하는 것이 중요합니다. RTO 및 RPO 값을 사용하여 솔리드를 개발할 수 있습니다. 재해 복구 과 사업 연속성 계획 기업에서 함께 마련해야하는 위험, 복구 요구 및 백업 솔루션을 간략하게 설명합니다.

RTO 설명

조직에서 재해 발생 후 애플리케이션과 프로세스를 복구하는 데 걸리는 목표 시간을 RTO(복구 시간 목표)라고 합니다. 복구 타임라인은 비즈니스의 다운타임 허용 수준을 결정하는 중요한 매개변수입니다. RTO는 "재해 발생 후 심각한 비즈니스 손실과 고객의 분노를 일으키지 않고 애플리케이션을 가동 중지하고 다시 실행할 수 있는 시간"이라는 질문에 답합니다. 이 주요 지표는 복구와 허용 가능한 데이터 손실 사이의 기간을 계산하는 데 도움이 될 수 있습니다.

그러나 RTO의 목표는 재해 발생과 복구 사이의 기간을 결정하는 것만이 아닙니다. 또한 IT 팀이 응용 프로그램 및 데이터를 복원하기 위해 수행해야 하는 복구 단계를 정의합니다. IT가 우선 순위가 높은 애플리케이션을 복구하기 위해 장애 조치 서비스에 투자했다면 단 몇 초 만에 RTO를 달성할 수 있습니다.

비즈니스 애플리케이션의 우선 순위를 기반으로 RTO를 계산하려면 RTO를 가능한 한 정확하게 만드는 것이 중요합니다.

• XNUMX에 가까운 RTO : 미션 크리티컬 애플리케이션을위한 장애 조치 서비스 필요
• 4 시간의 RTO : 완전 애플리케이션 및 데이터 가용성으로 끝나는 베어 메탈 복원에서 온 프레미스 복구
• 8 시간 이상의 RTO : 비즈니스에 심각한 피해를주지 않고 며칠 동안 중단 될 수있는 비 필수 애플리케이션 용

• 가능한 최소 복원 시간이 2 시간이면 XNUMX 시간의 RTO를 충족 할 수 없습니다.
• 또 다른 경우, RTO를 4시간으로 설정하고 오후 12시에 시스템 오류가 발생하면 서버가 수리되어 오후 4시에 가동되어 목표 RTO가 충족됨을 의미합니다.
• RTO를 2 주로 설정하면 중단이 발생한 후 데이터를 복구 할 시간이 충분하므로 투자 비용이 훨씬 적습니다.

RPO 설명

간단히 말해서 RPO(복구 시점 목표)는 비즈니스에서 손실을 감당할 수 있는 데이터의 양이며 비즈니스에 심각한 피해를 입히지 않고 계속 작동할 수 있습니다. RPO는 다운타임 동안 허용 가능한 데이터 손실 허용 기간으로 비즈니스 연속성을 보장합니다. 회사에서 "허용 가능한" 시간을 정의하는 것은 비즈니스 연속성 계획에서 매우 중요합니다. RPO가 길수록 다운타임 연장으로 인한 데이터 손실 가능성이 커집니다. RPO는 "기업이 손실을 감당할 수 있는 데이터의 양은 얼마입니까?"라는 질문에 답하려고 합니다. 즉, RPO는 비즈니스 운영을 정상으로 재개하기 위해 복구해야 하는 데이터의 수명을 결정합니다.

RPO는 재해 복구 (DR) 계획. 따라서 데이터의 중요도를 평가하여 복구해야 할 애플리케이션, 프로세스 또는 정보를 결정하는 것이 중요합니다. 중요도 수준에 따라 데이터를 복원해야 합니다. RPO는 마지막 백업의 지정된 기간과 백업 유형에 나열되므로 RPO는 전적으로 백업 시스템에 따라 다릅니다. 개별 RPO가 있는 데이터 백업은 일반적으로 매시간, 24시간, 12시간, 8~4시간 또는 10분마다 자동화할 수 있습니다. 즉, 1시간 RPO의 경우 24시간 분량의 데이터가 손실될 수 있습니다. 또는 20시간 분량의 데이터를 손실해도 괜찮으므로 RPO는 XNUMX시간으로 설정됩니다.

장애 조치 / 장애 복구 전략을 통해 거의 XNUMX에 가까운 RPO를 유지하는 것이 가능하지만 이는 비용이 많이 드는 작업입니다. 미션 크리티컬 애플리케이션의 우선 순위에 따라 예산 균형을 조정하는 RPO를 예약 할 수 있습니다.

• XNUMX에 가까운 RPO : CDP (무중단 데이터 보호) 또는 복제 (미션 크리티컬 데이터) 사용
• 4 시간의 RPO : 사용 거의 연속적인 데이터 보호 (CDP) 예약 된 스냅 샷 복제를 사용하는
• 8-24 시간의 RPO : 기존 백업 솔루션 사용 (다른 리포지토리에서 잠재적으로 백업 할 수있는 데이터)

• 오후 2시에 시스템이 중단되고 시스템이 오전 11시에 자동으로 백업을 수행하는 경우 정보는 가장 최근 백업에 사용 가능한 형식으로 저장됩니다. RPO는 오전 11 시여 야합니다. 즉, 비즈니스 연속성을 방해하지 않고 2 시간 분량의 데이터를 잃을 수 있습니다.
• 다시 말하지만, RPO가 6 시간이면 6 시간마다 데이터 손실 위험이 발생할 수 있으므로 24 시간마다 백업을 수행해야합니다. 그러나 1 시간마다 백업을 예약하면 많은 비용이들 수 있습니다.

RTO와 RPO의 주요 차이점

현실적으로 복구 시간 목표와 복구 시점 목표에 대한 확실한 이해는 지식 격차를 좁히고 예산, 리소스 및 애플리케이션 우선 순위에 따라 목표를 설정하는 데 도움이 될 수 있습니다. 구경하다.

• RTO는 중단 시작부터 측정되는 반면, 서비스 중단 후 RPO를 측정 할 수 있습니다.
• RTO는 백업 및 실행할 애플리케이션과 프로세스를 복구 할 미래의 시간을 결정합니다. RPO는 데이터가 마지막 최근 백업에 보존되었을 때 데이터 손실 이전의 과거 시간을 처리하므로 회사는 데이터를 복구하여 정상적인 작업을 재개 할 수 있습니다.
• RTO는 데이터 손실과 관련이 없으며 대부분 재해 후 IT 시스템 복원의 목표 시간을 처리합니다. 반면 RPO는 중단 시간부터 마지막 ​​백업까지 데이터 손실을 일으키는 허용 가능한 비즈니스 다운 타임입니다.
• RTO에는 다양한 재해를 완화하거나 복구하기 위해 IT가 취한 단계가 포함됩니다. 그러나 RPO는 IT 팀이 마지막 시점까지 얼마나 뒤로 이동해야하는지와 운영을 재해 이전 상태로 되돌리기 위해 수행해야하는 작업을 결정합니다.
• RTO에는 선형 시간 프레임, 이벤트 날짜 등과 같은 여러 요소에 의존하는 다양한 복원 시간이있어 계산이 더욱 복잡해집니다. RPO는 데이터 사용량이 대체로 일관되고 더 적은 변수를 포함하므로 계산하고 구현하기가 더 쉽습니다.
• RTO에는 전체 인프라 복구가 포함되므로 거의 XNUMX에 가까운 RTO 요구 사항을 충족하면 복구 비용이 크게 증가합니다. 그러나 XNUMX에 가까운 세분화된 RPO 복제는 고립된 정보를 더 빨리 복구할 수 있으므로 복구 비용과 효율성을 단순화합니다. 또한 전체 인프라를 복원하는 것과 달리 RPO가 길수록 경제적입니다.

RTO 및 RPO 달성 : Zmanda의 차이

24/7/365 운영 가용성과 액세스 가능성을 유지하는 것은 모든 비즈니스의 꿈입니다. 그러나 RTO 및 RPO 요구 사항을 계산하려면 상당한 데이터 손실 위험과 완화 비용이 수반될 수 있습니다. 게다가 장기간의 다운타임 동안 RTO 및 RPO 목표가 현실적이지 않으면 비즈니스에 큰 타격을 줄 수 있습니다. 결과? 평판, 고객 신뢰, 수백 건의 거래 손실! 따라서 올바른 복구 파트너를 선택하는 것은 복구 목표를 달성하는 데 매우 중요합니다. 여기에서 RTO 및 RPO 지표를 개선하여 비용-편익 방정식을 평가해야 합니다. 재해 복구 계획.

Zmanda의 포괄적 인 올인원 클라우드 네이티브로 모든 것을 남겨주세요 재해 복구 솔루션, 백업, 재해 복구 및 보안 게이트웨이 액세스 지원 솔루션을 통합하여 여러 지역 및 모든 워크로드에 걸쳐 백업을 확장합니다. Zmanda의 기본 코드 아키텍처는 복구 시간을 최소화하면서 미션 크리티컬 애플리케이션 및 데이터, 여러 유형의 백업 저장소를 즉시 복구하는 데 도움이 될 수 있습니다. 게다가 Amazon Glacier 스토리지 아키텍처 또한 원활한 하이브리드 백업을 용이하게하는 더 빠른 스토리지 아키텍처를 제공합니다. 또한 다중 계층 보안을 통해 Zmanda 고객은 복구 및 백업 중에 보안 강화를 기대할 수 있습니다. 데이터 관리 비즈니스에 영향을주지 않고 비용을 절감합니다.

실질적인 복구 목표를 결정하고 비즈니스 연속성을 달성하는 데 도움을 줄 수있는 방법에 대해 더 많은 통찰력을 얻고 싶으십니까? 문의하기 더 많은 정보를 원 하시거나 저희를 방문하십시오 DR 솔루션 페이지.

무료로 Zmanda 4.0 사용해보기 데모 요청

RTO와 RPO – 차이점은 무엇입니까?

비즈니스 응용 프로그램과 시스템이 작동하는 한 부서의 성공입니다. 그러나 주어진 시점에서 허용할 수 없는 중단이 발생하면 심각한 위협이 될 수 있습니다. 종종 경고가 거의 또는 전혀 없이 재난이 예기치 않게 발생합니다. 이것은 당신이 위험 계산을 수행하고 복구 우선 순위를 설정하도록 촉구합니다. 비즈니스 연속성 과 재해 복구 (DR) 계획 프로세스.

중단 중에 시스템은 심각한 비즈니스 손실 없이 즉시 복구되어야 합니다. RTO (복구 시간 목표) 과 RPO (복구 지점 목표) 비즈니스가 견딜 수 있는 데이터 손실의 양을 추정할 수 있는 두 가지 중요한 매개변수입니다. 비즈니스를 절약하는 시간 프레임에서 미션 크리티컬 애플리케이션을 복구하려면 RPO 대 RTO 목표를 조정해야 합니다. 복구 값이 비현실적이면 DR 목표를 달성하는 데 따르는 위험과 비용이 비즈니스에 큰 타격을 줄 수 있습니다. 따라서 RTO 및 RPO는 장기적으로 비즈니스 연속성과 재해 복구를 결정하는 데 핵심적인 역할을 하는 중요한 비즈니스 메트릭입니다.

이제 질문은 다음과 같습니다. RTO와 RPO 목표가 관련되어 있습니까?

RPO와 RTO 메트릭이 관련되어 있다고 생각할 수 있습니다. 그러나 이 두 가지 구성요소는 참사 복구 계획 핵심 목표, 목적, 데이터 우선 순위 및 사용이 다릅니다. 재해 발생 시 XNUMX분의 다운타임으로 인해 수천 달러의 수익이 손실될 수 있습니다. 최악의 경우 비즈니스에 대한 고객의 신뢰가 떨어집니다. 이제부터 견고한 RTO 대 RPO 전략을 수립하려면 RTO, RPO 및 주요 차이점이 무엇인지 이해하는 것이 중요합니다. RTO 및 RPO 값을 올바르게 설정하면 솔리드를 개발할 수 있습니다. 재해 복구 과 사업 연속성 계획 위험을 설명하고 복구 요구 사항을 충족하며 언제든지 데이터를 복원할 수 있는 백업 솔루션을 제공합니다.

RTO 란 무엇입니까?

RTO(복구 시간 목표)는 조직에서 재해 후 애플리케이션과 프로세스를 복구하는 데 소요할 수 있는 목표 시간입니다. 복구 일정은 비즈니스의 다운타임 허용 수준을 결정하는 중요한 매개변수입니다.

RTO는 "재해 발생 후 애플리케이션이 얼마나 오래 다운될 수 있습니까?"라는 질문에 답합니다. RTO는 또한 상당한 비즈니스 손실 없이 시작하고 실행하는 데 얼마나 걸릴지 답변합니다. 이 주요 지표를 사용하여 복구와 허용 가능한 비즈니스 데이터 손실 사이의 기간을 계산할 수 있습니다.

그러나 RTO의 목표는 재해 발생과 복구 사이의 기간을 결정하는 것만이 아닙니다. 또한 IT 팀이 애플리케이션과 데이터를 복원하기 위해 수행해야 하는 복구 단계를 정의해야 합니다. IT가 우선 순위가 높은 애플리케이션을 복구하기 위해 장애 조치 서비스에 투자했다면 단 몇 초 만에 RTO를 달성할 수 있습니다. RTO 시간 프레임을 2시간으로 설정했다면 재해 발생 시 2시간 이내에 업무를 정상화해야 합니다.

RTO를 계산하는 방법

RTO 목표를 정확하게 설정하려면 먼저 XNUMX계층 DR 모델을 기반으로 우선 순위가 높은 비즈니스 애플리케이션을 정의해야 합니다.

1 단계	미션 크리티컬 애플리케이션의 경우 거의 XNUMX에 가깝습니다.	거의 XNUMX에 가까운 RTO를 달성하려면 애플리케이션이 장애 조치 기능으로 전환해야 합니다.
2 단계	4시간의 RTO가 필요한 비즈니스 크리티컬 애플리케이션	4시간 RTO를 달성하려면 최소 4시간마다 온프레미스 복구를 수행해야 합니다. 이렇게 하면 비즈니스의 데이터 가용성이 보장됩니다.
3 단계	8시간의 RTO가 필요한 중요하지 않은 애플리케이션	8시간 이상의 RTO를 달성하기 위해 기존 백업 솔루션을 사용하여 중요하지 않은 애플리케이션을 복원할 수 있습니다.

RTO 사용 방법의 예 :

재해 발생 시 은행 시스템에 대한 비즈니스 연속성 시나리오의 예를 들어 보겠습니다.

• 1시간의 가동 중지 시간이 치명적일 수 있다는 점을 감안할 때 최소 복구 시간이 2시간이면 XNUMX시간의 RTO를 충족할 수 없습니다. RTO는 중단 XNUMX시간 이내에 모든 것을 복원하는 것을 목표로 하기 때문입니다.
• RTO를 4시간으로 설정하고 오후 12시에 시스템 장애가 있는 경우. RTO 목표를 달성하려면 오후 4시까지 서버 데이터를 복원해야 합니다.
• RTO를 2주로 설정하면 재해 복구에 대한 투자가 훨씬 낮아집니다. 중단이 발생한 후 데이터를 복구할 수 있는 충분한 시간이 있기 때문입니다.

이제 비즈니스 애플리케이션에 대한 RTO 목표를 계획하는 방법을 알았으므로 RPO가 무엇인지 이해하겠습니다.

RPO란 무엇입니까?

RPO(복구 시점 목표)는 심각한 손상 없이 비즈니스에서 감당할 수 있는 최대 데이터 손실량입니다. 비즈니스 연속성 계획에서 회사가 "허용할 수 있는" 시간을 정의해야 합니다. RPO가 길수록 다운타임 연장으로 인한 데이터 손실이 커집니다. RPO는 "비즈니스에서 손실을 감당할 수 있는 데이터의 양은 얼마입니까?"라는 질문에 답하려고 합니다. 즉, RPO는 비즈니스 운영을 정상으로 다시 시작하기 위해 복구해야 하는 데이터의 수명을 결정합니다.

RPO에 관심을 가져야 하는 이유

RPO는 결정 단계를 설정합니다. 재해 복구 (DR) 계획. 첫 번째 단계는 백업 빈도를 결정하는 RPO 기간을 정의하는 것입니다. 이 아이디어는 재해가 발생하기 전에 항상 사용 가능한 백업이 있는지 확인하는 것입니다. 그러나 복구해야 하는 데이터의 가치를 평가해야 합니다. 데이터 중요도 수준에 따라 연속 백업에 대한 RPO를 설정해야 합니다. 기업이 다운타임 동안 데이터를 잃는 것은 분명합니다. 그러나 RPO 시간 프레임을 정의하면 데이터 백업 빈도를 설정하여 상당히 견딜 수 있는 데이터 손실을 최소화할 수 있습니다.

개별 RPO를 사용하여 데이터 백업을 자동화할 수도 있습니다. 즉, RPO를 매시간, 24시간, 12시간, 8~4시간 또는 10분마다 설정할 수 있습니다. 따라서 1시간 RPO의 경우 비즈니스는 24시간 분량의 데이터를 잃을 수 있습니다. 다시 말하지만, 20시간 분량의 데이터를 잃어도 괜찮다면 RPO를 XNUMX시간으로 설정할 수 있습니다.

장애 조치/장애 복구 전략을 통해 거의 XNUMX에 가까운 RPO를 유지하는 것이 가능하지만 이는 비용이 많이 드는 작업입니다.

RPO 계산 방법

우선 순위가 높은 응용 프로그램의 경우 조직에서 손실을 감당할 수 있는 데이터의 양을 결정하는 것이 중요합니다.

RPO 사용 방법의 예 :

• 비즈니스에서 오후 2시에 시스템 중단이 발생하고 시스템이 오전 11시에 백업을 수행한다고 가정합니다. 가장 최근 백업에 정보를 저장했으므로 RPO는 오전 11시여야 합니다. 여기에서 비즈니스는 비즈니스 연속성을 방해하지 않고 2시간 분량의 데이터를 손실할 여유가 있습니다.
• 다시 말하지만 RPO가 6시간이면 6시간마다 백업을 수행해야 합니다. 24시간마다 데이터가 손실될 위험이 있기 때문입니다. 그러나 1시간마다 백업을 예약하면 비용이 많이 들 수 있습니다.

RTO와 RPO의 차이점

복구 시간 목표와 복구 시점 목표를 확실히 이해하면 복구 목표를 달성하는 데 도움이 됩니다. RTO와 RPO의 주요 차이점을 간단히 살펴보세요.

• RTO를 사용하면 다운타임 동안 비즈니스 애플리케이션이 다운될 수 있는 시간을 측정할 수 있습니다. 반면 RPO는 가동 중지 시간 동안 허용 가능한 데이터 손실의 가변 양을 측정합니다.
• 중단의 시작점을 취하여 RTO를 측정할 수 있습니다. 그러나 RPO를 측정하려면 생성된 마지막 백업에서 비즈니스가 허용할 수 있는 데이터 손실을 결정하기 위해 시간을 거슬러 측정해야 합니다.
• RTO에는 IT가 가동 중지 시간을 줄이고 애플리케이션을 다시 실행하기 위해 취해야 하는 단계가 포함됩니다. RPO는 IT가 수행한 마지막 백업에서 되돌려 데이터를 복구하기 위해 얼마나 뒤로 갈 것인지를 결정합니다.
• RTO를 계산하는 동안 고려해야 할 몇 가지 요소가 있으므로 RTO의 복원 시간이 달라집니다. 예를 들어 선형 시간 프레임, 재해 발생 날짜 등은 계산을 더욱 복잡하게 만듭니다. RPO는 마지막 데이터 사용량 및 백업 변수를 사용하므로 계산 및 구현이 더 쉽습니다.
• RTO에는 전체 인프라 복구가 포함되므로 거의 XNUMX에 가까운 RTO 요구 사항을 충족하면 복구 비용이 크게 증가합니다. 그러나 제로에 가까운 세분화된 RPO 복제를 사용하면 데이터 손실이 거의 XNUMX에 가까울 때까지 데이터를 지속적으로 복제할 수 있습니다. 이는 비용을 단순화하고 고가용성이 필요한 애플리케이션에 대해 더 빠른 복구를 수행합니다. 또한 전체 인프라를 복원하는 것과 달리 RPO가 길어질수록 저렴해집니다.

RTO 및 RPO 달성 : Zmanda의 차이

24일 연중무휴로 비즈니스 운영을 유지하는 것은 모든 비즈니스의 꿈입니다. 그러나 RTPO(복구 시간 및 목표 지점)는 만능이 아닙니다. 다운타임 동안 RTO 및 RPO 목표가 현실적이지 않으면 비즈니스에 큰 타격을 줄 수 있습니다. 결과? 평판, 고객 신뢰, 수백 건의 거래 손실! 따라서 올바른 복구 파트너를 선택하는 것은 복구 목표를 달성하는 데 매우 중요합니다. 여기에서 RTO 및 RPO 지표를 개선하여 비용-편익 방정식을 평가해야 합니다. 재해 복구 계획.

랩 업

따라서 애플리케이션 우선 순위를 기반으로 RTO 및 RPO 목표를 설정했습니다. 엄청난! 이제 RTO 및 RPO 목표를 달성하기 위한 올바른 재해 복구 전략을 수립할 때입니다. 더 이상 보지 마십시오. Zmanda의 올인원 클라우드 네이티브 재해 복구 솔루션은 백업, 재해 복구 및 보안 게이트웨이 액세스를 통합하여 여러 워크로드에 걸쳐 백업을 확장할 수 있습니다. Zmanda의 기본 코드 아키텍처를 사용하면 가능한 모든 오류 시나리오를 처리하여 주요 중단 중에도 워크로드에 대해 거의 실시간 RPO를 달성할 수 있습니다.

Zmanda의 지원 Amazon Glacier 스토리지 모든 중요한 데이터에 대한 원활한 데이터 백업을 제공하면서 스토리지 비용을 크게 줄일 수 있습니다. 또한 다계층 보안으로 데이터 보안 강화를 기대할 수 있습니다. 데이터 관리 비즈니스 수익에 영향을 주지 않으면서 비용을 절감할 수 있습니다.

비즈니스 연속성을 달성하기 위해 RTO 및 RPO 목표를 달성하는 데 도움이 될 수 있는 방법에 대해 더 많은 통찰력을 얻고 싶으십니까? 문의하기 더 많은 정보를 원 하시거나 저희를 방문하십시오 DR 솔루션 페이지.