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