스토리지나 데이터베이스를 백업 및 복구하는 과정에서 설정하게되는 중요 지표(값)이 몇개 등장하는데요 RPO(Recovery Point Object) 와 RTO(Recovery Time Objective) 에 대해서 정리해 봅니다.
이 두가지 지표는 결국 Recovery와 아주 밀접한 과계가 있습니다.
1. RTO(Recovery Time Objective)
어떠한 특별한 어플리케이션 없이도 얼마나 버틸수 있느냐와 관계가 있습니다(시간). 그래서 종종 허용할 수 있는 최대 허용 다운타임과 연관되어 사용되기도 합니다.
RTO는 실제로 리플리케이션, 테이프/디스크 백업에 사용됩니다. 또한 HA 클러스터 구성이나 혹은 그 이상의 견고한 시스템을 구축하는 것과 동반하여 사용되기도 합니다.
만일 RTO가 0(zero)이라고 한다면 이는 해당 애플리케이션이 완벽하게 이중화되어 있고 데이터가 오프 사이트와 그 밖의 장소에 복제되어 보관되어 있어야 함을 의미합니다. 만일 RTO가 48시간 또는 72시간이라면 테이프 백업으로도 충분할 것입니다.
Maximum length of time a system can be down
Glacier takes 3 to 5 hours to restore objects
2. RPO(Recovery Point Object)
허용할 수 있는 데이터의 손실양과 관계되는 것으로 내가 손실을 경험/허용 할 수 있는 최대의 데이터 양이 얼마인가에 관한 문제입니다..
다른 말로 하면, 만일 내가 오후 7시에 백업을 하였고, 이 시스템이 다음날 4시(오전)에 붕괴되었다고 한다면, 내가 백업을 하고 난 이후의 데이터들은 완전히 날아가게 되는 것입니다. 이러한 상황에서 RPO는 바로 전날 백업한 것이 됩니다.
High backup frequency means low RPO
Write/delete event to trigger incremental backup means low RPO
결국, RTO와 RPO는 실제로 리던던시의 종류와 백업 인프라에 영향을 미치고 서로 연관이 있게 된다. RTO가 타이트해 질 수록 RPO도 타이트 해 진다. 물론 비용도 동반 상승하게 되고 인프라 환경에 더 많은 돈이 투자되어야 함을 의미하는 것이다.
'DevOps' 카테고리의 다른 글
CentOS7 에 Puppet server/agent 설치 (0) | 2017.07.21 |
---|---|
AWS Route table 설정과 해석 (0) | 2017.06.10 |
성공적인 Git branching model 전략 (0) | 2017.06.06 |
AWS S3를 이용하여 Maven Private Repository 생성하기. (1) | 2017.06.05 |
스크럼(Scrum) 요약 (0) | 2016.10.20 |