2018.12.21

“재난을 대비하는 의사 결정” 오프사이트 데이터 백업 방법

W. Curtis Preston | Network World
백업을 오프사이트로 보내야 한다는 데는 모두가 동의하지만 그 방법에 대해서는 의견이 분분하다. 어느 방법을 선택하는지도 중요한 의사 결정이다. 각 방법에 따라 복구 시간 목표(RTO)와 복구 시점 목표(RPO), 위험 수준, 그리고 비용이 좌우되기 때문이다.
 

백업 RTO에 영향을 미치는 요소

데이터를 오프사이트에 저장하는 방법은 여러가지 중요한 요소에 영향을 미친다. 오프사이트 방법에 따라 RTO, 즉 손실된 데이터를 복원하는 데 얼마나 시간이 걸릴지가 결정된다.
 
예를 들어 페덱스 같은 일반적인 배송업체를 사용해서 멀리 떨어진, 위험이 미치지 않는 곳으로 테이프를 보내는 방법이 있다. 자연 재해가 발생해서 회사 시설과 인근의 오프사이트 스토리지 업체까지 모두 피해를 입는 상황을 우려할 때 주로 이용하는 방법이다. 위험 회피 관점에서 타당한 면도 있지만, 유일한 복사본이 페덱스의 배송을 이용해야만 받을 수 있는 거리에 있다면 RTO는 매우 길어진다. 훨씬 더 가까운 지점에 데이터를 저장하면 RTO를 대폭 단축할 수 있다.
 

백업 RPO에 영향을 미치는 요소

오프사이트 방법은 RPO, 즉 마지막 백업과 데이터 손실을 유발한 사고 사이의 공백에도 영향을 미친다. 아이언 마운틴(Iron Mountain)에 테이프 배송을 맡겼는데 이 업체가 하루에 한 번만 방문한다면 가능한 최선의 RPO는 24~48시간이다. 최악의 경우를 가정하면 사실 RPO는 이보다 훨씬 더 길어질 수 있다. 오프사이트 방법을 고민할 때는 RPO를 반드시 감안해야 한다.
 

백업 위험 평가

오프사이트 백업 방법은 RTO와 RPO 외에 위험 수준에도 영향을 미친다. 바로 옆에 있는 핫 사이트에 데이터 복사본을 저장하는 경우 탁월한 RPO를 달성할 수 있겠지만 대형 재해가 발생하면 두 곳이 모두 피해를 입게 된다. 예를 들어 뉴욕 쌍둥이 빌딩 중 하나에 입주해 있으면서 맞은편 빌딩에 핫 사이트를 뒀다가 9/11 사고로 폐업한 기업이 여럿 있다.
 
데이터가 멀리 위치할수록 위험은 줄어든다. 데이터가 가까울수록 동기 복제 등, 더 나은 RPO를 구현할 수 있다. 우선 완화할 위험과 감수할 위험을 결정해야 한다. 그런 다음 이러한 위험을 기준으로 데이터를 오프사이트로 보내는 방법을 선택해야 한다.
 

백업 비용 감안할 것

오프사이트 방법에 따라 비용도 달라진다. 비용이 가장 덜 드는 선택안은 지난밤 백업의 유일한 복사본을 페덱스를 통해 자회사로 보내는 방법이고, 가장 값비싼 선택안은 인접한 라이브 복사본을 동기식으로 업데이트하는 방법일 것이다. 각 방법에 따라 RTO와 RPO, 위험 수준, 비용이 제각기 다르므로 이러한 모든 요소를 감안해서 가장 적절한 방법을 결정해야 한다.
 

오프사이트로 백업 보내기

오프사이트로 테이프를 배송한다면 원본을 보낼지 복사본을 보낼지, 두 가지 옵션이 있다. 많은 기업이 원본 테이프를 오프사이트로 보낸다. 가장 쉽고 비용이 덜 들기 때문이다. 그러나 여기에는 몇 가지 문제가 따른다. 오프사이트 백업이 유일한 백업인 경우 복구를 위한 온사이트 백업이 없으므로 RTO가 길어진다는 것이다.
 
