네트워크 / 스토리지

백업·복구 시스템의 '재설계 시점'을 판단하는 5가지 기준

W. Curtis Preston | Network World 2020.04.02
백업 및 복구 시스템이 제대로 작동하는지 확인하는 것은 백업 및 복구에 걸리는 시간을 아는 것보다 더 중요하다. 이를 판단하는 핵심 지표를 파악하면 시스템이 정상적인 상태인지 혹시 재설계가 필요한지 판단하는 열쇠가 된다. 기업에서 시스템이 비즈니스 요구를 충족하는지 판단하는 데 활용할 수 있는 5가지 평가 기준을 알아보자.
 
ⓒ Getty Images Bank
 

저장 용량 및 사용량

매우 기본적인 기준부터 시작하자. 회사의 백업 시스템에 현재와 미래의 백업 및 복구 요구를 충족하기에 충분한 저장 용량이 있는가? 테이프 라이브러리 또는 스토리지 어레이와 관계없이, 스토리지 시스템 용량은 한정돼 있으며, 용량이 얼마인지, 시간이 지남에 따라 사용률이 어떻게 변하는지 모니터링해야 한다.

이런 모니터링에 실패하면 회사 정책에 위배될 수 있는 결정을 내려야 할 수도 있다. 예를 들어 추가 구매 없이 용량을 늘리는 유일한 방법은 기존의 백업을 삭제하는 것이다. 스토리지 시스템 용량을 모니터링하지 못해 회사에서 정한 보존 요건을 충족하지 못하게 되는 것이다. 이럴 때는 클라우드 기반 객체 스토리지가 해법이 될 수 있다. 일부 서비스는 기본적으로 무제한 용량을 제공한다.
 

처리량과 사용량

모든 스토리지 시스템은 매일 일정 규모의 백업을 수용할 수 있다. 일반적으로 초당 메가바이트 또는 시간당 테라바이트로 정도다. 이런 수치를 잘 이해하고 백업 시스템의 사용량을 모니터해야 한다. 그렇지 않으면 백업 시간이 한없이 늘어날 수 있다.

무엇보다 테이프의 처리량과 사용량을 모니터하는 것이 중요하다. 백업 처리량은 테이프 드라이브의 데이터 전송 처리량과 일치해야 한다. 특히 테이프 드라이브에 공급하는 처리량은 테이프 드라이브의 최소 속도 이상이어야 한다. 드라이브와 공급업체의 지원 시스템에 대한 설명서를 참조해 허용하는 최소 속도가 얼마인지 확인하고 가능한 가깝게 맞춰야 한다. 테이프 드라이브의 최대 속도에 접근할 가능성은 작지만 모니터해야 한다.
 

컴퓨팅 용량과 사용량

백업 시스템의 기능은 그 뒤에 있는 컴퓨팅 시스템의 기능에 좌우된다. 백업 서버의 처리 능력이나 백업 시스템 뒤의 데이터베이스 처리 능력이 따라가지 못하면 백업 속도가 느려져 작업에 영향을 미칠 수 있다. 또한 백업 시스템의 성능을 모니터해 이런 상황이 어느 정도나 발생하는지 확인해야 한다.
 

백업 윈도우

앞서 살펴본 두 평가 기준은 백업 윈도우에 영향을 미치기 때문에 매우 중요하다. 백업 윈도우는 백업을 실행할 수 있는 기간이다. 백업 중에 기본 시스템의 성능에 큰 영향을 미치는 기존 백업 시스템을 사용하는 경우 백업 윈도우(백업 기간)에 대해 미리 조처해야 한다. 전체 윈도우를 거의 채울 정도라면 윈도우를 다시 검토하거나 백업 시스템을 재설계 해야 할 시기임을 의미한다.

