Recovery 요구 사항 평가 데이터 보호 계획 #1

Recovery 요구 사항 평가 데이터 보호 계획 #1

• critical 데이터 식별 및 우선 순위 지정 

• 데이터 중요도에 대한 기본 Recovery 요구 사항 

RPO(RecoveryPoint Objective): 데이터 손실 허용 한도 

백업을 얼마나 자주 수행해야 합니까? 

Point-in-time Recovery가 필요합니까? 

RTO(RecoveryTime Objective): 다운타임 허용 한도 

다운타임: 문제 식별 + Recovery 계획 + 시스템 Recovery 

세분성 레벨별 계층 RTO(데이터베이스, 테이블스페이스, 테이블, 행) 

온사이트, 오프사이트 및 장기 백업에 대한 백업 Retention 정책 결정

Recovery 요구 사항 평가 Recovery 요구 사항을 올바르게 평가하려면 손실되거나 사용할 수 없는 데이터베이스가 업무에 얼마나 중요한지를 먼저 확인해야 합니다.   다음 사항을 고려하십시오.  -다운타임 시간당 회사의 손실은 얼마입니까?  -데이터베이스가 작동 중지될 경우 생산성 및 인건비 손실은 얼마입니까?  이러한 비용을 수량화하면 데이터베이스 Failure 방지 및 Recovery를 위한 하드웨어 및 저장 영역 비용 지출의 당위성을 얻을 수 있습니다.   다음 단계는 중요도에 따라 데이터베이스를 분류합니다.   예를 들어, 유저 커뮤니티에 허용되는 몇 시간의 다운타임 동안 일괄 처리 로드를 다시 실행할 수 있어서 12시간 동안의 데이터 손실이 허용될 수 있는 대규모 데이터 웨어하우징 보고 시스템이 회사에 있다면, 이 유형의 시스템에는 디스크/테이프 백업 전략이 적합할 수 있습니다.   그러나 다른 회사에 데이터베이스 작동 중지로 인한 시간당 수익 손실이 100,000달러에 이르기 때문에 몇 분 동안의 데이터 손실 및 다운타임만 허용될 수 있는 중요한 OLTP 시스템이 있다면 , 이 시스템은 일반적인 백업 및 Recovery 솔루션만으로는 충분하지 않을 수 있습니다.   이런 회사의 경우는 Oracle Data Guard와 같은"최소 다운타임 솔루션"을 고려해야 합니다. Recovery 요구 사항 평가(계속) 허용되는 데이터 손실 규모를 평가하는 데 도움이 되는 RPO(Recovery Point Objective)를 결정합니다.  다음 사항을 고려하십시오. -백업을 더 자주 수행해야 하는 데이터베이스가 있습니까? -아카이브된 로그에 사용할 수 있는 디스크 공간이 충분합니까(예를 들어, point-in-time Recovery의 경우)? 허용할 수 있는Recovery 시간을 결정하기 위해 RTO(Recovery Time Objective)를 고려합니다.  이 시간은 몇 시간 아니면 몇 분 정도일까요? RTO는 데이터베이스 및/또는 서버에 따라 다릅니다.  중요한 데이터베이스인 경우 더 까다로운 RTO 요구 사항을 충족하기 위해 디스크 및 테이프 백업을 결합해야 할 수 있습니다.  디스크 및 테이프에서 원하는 Recovery 기능을 결정했으면 백업의 Retention 기간을 평가합니다.