일부 기업은 백업을 일주일 동안 온사이트에 보관한 다음 지난주 분의 백업을 오프사이트에 보내는 방법으로 이 문제에 대처한다. 이 경우 운영 복구 측면에서 안심할 수 있는 RTO를 확보하게 되지만, 재해 발생 시 RPO는 형편없게 된다. 대다수 전문가가 원본 백업을 오프사이트로 보내는 데 반대하는 이유가 여기에 있다.
 
원본을 오프사이트로 보내는 방법의 대안은 복사본을 오프사이트로 보내고 원본을 온사이트에 두는 방법이다. 현재 대부분의 데이터센터는 먼저 중복 제거 디스크 시스템에 백업한 다음 테이프에 복사하는 방법으로 이를 구현한다. DR을 위한 유일한 옵션이 테이프라면 이 방법이 최적이다.
 
보편적으로 사용되는 또 다른 오프사이트 방법은 백업을 오프사이트로 복제하는 기능이 있는 중복 제거 디스크 시스템을 사용하는 것이다. 중복 제거는 백업을 저장하는 데 필요한 디스크 용량을 줄이는 것 외에 지난밤 백업을 복제하는 데 필요한 대역폭도 줄여준다.
 
이 방법의 장점은 배송업체에 의존할 필요가 일체 없이 온사이트와 오프사이트에 모두 디스크 기반 백업을 두게 된다는 점이다. 단점은 비용이다. 두 개의 중복 제거 시스템을 구매해야 하는 데다 대역폭 비용도 상당하기 때문이다. 그래서 많은 기업이 위에 언급한 디스크-디스크-테이프 방식을 채택한다. 그러나 비용만 감당할 수 있다면 오프사이트로 복제하는 중복 제거 디스크 시스템은 완전히 자동화된 온사이트 및 오프사이트 백업을 구축하기 위한 아주 좋은 방법이다.
 

타겟 중복 제거냐, 소스 중복 제거냐

타겟 중복 제거를 사용하면 일반적으로 중복 제거는 백업 소프트웨어가 아닌 스토리지 대상 근처에 있는 서드파티 어플라이언스가 수행한다. 소스 중복 제거는 대체로 백업 소프트웨어에 의해, 백업 프로세스의 시작 시점에 백업되는 클라이언트(소스)에서 수행된다. 백업 클라이언트는 직접 오프사이트로 백업을 전송할 수 있다.
 
소스 중복 제거의 장점은 온사이트 어플라이언스가 불필요하다는 점이다. 온사이트 어플라이언스를 두지 않을 때의 단점은 원본 백업 테이프를 오프사이트 스토리지 업체로 바로 보내는 경우와 같다. 즉, RTO가 길어진다는 점이다. 그래서 소스 중복 제거가 가능한 업체 일부는 온사이트에 데이터 복사본을 저장하는 옵션도 함께 제공한다. 이 방법을 선택하는 기업은 일반적으로 규모가 큰 데이터센터용으로 어플라이언스를 사용하고, 소규모 사무실이나 노트북에 대해서는 어플라이언스를 사용하지 않는다.
 

일단 오프사이트로 보내기

어느 방법이든 아무것도 하지 않는 것보다는 낫다. 오래 전에 서버 위 박스 안에 백업 테이프를 넣어 두었다가 모든 데이터를 잃은 사람이 있었다. 서버에 불이 붙어 테이프도 함께 전소된 것이다. 이후 이 사람은 한 강연에서 문제는 테이프이며, 모든 백업은 디스크에 해야 한다고 역설했다. 디스크 기반 백업은 그로부터 10년 뒤에나 실현되었으니, 시대를 앞서갔다고 할 수 있다.
 
그러나 정작 중요한 교훈을 놓쳤다. 문제는 테이프가 아니었다. 유일한 백업 복사본과 백업 대상을 동일한 곳에 보관하는 습관은 반드시 재앙으로 이어진다. 지금 백업을 오프사이트로 보내지 않고 있다면 최대한 빨리 보낼 방법을 강구하라. 어떻게 보내는지는 문제가 아니다. 할 수 있다면 일단 보내야 한다. editor@itworld.co.kr 


