복원과 백업을 모두 효율적으로··· ‘통합 풀 백업’이란?

통합 풀 백업의 발명(synthetic full backup)은 디스크 기반 백업, 중복 제거, CDP, 클라우드 등과 더불어 지난 몇 십 년 동안 백업 기술 분야에서 이룩된 가장 중요한 발전에 속한다. 통합 풀 백업이 어떻게 탄생하게 되었고 어떤 장점이 있는지 소개한다.
 

전통적인 백업 옵션
백업 단계에는 기본적으로 크게 2가지 범주가 있다. 모든 것을 백업하거나(풀 백업) 아니면 변경된 것만 백업하는 것 (증분 백업 ; incremental backup)이다. 증분 백업에는 다양한 종류가 있는데 이번에 다루는 내용과는 그다지 관련이 없다. 증분 백업은 매일 밤, 전체 백업은 매주(또는 그 보다 긴 주기로) 실행하는 것이 보통이다.

주기적으로 전체 백업을 실행하는 이유는 복원을 수행할 때 일어나는 일 때문이다. 전통적인 백업 소프트웨어는 전체 백업본에 있는 데이터를 모두 복원한다. 해당 테이프에 있는 데이터 중 일부가 새로운 버전으로 바뀌어 증분 백업본에 있게 되는 경우에도 마찬가지이다. 복원 과정이 실행되면 다양한 증분 백업본 상에 있는 새로운 파일이나 업데이트된 파일이 생성 순서대로 복원되기 시작한다.

이처럼 어차피 덮어쓰게 될 데이터를 복원하는 것을 비롯해 복원을 여러 번 실행하는 것은 당연히 비효율적이다. 테이프에서 복원을 하는 경우, 각 테이프를 넣고 로딩하는 시간도 추가되고 테이프 상의 적절한 위치도 찾아야 하고 테이프가 더 이상 필요 없어지면 꺼내기도 해야 한다. 테이프 하나 당 5분 이상 소요될 수 있다.

즉, 이런 종류의 구성에서는 전체 백업이 잦으면 잦을수록 복원에서 낭비되는 시간이 적기 때문에 복원 속도가 빨라지게 된다. (복원의 관점에서 보면 매일 밤 전체 백업이 이상적이다.) 그렇기 때문에 모든 시스템에서 일주일에 한 번 전체 백업을 실행하는 것이 그렇게 흔한 것이다. 단 시스템의 자동화 정도가 늘어나면서 전체 백업을 매월 또는 매분기 하는 쪽으로 바꾼 조직들도 있다.

그런데, 사용 중인 서버나 VM에 전체 백업을 수행하면 그 서버에 상당한 부하가 생긴다. 따라서, 백업 관리자 입장에서는 복원에 시간이 오래 걸리는 결과를 낳게 되더라도 전체 백업 빈도를 최대한 줄이려고 한다. 백업과 복원 효율성 사이에 이러한 줄다리기가 통합 풀 백업 탄생의 주요 원인이다.

통합 풀 백업이란?
통합 풀 백업이란 복원 도중에는 풀 백업처럼 행동하지만 백업 도중에는 그렇지 않은 백업이다. 사실, 일반적인 통합 풀 백업 구성에서 전체 백업은 거의 사용되지 않는다. 이를 가능하게 하는 주요 방법은 3가지가 있다.

통합 풀 백업본을 만드는 첫 번째이자 아마도 가장 흔한 방법은 사용 가능한 백업본에서 하나 만드는 것이다. 백업 시스템은 백업할 때마다 발견된 모든 데이터에 대한 목록을 작성한다. 따라서 전통적인 방식으로 전체 백업본을 만들려고 할 때 그 안에 포함될 모든 파일과 그 파일의 버전을 항시 파악하고 있다. 

각 파일을 한 매체에서 다른 매체로 간단히 복사한다. 이 방법은 테이프나 디스크에서 활용할 수 있다. 단, 여러 대의 장치가 이용 가능해야 한다.

