RTO(복구 시간 목표)는 서비스 복구에 허용되는 최대 시간을 정의합니다. 예를 들어 인사 데이터베이스의 RTO는 24시간이 될 수 있습니다. 왜냐하면 업무 중에 이 데이터에 액세스하지 못하는 것이 매우 불편함에도 불구하고 비즈니스가 계속 운영될 수 있기 때문입니다. 반면 은행의 총계정원장을 지원하는 데이터베이스에는 분 또는 초 단위로 측정된 RTO가 있습니다. 실제 서비스 중단과 네트워크 패킷 손실과 같은 일상적인 이벤트를 구분하는 방법이 있어야 하므로 RTO 0은 불가능합니다. 하지만 제로에 가까운 RTO는 일반적인 요구사항입니다.

RPO(복구 지점 목표)는 허용되는 최대 데이터 손실을 정의합니다. 대부분의 경우 RPO는 스냅샷 또는 SnapMirror 업데이트 빈도에 의해서만 결정됩니다.

경우에 따라 RPO를 보다 적극적으로 설정하여 특정 데이터를 보다 자주 보호할 수 있습니다. 데이터베이스 컨텍스트에서 RPO는 일반적으로 특정 상황에서 손실될 수 있는 로그 데이터의 양이 어느 정도인지에 관한 문제입니다. 제품 버그 또는 사용자 오류로 인해 데이터베이스가 손상된 일반적인 복구 시나리오에서 RPO는 0이어야 합니다. 즉, 데이터 손실이 없어야 합니다. 복구 절차에서는 데이터베이스 파일의 이전 복사본을 복원한 다음 로그 파일을 재생하여 데이터베이스 상태를 원하는 시점으로 되돌리는 작업을 수행합니다. 이 작업에 필요한 로그 파일이 이미 원래 위치에 있어야 합니다.

비정상적인 시나리오에서는 로그 데이터가 손실될 수 있습니다. 예를 들어, 우발적 또는 악의적 경우입니다 rm -rf * 데이터베이스 파일의 경우 모든 데이터가 삭제될 수 있습니다. 유일한 옵션은 로그 파일을 포함하여 백업에서 복원하는 것이며, 일부 데이터가 손실될 수밖에 없습니다. 기존 백업 환경에서 RPO를 향상시킬 수 있는 유일한 옵션은 로그 데이터의 반복 백업을 수행하는 것입니다. 그러나 지속적인 데이터 이동과 백업 시스템을 지속적으로 실행하는 서비스로 유지 관리하기가 어렵기 때문에 이러한 문제에는 한계가 있습니다. 고급 스토리지 시스템의 이점 중 하나는 파일에 대한 우발적 또는 악의적 손상으로부터 데이터를 보호하여 데이터 이동 없이 더 높은 RPO를 제공하는 기능입니다.

재해 복구에는 물리적 재해 발생 시 서비스를 복구하는 데 필요한 IT 아키텍처, 정책 및 절차가 포함됩니다. 여기에는 홍수, 화재 또는 악의적이거나 과실로 행동하는 사람이 포함될 수 있습니다.

재해 복구는 단순한 복구 절차 그 이상입니다. 다양한 위험을 식별하고, 데이터 복구 및 서비스 연속성 요구 사항을 정의하고, 관련 절차에 따라 올바른 아키텍처를 제공하는 완전한 프로세스입니다.

데이터 보호 요구 사항을 설정할 때는 일반적인 RPO 및 RTO 요구 사항과 재해 복구에 필요한 RPO 및 RTO 요구 사항을 구분해야 합니다. 일부 애플리케이션 환경에서는 비교적 일반적인 사용자 오류부터 데이터 센터 파괴에 이르는 데이터 손실 상황에 대해 0의 RPO와 0에 가까운 RTO가 필요합니다. 그러나 이러한 높은 수준의 보호를 위해서는 비용과 관리 상의 문제가 발생합니다.

일반적으로 비재해 데이터 복구 요구사항은 두 가지 이유로 엄격해야 합니다. 첫째, 애플리케이션 버그와 사용자 오류로 인해 데이터가 손상되는 것은 거의 불가피한 시점까지 예상할 수 있습니다. 둘째, 스토리지 시스템이 폐기되지 않는 한 RPO 0과 낮은 RTO를 제공할 수 있는 백업 전략을 설계하는 것은 쉽지 않습니다. 쉽게 해결할 수 있는 심각한 위험을 해결하지 않을 이유가 없습니다. 따라서 로컬 복구에 대한 RPO 및 RTO 목표를 적극적으로 적용해야 합니다.

재해 복구 RTO 및 RPO 요구 사항은 재해 가능성 및 관련 데이터 손실 또는 비즈니스 중단 결과에 따라 더 크게 달라집니다. RPO 및 RTO 요구 사항은 일반적인 원칙이 아닌 실제 비즈니스 요구 사항을 기반으로 해야 합니다. 여러 논리적 및 물리적 재해 시나리오를 고려해야 합니다.

데이터 보호 전략의 마지막 측면은 데이터 보존 시간이며, 이는 크게 달라질 수 있습니다.