2018.12.21

“재난을 대비하는 의사 결정” 오프사이트 데이터 백업 방법

W. Curtis Preston | Network World
백업을 오프사이트로 보내야 한다는 데는 모두가 동의하지만 그 방법에 대해서는 의견이 분분하다. 어느 방법을 선택하는지도 중요한 의사 결정이다. 각 방법에 따라 복구 시간 목표(RTO)와 복구 시점 목표(RPO), 위험 수준, 그리고 비용이 좌우되기 때문이다.
 

백업 RTO에 영향을 미치는 요소

데이터를 오프사이트에 저장하는 방법은 여러가지 중요한 요소에 영향을 미친다. 오프사이트 방법에 따라 RTO, 즉 손실된 데이터를 복원하는 데 얼마나 시간이 걸릴지가 결정된다.
 
예를 들어 페덱스 같은 일반적인 배송업체를 사용해서 멀리 떨어진, 위험이 미치지 않는 곳으로 테이프를 보내는 방법이 있다. 자연 재해가 발생해서 회사 시설과 인근의 오프사이트 스토리지 업체까지 모두 피해를 입는 상황을 우려할 때 주로 이용하는 방법이다. 위험 회피 관점에서 타당한 면도 있지만, 유일한 복사본이 페덱스의 배송을 이용해야만 받을 수 있는 거리에 있다면 RTO는 매우 길어진다. 훨씬 더 가까운 지점에 데이터를 저장하면 RTO를 대폭 단축할 수 있다.
 

백업 RPO에 영향을 미치는 요소

오프사이트 방법은 RPO, 즉 마지막 백업과 데이터 손실을 유발한 사고 사이의 공백에도 영향을 미친다. 아이언 마운틴(Iron Mountain)에 테이프 배송을 맡겼는데 이 업체가 하루에 한 번만 방문한다면 가능한 최선의 RPO는 24~48시간이다. 최악의 경우를 가정하면 사실 RPO는 이보다 훨씬 더 길어질 수 있다. 오프사이트 방법을 고민할 때는 RPO를 반드시 감안해야 한다.
 

백업 위험 평가

오프사이트 백업 방법은 RTO와 RPO 외에 위험 수준에도 영향을 미친다. 바로 옆에 있는 핫 사이트에 데이터 복사본을 저장하는 경우 탁월한 RPO를 달성할 수 있겠지만 대형 재해가 발생하면 두 곳이 모두 피해를 입게 된다. 예를 들어 뉴욕 쌍둥이 빌딩 중 하나에 입주해 있으면서 맞은편 빌딩에 핫 사이트를 뒀다가 9/11 사고로 폐업한 기업이 여럿 있다.
 
데이터가 멀리 위치할수록 위험은 줄어든다. 데이터가 가까울수록 동기 복제 등, 더 나은 RPO를 구현할 수 있다. 우선 완화할 위험과 감수할 위험을 결정해야 한다. 그런 다음 이러한 위험을 기준으로 데이터를 오프사이트로 보내는 방법을 선택해야 한다.
 

백업 비용 감안할 것

오프사이트 방법에 따라 비용도 달라진다. 비용이 가장 덜 드는 선택안은 지난밤 백업의 유일한 복사본을 페덱스를 통해 자회사로 보내는 방법이고, 가장 값비싼 선택안은 인접한 라이브 복사본을 동기식으로 업데이트하는 방법일 것이다. 각 방법에 따라 RTO와 RPO, 위험 수준, 비용이 제각기 다르므로 이러한 모든 요소를 감안해서 가장 적절한 방법을 결정해야 한다.
 

오프사이트로 백업 보내기

오프사이트로 테이프를 배송한다면 원본을 보낼지 복사본을 보낼지, 두 가지 옵션이 있다. 많은 기업이 원본 테이프를 오프사이트로 보낸다. 가장 쉽고 비용이 덜 들기 때문이다. 그러나 여기에는 몇 가지 문제가 따른다. 오프사이트 백업이 유일한 백업인 경우 복구를 위한 온사이트 백업이 없으므로 RTO가 길어진다는 것이다.
 