이러한 통합 풀 백업 수행 방식은 시간이 꽤 소요될 수 있다. 단, 백업 중인 시스템에 아무런 영향을 미치지 않고 하루 중 어느 시간에도 실행 가능하다. 사실, 백업 중인 서버나VM은 전혀 관여되지 않는다. 

그 결과 만들어진 백업본은 어디를 보나 전체 백업이며 그 이후의 증분 백업은 그 전체 백업본을 바탕으로 만들 수 있다. 이 방법의 유일한 단점은 전체 백업본 복사에 필요한 시간이다.

두 번째 방법은 디스크를 기본 백업 대상으로 사용하는 경우에만 가능하다. 또한, 백업 시스템이 변경된 각 파일이나 블록을 스토리지 시스템에 별도의 개체로 저장하는 경우에만 가능하다. 

백업 시스템이 전통적으로 백업본을 저장하던 방식, 즉, 여러 파일을 컨테이너 내부에 넣는(예: tar형식 또는 상용 백업 형식)과는 대비된다. 만일 변경된 파일이나 블록이 모두 개별적인 데이터 덩어리로 저장된다면, 전체 백업본을 구성하는 현재 덩어리의 최신 버전 대한 스냅샷같은 뷰를 만드는 것만으로 통합 풀 백업본을 생성할 수 있다.

이 방법에는 장점이 많다. 먼저, 데이터의 이동이 없기 때문에 통합 풀 백업본을 만드는 시간이 거의 걸리지 않는다. 이로 인해 통합 풀 백업본을 훨씬 더 자주 만들 수 있게 된다. 

실제로 이 방식을 지원하는 시스템은 대부분 백업할 때마다 그 이후에 전체 백업본을 만들게 된다. 즉, 시스템은 증분 백업만 수행하지만 백업본은 모두 전체 백업본처럼 행동한다는 뜻이다. 이를 두고 보통 블록 수준 증분 영구 백업 시스템이라고 한다. 전통적인 방식으로든 위에서 언급한 복사 방법을 사용하든 전체 백업본을 만들어야 할 일이 다시는 없기 때문이다.

마지막으로, 이 2가지 방식을 어느 정도 혼합한 방식이 있다. 중복 제거 대상 시스템에서만 가능하다. 위에서 언급한 두 번째 방식과 같이, 모든 백업본이 작은 데이터 덩어리로 저장된다. 

그 결과, 변경된 각 파일이나 블록은 중복 제거 대상 시스템에 저장된 여러 개의 작은 덩어리로 표현된다. 즉, 이 기기에서 가상 전체 백업본을 생성할 수 있으며 시간도 거의 걸리지 않는다(위에서 언급한 증분 영구 방법과 유사). 

이 과정은 백업 제품을 통해서도 통제할 수 있다. 백업 제품은 중복 제거 대상 시스템에게 통합 풀 백업본을 생성하라는 명령을 내리게 된다. 위에서 언급한 두 번째 방식과 같이, 이 방법은 매우 효율적이며 거의 동시에 이루어진다.

통합 풀 백업 지원 여부
복사 방법을 쓰든, 블록 수준 증분 영구 백업 방법을 쓰든, 중복 제거 대상 시스템에서 사용하는 가상 복사 방법을 쓰든, 통합 풀 백업은 대부분의 상용 백업 시스템에서 매우 흔해졌다. 이 기능을 사용하지 않고 있는 사람이라면 본인의 하드웨어 및 소프트웨어 셋업에서 가능한지 알아봐야 할 때가 되었다고 할 수 있다. 만일 가능하지 않다면, 본인의 백업 시스템이 시대에 약간 뒤떨어져 있다는 의미일 수도 있다. 

* W. 커티스 프레스톤은 1993년부터 스토리지, 백업, 복원 분야에 종사해왔다. 현재는 클라우드 기반 데이터 보호 기업 드루바에 속해 있다. ciokr@idg.co.kr