단, CDP(Continuous Data Protection), Near-CDP, 블록 레벨 증분 백업, 또는 소스 중복 제거 백업과 같은 증분-영구 범주에 속하는 백업 기술을 사용하는 기업이라면 일반적으로 백업 윈도우에 대해 걱정할 필요가 없다. 이 프로세스는 기본 시스템에 미치는 성능 영향이 매우 적고, 백업이 매우 짧은 시간 동안 수행돼 적은 양의 데이터를 전송하기 때문이다. 또한 이런 시스템을 사용하는 기업은 보통 온종일, 1시간 또는 5분 간격으로 백업을 수행해야 한다. 진정한 CDP 시스템은 지속해서 실행되며, 새로운 데이터가 쓰여질 때마다 백업된다.
 

실제 복구 시점 및 복구 시간

백업에 시간이 얼마나 걸리든 실제로 우려하는 사람은 없다. 대신 정말 걱정하는 것은 복구에 걸리는 시간이다. 복구시간목표(Recovery Time Objective, RTO)는 사고 발생 이후 복구에 필요한 시간이다. 허용되는 RTO의 길이는 보통 시스템이 중단됐을 때 손실되는 비용에 따라 결정된다.

예를 들어 기업이 시스템 중단 시간 동안 수백만 달러의 손실을 보는 경우 매우 엄격한 RTO를 규정한다. 특히 금융 회사는 가능한 0에 가까운 RTO를 추구한다. 더 긴 중단 시간을 견딜 수 있는 기업의 RTO는 몇 주까지 될 수 있다. 중요한 것은 RTO가 기업의 비즈니스 요구와 일치하느냐다. 또한, 기업 전체에 걸쳐 단일 RTO만 있어야 하는 것은 아니다. 데이터센터에서 더 중요한 애플리케이션에는 엄격한 RTO를, 나머지에는 더 완화된 RTO를 적용하는 것이 지극히 정상적이고 합리적이다.

목표복구시점(Recovery Point Objective, RPO)은 대규모 사고 후 허용되는 데이터 손실량으로, 시간 단위로 측정된다. 예를 들어 1시간 분량의 데이터를 잃을 수 있다고 설정하면, 1시간의 RPO를 동의한 것이다. 그러나 대부분의 기업은 24시간 이상과 같이 훨씬 큰 값을 설정한다. RPO가 작을수록 백업 시스템을 더 자주 실행해야 하기 때문이다. 많은 기업에서 더 엄격한 RPO를 원할 수 있지만, 현재 백업 시스템으로는 불가능하다는 것을 알고 있다. RTO와 마찬가지로, 서로 다른 데이터 세트의 중요도에 따라 다양한 RPO를 설정하는 것이 일반적이다.

실제 복구 시점 및 복구 시간 평가 기준은 실제 또는 테스트를 통해 복구가 발생한 경우에만 측정된다. RTO와 RPO는 목표이며, RPR과 RTR은 복구 후 해당 목표를 달성한 정도를 의미한다. 이를 측정한 후 RTO와 RPO와 비교해 백업 및 복구 시스템의 재설계를 고려해야 할지 결정할 수 있다. 그러나 현실에서 대부분의 기업의 RTR 및 RPR은 내부에서 합의된 RTO와 RPO에 거의 미치지 못한다. 중요한 것은 이 현실을 공개하고 인정하는 것이다. RTO와 RPO를 조정하거나 백업 시스템을 재설계해야 한다. RTR과 RPR이 RTO나 RPO와 크게 차이난다면 굳이 RTO나 RPO를 엄격하게 설정할 필요가 없다.
 

평가 기준으로 해야 할 일

백업 시스템에 대한 신뢰도를 높일 수 있는 방법의 하나는 지금까지 살펴본 모든 평가 기준을 문서화하고 공유하는 것이다. 백업 시스템이 설계한 대로 성능이 나오는지 의사결정권자에게 알려야 한다. 현재 증가율을 기준으로 추가 용량을 구입하기까지 얼마나 걸리는지도 중요하다. 무엇보다 백업 및 복구 시스템이 미리 정한 RTO와 RPO를 충족하는지 파악해야 한다. 이 사실을 숨기면 정작 정전 같은 사고가 발생했을 때 아무에게도 도움이 되지 않는다. editor@itworld.co.kr
 Tags 복구 백업

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.