일부 기업은 백업을 일주일 동안 온사이트에 보관한 다음 지난주 분의 백업을 오프사이트에 보내는 방법으로 이 문제에 대처한다. 이 경우 운영 복구 측면에서 안심할 수 있는 RTO를 확보하게 되지만, 재해 발생 시 RPO는 형편없게 된다. 대다수 전문가가 원본 백업을 오프사이트로 보내는 데 반대하는 이유가 여기에 있다.
 
원본을 오프사이트로 보내는 방법의 대안은 복사본을 오프사이트로 보내고 원본을 온사이트에 두는 방법이다. 현재 대부분의 데이터센터는 먼저 중복 제거 디스크 시스템에 백업한 다음 테이프에 복사하는 방법으로 이를 구현한다. DR을 위한 유일한 옵션이 테이프라면 이 방법이 최적이다.
 
보편적으로 사용되는 또 다른 오프사이트 방법은 백업을 오프사이트로 복제하는 기능이 있는 중복 제거 디스크 시스템을 사용하는 것이다. 중복 제거는 백업을 저장하는 데 필요한 디스크 용량을 줄이는 것 외에 지난밤 백업을 복제하는 데 필요한 대역폭도 줄여준다.
 
이 방법의 장점은 배송업체에 의존할 필요가 일체 없이 온사이트와 오프사이트에 모두 디스크 기반 백업을 두게 된다는 점이다. 단점은 비용이다. 두 개의 중복 제거 시스템을 구매해야 하는 데다 대역폭 비용도 상당하기 때문이다. 그래서 많은 기업이 위에 언급한 디스크-디스크-테이프 방식을 채택한다. 그러나 비용만 감당할 수 있다면 오프사이트로 복제하는 중복 제거 디스크 시스템은 완전히 자동화된 온사이트 및 오프사이트 백업을 구축하기 위한 아주 좋은 방법이다.
 

타겟 중복 제거냐, 소스 중복 제거냐

타겟 중복 제거를 사용하면 일반적으로 중복 제거는 백업 소프트웨어가 아닌 스토리지 대상 근처에 있는 서드파티 어플라이언스가 수행한다. 소스 중복 제거는 대체로 백업 소프트웨어에 의해, 백업 프로세스의 시작 시점에 백업되는 클라이언트(소스)에서 수행된다. 백업 클라이언트는 직접 오프사이트로 백업을 전송할 수 있다.
 
소스 중복 제거의 장점은 온사이트 어플라이언스가 불필요하다는 점이다. 온사이트 어플라이언스를 두지 않을 때의 단점은 원본 백업 테이프를 오프사이트 스토리지 업체로 바로 보내는 경우와 같다. 즉, RTO가 길어진다는 점이다. 그래서 소스 중복 제거가 가능한 업체 일부는 온사이트에 데이터 복사본을 저장하는 옵션도 함께 제공한다. 이 방법을 선택하는 기업은 일반적으로 규모가 큰 데이터센터용으로 어플라이언스를 사용하고, 소규모 사무실이나 노트북에 대해서는 어플라이언스를 사용하지 않는다.
 

일단 오프사이트로 보내기

어느 방법이든 아무것도 하지 않는 것보다는 낫다. 오래 전에 서버 위 박스 안에 백업 테이프를 넣어 두었다가 모든 데이터를 잃은 사람이 있었다. 서버에 불이 붙어 테이프도 함께 전소된 것이다. 이후 이 사람은 한 강연에서 문제는 테이프이며, 모든 백업은 디스크에 해야 한다고 역설했다. 디스크 기반 백업은 그로부터 10년 뒤에나 실현되었으니, 시대를 앞서갔다고 할 수 있다.
 
그러나 정작 중요한 교훈을 놓쳤다. 문제는 테이프가 아니었다. 유일한 백업 복사본과 백업 대상을 동일한 곳에 보관하는 습관은 반드시 재앙으로 이어진다. 지금 백업을 오프사이트로 보내지 않고 있다면 최대한 빨리 보낼 방법을 강구하라. 어떻게 보내는지는 문제가 아니다. 할 수 있다면 일단 보내야 한다. editor@itworld.co.kr 


X