RTO와 RPO – 차이점은 무엇입니까?
생산 시스템과 필수 기능이 제대로 작동한다면 이는 부서의 성공입니다. 그러나 특정 시점에 용납할 수 없는 운영 중단이 발생하면 심각한 위협이 됩니다. 경고가 거의 또는 전혀 없이 예기치 않게 재해가 발생하는 경우가 많습니다. 에 따르면 Statista, 서버 가동 중지 시간의 평균 비용은 시간당 $301,000에서 $400,000 사이입니다. 이를 통해 위험 계산을 수행하고 복구 우선순위를 설정해야 합니다. 이는 두 가지 모두의 필수 요소입니다. 비즈니스 연속성 재해 복구 (DR) 계획 프로세스.
중대한 중단이 발생한 경우 시스템을 복구해야 하며 이를 무시할 수 없습니다. 잠재적인 중단 동안 회사의 데이터 손실 허용 범위를 반영하는 두 가지 중요한 결정은 RTO와 RPO입니다. RTO (복구 시간 목표) RPO (복구 지점 목표). RTO와 RPO 목표는 비즈니스 연속성에 맞춰 설정되어야 합니다. 이러한 매개변수는 백업 실행 빈도를 결정하는 데 중요한 역할을 하는 필수 비즈니스 지표입니다.
의미상 RTO와 RPO는 서로 관련되어 있지만 회사의 이 두 구성 요소는 참사 복구 계획 및 비즈니스 연속성 전략은 핵심 목표, 목적, 데이터 우선 순위 및 사용법이 다릅니다. 재해 발생 시 가동 중지 시간이 1분마다 수천 달러에 달하는 수익 손실을 초래하고 비즈니스에 대한 고객의 신뢰가 서서히 약화될 수 있습니다.
따라서 견고한 재해 복구 RTO 대 RPO 전략을 구축하려면 RTO, RPO 및 이들의 차이점을 이해하는 것이 중요합니다. RTO 및 RPO 값을 사용하여 다음을 개발할 수 있습니다. 견고한 재해 복구 사업 연속성 계획 기업에서 함께 마련해야하는 위험, 복구 요구 및 백업 솔루션을 간략하게 설명합니다.
복구 시간 목표란 무엇입니까?
재해 발생 후 조직이 애플리케이션과 프로세스를 복구하는 데 걸리는 목표 시간을 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는 재해 복구 (DR) 계획. 따라서 복구해야 할 애플리케이션, 프로세스 또는 정보를 결정하려면 데이터의 중요성을 평가하는 것이 중요합니다. 중요도 수준에 따라 데이터를 복원해야 합니다. RPO는 마지막 백업의 지정된 기간과 백업 유형에 나열되므로 RPO는 전적으로 백업 시스템에 따라 다릅니다.
개별 RPO를 사용한 데이터 백업은 일반적으로 매시간, 24시간, 12시간, 8~4시간 또는 10분마다 자동화될 수 있습니다. 즉, 1시간 RPO의 경우 24시간 분량의 데이터가 손실될 수 있고, 20시간 분량의 데이터가 손실되어도 괜찮다면 RPO는 XNUMX시간으로 설정됩니다.
장애 조치/장애 복구 전략을 통해 거의 0에 가까운 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는 백업 및 실행할 애플리케이션과 프로세스를 복구 할 미래의 시간을 결정합니다. RPO는 데이터가 마지막 최근 백업에 보존되었을 때 데이터 손실 이전의 과거 시간을 처리하므로 회사는 데이터를 복구하여 정상적인 작업을 재개 할 수 있습니다.
- RTO는 데이터 손실과 관련이 없으며 대부분 재해 발생 후 IT 시스템 복원을 위한 목표 시간을 다룹니다. 반면, RPO는 마지막 백업이 중단된 시점부터 데이터 손실을 초래하는 허용 가능한 비즈니스 가동 중지 시간입니다.
- RTO에는 다양한 재해를 완화하거나 복구하기 위해 IT가 취하는 단계가 포함됩니다. 그러나 RPO는 IT 팀이 마지막 시점까지 얼마나 뒤로 가야 하는지, 그리고 운영을 재해 이전 상태로 되돌리기 위해 수행해야 하는 작업을 결정합니다.
- RTO에는 선형 시간 프레임, 이벤트 날짜 등과 같은 여러 요소에 의존하는 다양한 복원 시간이있어 계산이 더욱 복잡해집니다. RPO는 데이터 사용량이 대체로 일관되고 더 적은 변수를 포함하므로 계산하고 구현하기가 더 쉽습니다.
- RTO에는 전체 인프라 복구가 포함되므로 거의 0에 가까운 RTO 요구 사항을 충족하면 복구 비용이 크게 증가합니다. 그러나 세분화된 제로에 가까운 RPO 복제는 사일로화된 정보를 더 빠르게 복구할 수 있으므로 복구 비용과 효율성을 단순화합니다. 또한 전체 인프라를 복원하는 것과는 달리 RPO가 길어지면 경제적입니다.
RTO와 RPO: Zmanda의 차이점
연중무휴 24시간 운영 가용성과 접근성을 유지하는 것은 모든 기업의 꿈입니다. 그러나 RTO와 RPO 요구 사항을 계산하는 데는 상당한 데이터 손실 위험과 완화 비용이 포함될 수 있습니다. 게다가 가동 중지 시간이 길어지는 동안 RTO 및 RPO 목표가 현실적이지 않으면 비즈니스에 큰 타격을 줄 수 있습니다. 결과는? 평판 상실, 고객 신뢰 상실, 수백 건의 거래 상실! 따라서 복구 목표를 달성하려면 올바른 복구 파트너를 선택하는 것이 중요합니다. 여기에서는 RTO 및 RPO 지표를 개선하여 비용-이익 방정식을 평가해야 합니다. 재해 복구 계획.
RTO와 RPO – 차이점은 무엇입니까?
비즈니스 애플리케이션과 시스템이 작동하는 한 이는 부서의 성공입니다. 그러나 특정 시점에 용납할 수 없는 중단이 발생하면 심각한 위협이 될 수 있습니다. 경고가 거의 또는 전혀 없이 예기치 않게 재해가 발생하는 경우가 많습니다. 이는 위험 계산을 수행하고 복구 우선순위를 설정하는 것이 중요합니다. 비즈니스 연속성 재해 복구(DR) 계획 프로세스.
중단이 발생한 경우 심각한 비즈니스 손실 없이 시스템을 즉시 복구해야 합니다. RTO 대 RPO라고도 함 RTO (복구 시간 목표) RPO (복구 지점 목표) 귀하의 비즈니스가 견딜 수 있는 데이터 손실의 양을 추정할 수 있는 두 가지 중요한 매개변수입니다. 비즈니스를 절약하는 시간 내에 미션 크리티컬 애플리케이션을 복구하려면 RTO와 RPO 목표를 일치시켜야 합니다. 복구 값이 비현실적일 경우 DR 목표 달성에 따른 위험과 비용이 비즈니스에 큰 타격을 줄 수 있습니다. 따라서 RTO와 RPO는 장기적으로 비즈니스 연속성과 재해 복구를 결정하는 데 중요한 역할을 하는 중요한 비즈니스 지표입니다.
이제 질문은 RTO와 RPO 목표가 관련되어 있습니까?
RTO와 RPO 측정항목이 서로 관련되어 있다고 생각할 수도 있습니다. 그러나 이 두 가지 구성 요소는 참사 복구 계획 핵심 목표, 목적, 데이터 우선순위 및 사용 방식이 다릅니다. 재해 발생 시, 가동 중단 시간 1분마다 수천 달러의 매출 손실이 발생할 수 있습니다. 최악의 경우, 이는 귀사의 비즈니스에 대한 고객의 신뢰를 떨어뜨릴 것입니다. 따라서 견고한 RTO 대 RPO 전략을 구축하려면 RTO 대 RPO 차이점을 이해하는 것이 중요합니다. RTO 및 RPO 값을 올바르게 설정하면 견고한 재해 복구를 개발하다 사업 연속성 계획 위험을 설명하고 복구 요구 사항을 충족하며 언제든지 데이터를 복원할 수 있는 백업 솔루션을 제공합니다.
RTO 란 무엇입니까?
RTO(복구 시간 목표)는 조직에서 재해 후 애플리케이션과 프로세스를 복구하는 데 소요할 수 있는 목표 시간입니다. 복구 일정은 비즈니스의 다운타임 허용 수준을 결정하는 중요한 매개변수입니다.
RTO는 "재난 발생 후 애플리케이션이 얼마나 오랫동안 다운될 수 있습니까?"라는 질문에 답합니다. RTO는 또한 심각한 비즈니스 손실 없이 가동 및 실행하는 데 시간이 얼마나 걸리는지에 대해서도 답변합니다. 이 주요 지표를 사용하면 복구부터 허용 가능한 비즈니스 데이터 손실까지의 시간을 계산할 수 있습니다.
그러나 RTO 목표는 재해 발생부터 복구까지의 기간을 결정하는 것만이 아닙니다. 또한 IT 팀이 애플리케이션과 데이터를 복원하기 위해 수행해야 하는 복구 단계를 정의해야 합니다. IT가 우선순위가 높은 애플리케이션을 복구하기 위해 장애 조치 서비스에 투자했다면 단 몇 초 만에 RTO를 달성할 수 있습니다. RTO 기간을 2시간으로 설정한 경우 재해 발생 시 2시간 이내에 비즈니스 운영을 정상화해야 합니다.
RTO를 계산하는 방법
RTO 목표를 정확하게 설정하려면 먼저 3계층 DR 모델을 기반으로 우선 순위가 높은 비즈니스 애플리케이션을 정의해야 합니다.
| 1 단계 | 미션 크리티컬 애플리케이션의 경우 거의 XNUMX에 가깝습니다. | 거의 XNUMX에 가까운 RTO를 달성하려면 애플리케이션이 장애 조치 기능으로 전환해야 합니다. |
| 2 단계 | 4시간의 RTO가 필요한 비즈니스 크리티컬 애플리케이션 | 4시간 RTO를 달성하려면 최소 4시간마다 온프레미스 복구를 수행해야 합니다. 이렇게 하면 비즈니스의 데이터 가용성이 보장됩니다. |
| 3 단계 | 8시간의 RTO가 필요한 중요하지 않은 애플리케이션 | 8시간 이상의 RTO를 달성하기 위해 기존 백업 솔루션을 사용하여 중요하지 않은 애플리케이션을 복원할 수 있습니다. |
RTO 사용 방법의 예 :
재해 발생 시 은행 시스템에 대한 비즈니스 연속성 시나리오의 예를 들어 보겠습니다.
- 1시간의 가동 중지 시간은 치명적일 수 있으므로 최소 복원 시간이 2시간이면 XNUMX시간의 RTO를 충족할 수 없습니다. RTO는 중단 시간 내에 모든 것을 복원하는 것을 목표로 하기 때문입니다.
- 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시간으로 설정할 수 있습니다.
장애 조치/장애 복구 전략을 통해 거의 0에 가까운 RPO를 유지하는 것이 가능하지만 여전히 비용이 많이 드는 작업입니다.
RPO 계산 방법
우선 순위가 높은 응용 프로그램의 경우 조직에서 손실을 감당할 수 있는 데이터의 양을 결정하는 것이 중요합니다.
RPO 사용 방법의 예 :
- 회사에서 오후 2시에 시스템 중단이 발생했고 시스템이 오전 11시에 백업을 수행한다고 가정합니다. 가장 최근 백업에 정보를 저장했으므로 RPO는 오전 11시가 되어야 합니다. 여기서 기업은 비즈니스 연속성을 방해하지 않고 2시간 분량의 데이터를 손실할 수 있습니다.
- 다시 말하지만, RPO가 6시간이면 6시간마다 백업을 수행해야 합니다. 이는 24시간마다 데이터 손실 위험이 있을 수 있기 때문입니다. 하지만 1시간마다 백업을 예약하면 비용이 많이 들 수 있습니다.
RTO와 RPO 차이
RTO와 RPO를 확실히 이해하면 복구 목표를 달성하는 데 도움이 될 수 있습니다. RTO와 RPO의 주요 차이점을 빠르게 살펴보세요.
- RTO를 사용하면 가동 중지 시간 동안 비즈니스 애플리케이션이 가동 중지될 수 있는 시간을 측정할 수 있습니다. 반면 RPO는 가동 중지 시간 동안 허용 가능한 데이터 손실의 가변적인 양을 측정합니다.
- 중단의 시작점을 취하여 RTO를 측정할 수 있습니다. 그러나 RPO를 측정하려면 생성된 마지막 백업에서 비즈니스가 허용할 수 있는 데이터 손실을 결정하기 위해 시간을 거슬러 측정해야 합니다.
- RTO에는 IT가 가동 중지 시간을 줄이고 애플리케이션을 다시 실행하기 위해 취해야 하는 단계가 포함됩니다. RPO는 IT가 수행한 마지막 백업에서 되돌려 데이터를 복구하기 위해 얼마나 뒤로 갈 것인지를 결정합니다.
- RTO를 계산하는 동안 고려해야 할 여러 요소가 있으므로 RTO 복원 시간은 다양합니다. 예를 들어 선형 시간 프레임, 재해 발생 날짜 등은 계산을 더욱 복잡하게 만듭니다. RPO는 마지막 데이터 사용량과 백업 변수를 사용하므로 계산하고 구현하기가 더 쉽습니다.
- RTO에는 전체 인프라 복구가 포함되므로 거의 0에 가까운 RTO 요구 사항을 충족하면 복구 비용이 크게 증가합니다. 그러나 세분화된 0에 가까운 RPO 복제를 사용하면 데이터 손실이 거의 0에 가깝게 유지되도록 데이터를 지속적으로 복제할 수 있습니다. 이를 통해 비용이 단순화되고 고가용성이 필요한 애플리케이션에 대한 복구 속도가 빨라집니다. 또한 전체 인프라를 복원하는 것과는 달리 RPO가 길어지면 경제적입니다.
RTO와 RPO: Zmanda의 차이점
비즈니스 운영을 연중무휴 24시간 온라인으로 유지하는 것은 모든 비즈니스의 꿈입니다. 그러나 복구 시간 및 지점 목표(RTO 대 RPO)가 모든 경우에 적용되는 것은 아닙니다. 가동 중지 시간 동안 RTO와 RPO 목표가 현실적이지 않으면 비즈니스에 큰 타격을 줄 수 있습니다. 결과는? 평판 상실, 고객 신뢰 상실, 수백 건의 거래 상실! 따라서 복구 목표를 달성하려면 올바른 복구 파트너를 선택하는 것이 중요합니다. 여기에서는 RTO 및 RPO 지표를 개선하여 비용-이익 방정식을 평가해야 합니다. 재해 복구 계획.
이제 RTO 대 RPO 목표를 달성하기 위해 올바른 재해 복구 전략을 모색해야 할 때입니다. 더 이상 보지 마십시오. 현대 비즈니스를 위한 포괄적이고 안정적이며 확장 가능한 옵션인 Zmanda Pro를 만나보세요.
Zmanda Pro가 돋보이는 이유는 다음과 같습니다.
- 1시간 미만의 RPO 및 빠른 RTO: 유연한 예약 및 보존 정책과 자동화된 대량 복구를 통해 RTO 및 RPO 요구 사항을 달성하세요.
- 혁신적인 백업 기술: Zmanda가 제공하는 고급 백업 및 복구 재해 복구 및 지속적인 복원 기능을 포함하는 서비스입니다.
- 원활한 클라우드 통합: 오픈소스 Restic 프레임워크를 기반으로 하는 당사의 솔루션은 OpenShift, OpenStack, Kubernetes, Red Hat OpenStack Platform과 같은 클라우드 플랫폼과 손쉽게 통합됩니다. 우리를 확인해보세요 호환성 매트릭스 우리가 지원하는 워크로드를 파악하는 것입니다.
- 파트너십 및 리소스: 사례 연구 및 문서와 같은 광범위한 리소스와 결합된 Wasabi 및 Nutanix와 같은 업계 리더와의 협업은 추가적인 가치를 제공합니다.
제품 데모를 통해 직접 기능을 경험하고, 고객 사용후기를 자세히 살펴보고, 현명한 결정을 내리는 데 필요한 모든 정보를 수집하세요. 오늘부터 데이터 보안을 시작해 보세요. 14 일 무료 사용 .
아직 확실하지 않은 경우 다음을 수행할 수도 있습니다. 데이터 보호 전문가와 상담하세요 엔터프라이즈 데이터 보호 솔루션을 선택하기 전에 30분 무료 상담을 받아보세요.
비즈니스 연속성을 달성하기 위해 RTO 및 RPO 목표를 달성하는 데 어떻게 도움을 줄 수 있는지에 대해 더 많은 통찰력을 얻고 싶으십니까? 당사에 문의해 주세요. 더 많은 정보를 원 하시거나 저희를 방문하십시오 DR 솔루션 페이지.
