복구 시간 목표(RTO)를 설정하는 것은 특히 네트워크 해킹과 랜섬웨어 공격이 증가하고 있을 때 매우 중요합니다. 언제 다음 희생자가 될지 알 수 없습니다. 이 시점에서 RTO가 정의되지 않았다면 어떻게 데이터 백업 및 복구 계획을 세울 수 있을까요?
이 게시물에서는 복구 시간 목표를 정의하고 RTO를 설정할 때 고려해야 할 요소를 살펴보겠습니다.
복구 시간 목표란 무엇입니까?
복구 시간 목표는 재해 복구 및 비즈니스 연속성 계획에 사용되는 지표입니다. 재해나 장애가 발생한 후 조직이 상당한 피해를 입기 전까지 애플리케이션, 네트워크, 시스템 또는 컴퓨터가 다운될 수 있는 최대 기간입니다. 수익 손실 및 비즈니스 연속성 중단과 같은 요인은 RTO에 영향을 미칠 수 있습니다. RTO는 관련 시스템 및 프로세스에 따라 크게 다릅니다.
RTO 시간은 서비스 수준 계약에 정의된 대로 실패한 시스템을 복구하고 시스템 복원을 완료하는 데 걸리는 시간을 나타냅니다. 서비스 수준 목표는 재해가 발생한 후 비즈니스 연속성을 보장하기 위해 조직이 임무에 중요한 IT 프로세스 또는 운영을 정상 상태로 복구하거나 복원하는 데 설정한 복구 시간을 설명합니다.
프로 팁: 재해의 영향을 최소화하려면 항상 가능한 가장 낮은 RTO를 달성하는 것을 목표로 해야 합니다. RTO를 결정하려면 먼저 데이터를 사용할 수 없는 기간이 비즈니스에 미치는 영향을 식별해야 합니다.
예 :
- 데이터의 10%가 24시간 이내에 사용 가능해야 하는 경우,
- 그리고 데이터베이스가 완전히 손실된 후 50일 이내에 데이터의 2%를 사용할 수 있어야 합니다.
- 나머지 40%의 데이터는 향후 5일 이내에 사용할 수 있어야 합니다.
총 RTO는 = 8일입니다.
다른 예를 인용하자면:
Exchange 서버가 다운되었다고 가정해 보겠습니다. RTO가 5시간이라면 조직은 5시간의 다운타임을 허용할 수 있으며 Exchange 서버의 RTO는 5시간 미만이어야 합니다. 재해 복구 정책에는 IT 부서가 데이터를 백업하고 복원하기 위해 취한 필요한 단계가 포함되어야 합니다.
데이터 복구를 위해 복구 시간 목표를 설정할 수 있지만, 이에 대한 단일 솔루션은 없습니다. 사업 연속성 계획. 재해 발생 후 데이터를 복구하도록 RTO를 설정할 수 있습니다. 그러나 사고가 발생하면 재해 복구 계획의 실제 실용성도 복구를 제공하는 데 사용되는 특정 도구와 기술에 따라 달라집니다. 따라서 RTO 적중 능력은 다양한 기술과 DR 도구의 기능이 다르기 때문에 달라집니다. RTO는 정전이 시작되기 전에도 측정되며 서버 수리, 우선 순위 애플리케이션 설치 및 데이터 복원에 소요된 시간을 포함합니다. 또한 복구 방법 및 복구해야 하는 백업 데이터도 포함됩니다.
RTO는 무엇을 결정하나요?
RTO는 애플리케이션, 시스템 및/또는 프로세스가 다운타임을 견뎌내고 중단이 시작되기 전에 작동하지 않는 목표 기간입니다. RTO는 RTO 매개변수 내에서 애플리케이션과 프로세스의 우선 순위를 정하는 데 걸리는 시간을 결정하는 데 매우 중요합니다. 데이터 보호 계획 및 재해 복구 전략에서 RTO는 "서비스 중단 알림 후 서비스 복구를 위해 설정된 목표 시간은 무엇인가?"라는 질문에 답합니다.
RTO는 다음을 결정할 수 있습니다.
- 사고가 발생한 순간부터 작업이 복구될 때까지 실시간으로 사이트를 복구하는 데 걸리는 시간
- 재해 복구 계획을 수행하기 위해 어떤 IT 준비를 설계해야 합니까?
- 시스템이나 주요 애플리케이션이 다운될 때 허용되는 데이터 손실 수준
재해 복구 계획을 위한 RTO를 계산하는 방법은 무엇입니까?
RTO 메트릭은 다운타임 후 시스템이나 애플리케이션을 복구하고 시스템을 다시 온라인 상태로 전환하는 데 걸리는 시간에 대한 임계값을 결정하기 때문에 IT 팀에 대한 목표 기대치를 미리 설정합니다. 시스템을 복구하는 데 걸리는 "실시간"의 양에 따라 이 측정을 정의한 후 서비스를 다시 작동시키기 위한 복구 전략을 계획할 수 있습니다. RTO를 계산하려면 (BCP) 비즈니스 연속성 RTO가 중단됨에 따른 손실을 고려해야 합니다. 또한 서비스의 비즈니스 중단으로 인한 단기 또는 장기적 영향을 설명하는 영향 분석을 포함합니다. 여기에는 위험, 수익 손실, 비용, 고객 대상 애플리케이션, 미션 크리티컬 애플리케이션, 영향을 받거나 사용할 수 없게 되는 우선 순위가 낮은 애플리케이션이 포함됩니다. RTO는 데이터 복구 프로세스의 다운타임 및 시간 제한과 더 관련이 있습니다.
특정 중단에는 복구 시간이 많이 필요하지 않을 수 있고 일부는 다른 장기 보호 솔루션이 필요할 수 있기 때문에 RTO를 해결하려면 여러 RTO 범주가 필요할 수 있습니다. 예를 들어 RTO는 덜 중요한 애플리케이션(자주 사용되지 않음)의 경우 훨씬 더 길 수 있습니다. 운영 중인 여러 보안 시스템의 복잡성 수준에 따라 단기 및 장기 백업에 따라 RTO를 설정해야 할 수 있습니다. 이는 랜섬웨어 이벤트 또는 기타 대규모 재난 사고로 인해 발생할 수 있습니다.
RTO를 계산할 때 고려해야 할 주요 요소
- 복구 솔루션을위한 비용 / 편익 방정식
- 개별 시스템 및 데이터의 우선 적용
- 프로세스, 자동화된 기술 또는 IT 인프라를 복원하는 기술을 기반으로 IT 부서에서 취해야 할 조치
- 중단 및 완화 비용
- 복구 절차의 복잡성
RTO 샘플 간격
XNUMX에 가까운 RTO를 달성하는 것은 대부분의 IT 기업에서 비용이 많이 들지만 애플리케이션과 데이터의 우선 순위를 정한다면 달성할 수 있습니다. 덜 비즈니스 크리티컬한 애플리케이션의 경우 RTO 클록이 평소보다 더 긴 목표 시간을 소비할 수 있습니다. 미션 크리티컬 애플리케이션을 위한 제로에 가까운 RTO 계획을 사용하려면 즉각적인 장애 조치 기능을 고려해야 할 수 있습니다.
중단의 심각도에 따라 달성 가능한 목표 RTO 시간을 설정할 수 있습니다. 그러나 RTO 복원 시간도 IT 조직의 한계에 따라 다릅니다. 예를 들어 모든 IT 기능 및 운영을 복원하는 데 3시간이 걸린다면 RTO는 3시간 이상이어야 합니다.
주의 사항: 재해 복구(DR) 관점에서 RTO 시계는 복구 프로세스가 시작될 때 바로 시작됩니다.
사업부의 RTO를 계산할 때 다음 샘플 간격을 고려하세요.
한 시간
이 간격은 외장 하드 드라이브의 중복 데이터 백업을위한 것입니다.
오일
이 경우 가장 비용 효율적인 솔루션은 컴팩트 디스크, 테이프 또는 오프사이트 디스크 저장소를 사용하여 데이터를 백업하는 것입니다.
Zmanda 방식으로 RTO 달성
RTO 및 RPO (복구 지점 목표) 매우 중요한 목표이며 복구 계획의 기초입니다. 실제 복구 목표의 일련의 단계를 어떻게 결정합니까? 이것은 우리가 도울 수 있는 곳입니다!
와 Zmanda의 DRaaS 계획 그리고 맞춤형 서비스 수준 계약, 귀사의 비즈니스 규모와 상관없이, 귀사의 비즈니스 요구 사항에 따라 중단 시간을 단축하고 다운타임의 고통을 피할 수 있도록 도와드릴 수 있습니다. 전환을 지원하고 비교적 빠른 RTO를 달성하기 위한 하이브리드 백업 외에도, 당사의 엔터프라이즈 솔루션은 Amazon Glacier를 20배 낮은 장기 데이터 보관 비용과 결합하여 견고한 고가용성을 구축하고 비즈니스 연속성을 보장합니다.
당사는 귀사의 요구 사항을 충족하도록 엔터프라이즈 백업 솔루션을 맞춤화하여 백업 프로세스, 데이터 연속성 및 장기 스토리지 보관을 통합하는 제품을 제공합니다. 예상치 못한 일이 발생하더라도 필요한 안정성과 보안을 확보하세요. 심지어 전체 서버 장애가 발생한 경우에도 마찬가지입니다.
Zmanda Pro를 직접 사용해보고 싶으신가요?
Zmanda Pro가 어떻게 가동 중단 시간을 단축하고 가동 중지 시간을 피하는 데 도움이 되는지 확인하세요. Zmanda Pro 무료 평가판에 가입하세요 그리고 회복 시간 목표를 전략화하세요. 14일 체험 기간 동안 모든 기능에 액세스할 수 있으며, 체험 상태에 대한 최신 정보를 제공해 드립니다. 솔루션에 대한 질문이 있으면, 전문가에게 문의.
