2020.07.10

"같이 써야 더 강하다" 항목 수준 백업 vs. 이미지 수준 백업 비교

W. Curtis Preston | Network World
컴퓨터 백업에는 서로 정반대인 두 가지 방법이 있다. 바로 항목 수준 백업과 이미지 수준 백업이다. IT 전문가는 수십년 동안 두 가지 방법을 모두 혼합해 사용해왔다. 두 가지 모두 장단점이 있으므로 대부분의 환경에서는 둘을 혼합해 사용한다.
 
ⓒ gorodenkoff / Getty Images
 

항목 수준 백업

항목 수준 백업은 개별 항목으로 취급되는 각각의 정보 모음을 백업한다. 가장 보편적인 항목 유형은 파일이다. 과거에는 파일 수준 백업이라는 용어를 사용했다.
 
파일 외에 항목 수준 백업에 포함될 수 있는 다른 유형의 항목은 객체 스토리지 시스템의 객체다. 많은 환경에서 객체는 파일과 비슷하다. 객체 스토리지를 사용하는 대부분의 기업에서 객체는 파일과 마찬가지 역할을 한다. 다만 객체 스토리지에 저장되므로 파일은 아니다. 파일은 파일 시스템에 저장된다. 둘의 내용은 같은 경우가 많지만 서로 저장 방법이 다르다는 이유로 서로 다른 이름으로 불린다.
 
일반적으로 항목 수준 백업은 파일 서버, 윈도우나 리눅스 서버, 또는 백업 에이전트가 서버/VM 자체 내에서 실행되는 가상머신에 사용된다. 백업 에이전트는 먼저 파일 시스템(예를 들어 C:\)을 확인해서 백업할 파일을 결정한다. 전체 백업을 수행하는 중이라면 백업 에이전트는 파일 시스템의 모든 파일을 백업하고, 증분 백업 중이라면 마지막 백업 이후 변경된 파일을 백업한다.
 
또한 아마존 S3, 애저 블롭(Blob), 구글 클라우드 스토리지와 같은 객체 스토리지 시스템을 백업하는 경우에도 항목 수준 백업이 사용된다. 이러한 서비스는 일반적으로 데이터 탄력성을 위해 여러 위치로 복제되는데, 왜 굳이 백업을 해야 하는지 의문이 생길 수 있다. 객체 스토리지 내의 복제는 일반적으로 시스템 중단에 대한 내성을 갖도록 설계되지만 항상 객체 자체를 삭제하는 외부 공격까지 견디도록 설계되지는 않는다. 의도적이든, 우발적 또는 악의적인 이유로든 객체가 삭제될 경우 삭제도 모든 복사본으로 복제된다. 이와 같은 상황에 대비한 유일한 보호 방법은 객체 스토리지를 다른 계정으로 항목 수준 백업하는 것이다.
 
항목 수준 백업의 이점은 매우 쉽다는 데 있다. 적절한 곳에 백업 에이전트를 설치하면 에이전트가 파일 또는 객체 스토리지 시스템을 살펴보면서 모든 항목을 찾고 적절한 시점에 백업한다. 전체 파일 또는 객체 스토리지 시스템을 복원하려면 먼저 전체 백업을 복원한 다음 각 후속 증분 백업에서 복원을 수행해야 한다.
 

이미지 수준 백업

이미지 수준 백업은 물리적 또는 가상 디바이스를 블록 수준에서 백업하는 것이다. 그래서 보는 기준에 따라 이미지 수준 백업을 드라이브 수준, 볼륨 수준 또는 가상머신 수준 백업이라고도 한다. 디바이스는 표준 파일 시스템, 데이터베이스용 블록 스토리지, 물리적 또는 가상머신의 부팅 볼륨 등 다양한 정보 유형을 저장할 수 있다. 이미지 수준 백업 내에서는 파일 자체를 백업하는 것이 아니라 파일 시스템의 구성 블록을 백업한다.
 
가상화가 등장하기 전에는 이미지 수준 백업은 극히 드물었다. 물리적 드라이브를 백업하기가 지금보다 훨씬 더 어려웠고 블록을 백업하는 동안 파일시스템의 마운트를 해제해야 했기 때문이다. 그렇지 않을 경우 각 블록을 가져온 시점이 다른, 손상된 백업이 발생할 위험이 있었다. 윈도우 볼륨 섀도우 서비스(VSS)나 VM웨어 스냅샷에 사용되는 것과 같은 가상 스냅샷 기술은 이 근본적인 문제를 해결했다.
 
가상머신이 등장한 이후 볼륨 수준 백업의 인기가 훨씬 더 높아졌다. 이미지 수준 백업으로 하이퍼바이저 수준에서 가상머신 백업을 수행할 수 있다. 백업 소프트웨어는 가상머신 외부에서 실행되며, 이 소프트웨어 관점에서 가상머신은 하나 또는 여러 개의 이미지다(예를 들어 VM웨어의 VMDK 파일).
 
이미지 수준 백업에는 다양한 이점이 있다. 첫째, 백업이 더 빠르고 복원은 훨씬 더 빠르다. 이미지 수준 백업은 파일 또는 객체 스토리지 시스템의 오버헤드를 건너뛰고 바로 기반 스토리지를 다룬다. 파일 수준 백업의 경우 각 파일을 개별적으로 복원해야 하고 이를 위해서는 파일 시스템에 파일을 만들어야 하는데, 상당한 오버헤드가 수반되는 프로세스다. 특히 수많은 파일이 포함된 매우 밀집한 파일 시스템을 복원하는 경우 데이터를 파일로 전송하는 프로세스보다 복원 중에 파일을 생성하는 프로세스에 더 오랜 시간이 걸리면서 이 문제가 두드러지게 나타난다. 이미지 수준 복원은 블록 수준에 바로 데이터를 두기 때문에 이 문제가 없다.
 
스냅샷으로 블록 변경 문제는 해결됐지만 이미지 수준 백업에는 그 다음으로 큰 문제가 있었다. 바로 증분 백업이다. 드라이브, 볼륨 또는 이미지 수준에서 백업하는 경우 모든 파일은 전체 백업이다. 예를 들어 VMDK 파일 형태의 가상머신을 생각해 보자. 이 가상머신이 실행 중인 상태에서 가상머신의 한 블록이 변경된다면 이미지의 수정 시간을 통해 가상머신이 변경되었음이 표시된다. 그러면 소수의 데이터 블록만 변경된 경우라 해도 후속 백업은 전체 VMDK 파일을 백업한다.
 
이 문제도 가상머신에서 변경 블록 추적(CBT)을 통해 해결됐다. CBT는 이전 백업이 생성된 시점과 이 마지막 백업 이후 변경된 블록을 추적하는 프로토콜이다. CBT를 사용해서 어떤 블록이 변경되었는지 묻고 해당 블록만 복사함으로써 이미지 수준 백업에서 블록 수준 증분 백업을 수행할 수 있다.
 
이미지 수준 백업의 마지막 단점은 항목 수준 복구 기능의 부재다. 고객은 전체 가상머신을 복원하기보다는 가상머신 내의 파일 한두 개를 복원하고자 하는 경우가 많다. 전체 가상머신을 하나의 이미지로 백업했다면 가상머신의 파일 하나를 어떻게 복원할까? 이 문제 역시 많은 백업 소프트웨어 기업에서 해결했다. 예를 들어 VM웨어 가상머신의 경우 VMDK 파일의 형식을 인식해서 여러 가지 작업을 수행할 수 있다. 원래의 VMDK 파일을 가상 볼륨으로 마운트해서 필요한 파일을 가져올 수 있는 백업 제품도 있고, 요청한 파일을 복원하기 위해 필요한 적절한 블록을 지정할 수 있는 백업 제품도 있다.
 

두 가지 장점의 혼합

즉, 현 시점의 백업 및 복구에서는 대부분의 기업이 모든 가상머신에 대해 이미지 수준 백업을 하면서 증분 백업과 항목 수준 복원을 수행할 수 있는 역량도 계속 유지하고 있다. 이 방식은 항목 수준 증분 백업보다 훨씬 더 효율적인 블록 수준 증분 백업도 지원한다.
 
또한 가상머신 수준 백업에는 가상머신을 하나의 이미지로 손쉽게 복원할 수 있는 기능도 제공된다. 흔히 말하는 베어메탈 복구가 전보다 훨씬 더 쉬워진다. 변경 블록 문제를 붙잡고 씨름할 필요 없이 베어메탈 복구의 모든 기능을 이용할 수 있다.
 
나아가 물리적 윈도우 서버의 이미지 수준 백업도 가능하다. 대부분의 사람들이 VSS를 사용해서 백업에 앞서 각 파일 시스템의 스냅샷을 생성하고 있다. 이를 통해 백업 소프트웨어 제품은 데이터 손상 위험 없이 이미지 수준에서 백업할 수 있다.
 
이제 각 접근 방법의 장단점을 알았으니 각자의 상황에 적절한 방법을 현명하게 결정할 수 있을 것이다. 가상머신을 백업할 때 대부분의 사람들은 이미지 수준 백업을 사용하며, 파일 서버를 백업할 때는 대부분 항목 수준 백업을 사용한다. 물리적 서버를 사용하는 경우 조금 더 심층적인 연구가 필요할 것이다. editor@itworld.co.kr 


2020.07.10

"같이 써야 더 강하다" 항목 수준 백업 vs. 이미지 수준 백업 비교

W. Curtis Preston | Network World
컴퓨터 백업에는 서로 정반대인 두 가지 방법이 있다. 바로 항목 수준 백업과 이미지 수준 백업이다. IT 전문가는 수십년 동안 두 가지 방법을 모두 혼합해 사용해왔다. 두 가지 모두 장단점이 있으므로 대부분의 환경에서는 둘을 혼합해 사용한다.
 
ⓒ gorodenkoff / Getty Images
 

항목 수준 백업

항목 수준 백업은 개별 항목으로 취급되는 각각의 정보 모음을 백업한다. 가장 보편적인 항목 유형은 파일이다. 과거에는 파일 수준 백업이라는 용어를 사용했다.
 
파일 외에 항목 수준 백업에 포함될 수 있는 다른 유형의 항목은 객체 스토리지 시스템의 객체다. 많은 환경에서 객체는 파일과 비슷하다. 객체 스토리지를 사용하는 대부분의 기업에서 객체는 파일과 마찬가지 역할을 한다. 다만 객체 스토리지에 저장되므로 파일은 아니다. 파일은 파일 시스템에 저장된다. 둘의 내용은 같은 경우가 많지만 서로 저장 방법이 다르다는 이유로 서로 다른 이름으로 불린다.
 
일반적으로 항목 수준 백업은 파일 서버, 윈도우나 리눅스 서버, 또는 백업 에이전트가 서버/VM 자체 내에서 실행되는 가상머신에 사용된다. 백업 에이전트는 먼저 파일 시스템(예를 들어 C:\)을 확인해서 백업할 파일을 결정한다. 전체 백업을 수행하는 중이라면 백업 에이전트는 파일 시스템의 모든 파일을 백업하고, 증분 백업 중이라면 마지막 백업 이후 변경된 파일을 백업한다.
 
또한 아마존 S3, 애저 블롭(Blob), 구글 클라우드 스토리지와 같은 객체 스토리지 시스템을 백업하는 경우에도 항목 수준 백업이 사용된다. 이러한 서비스는 일반적으로 데이터 탄력성을 위해 여러 위치로 복제되는데, 왜 굳이 백업을 해야 하는지 의문이 생길 수 있다. 객체 스토리지 내의 복제는 일반적으로 시스템 중단에 대한 내성을 갖도록 설계되지만 항상 객체 자체를 삭제하는 외부 공격까지 견디도록 설계되지는 않는다. 의도적이든, 우발적 또는 악의적인 이유로든 객체가 삭제될 경우 삭제도 모든 복사본으로 복제된다. 이와 같은 상황에 대비한 유일한 보호 방법은 객체 스토리지를 다른 계정으로 항목 수준 백업하는 것이다.
 
항목 수준 백업의 이점은 매우 쉽다는 데 있다. 적절한 곳에 백업 에이전트를 설치하면 에이전트가 파일 또는 객체 스토리지 시스템을 살펴보면서 모든 항목을 찾고 적절한 시점에 백업한다. 전체 파일 또는 객체 스토리지 시스템을 복원하려면 먼저 전체 백업을 복원한 다음 각 후속 증분 백업에서 복원을 수행해야 한다.
 

이미지 수준 백업

이미지 수준 백업은 물리적 또는 가상 디바이스를 블록 수준에서 백업하는 것이다. 그래서 보는 기준에 따라 이미지 수준 백업을 드라이브 수준, 볼륨 수준 또는 가상머신 수준 백업이라고도 한다. 디바이스는 표준 파일 시스템, 데이터베이스용 블록 스토리지, 물리적 또는 가상머신의 부팅 볼륨 등 다양한 정보 유형을 저장할 수 있다. 이미지 수준 백업 내에서는 파일 자체를 백업하는 것이 아니라 파일 시스템의 구성 블록을 백업한다.
 
가상화가 등장하기 전에는 이미지 수준 백업은 극히 드물었다. 물리적 드라이브를 백업하기가 지금보다 훨씬 더 어려웠고 블록을 백업하는 동안 파일시스템의 마운트를 해제해야 했기 때문이다. 그렇지 않을 경우 각 블록을 가져온 시점이 다른, 손상된 백업이 발생할 위험이 있었다. 윈도우 볼륨 섀도우 서비스(VSS)나 VM웨어 스냅샷에 사용되는 것과 같은 가상 스냅샷 기술은 이 근본적인 문제를 해결했다.
 
가상머신이 등장한 이후 볼륨 수준 백업의 인기가 훨씬 더 높아졌다. 이미지 수준 백업으로 하이퍼바이저 수준에서 가상머신 백업을 수행할 수 있다. 백업 소프트웨어는 가상머신 외부에서 실행되며, 이 소프트웨어 관점에서 가상머신은 하나 또는 여러 개의 이미지다(예를 들어 VM웨어의 VMDK 파일).
 
이미지 수준 백업에는 다양한 이점이 있다. 첫째, 백업이 더 빠르고 복원은 훨씬 더 빠르다. 이미지 수준 백업은 파일 또는 객체 스토리지 시스템의 오버헤드를 건너뛰고 바로 기반 스토리지를 다룬다. 파일 수준 백업의 경우 각 파일을 개별적으로 복원해야 하고 이를 위해서는 파일 시스템에 파일을 만들어야 하는데, 상당한 오버헤드가 수반되는 프로세스다. 특히 수많은 파일이 포함된 매우 밀집한 파일 시스템을 복원하는 경우 데이터를 파일로 전송하는 프로세스보다 복원 중에 파일을 생성하는 프로세스에 더 오랜 시간이 걸리면서 이 문제가 두드러지게 나타난다. 이미지 수준 복원은 블록 수준에 바로 데이터를 두기 때문에 이 문제가 없다.
 
스냅샷으로 블록 변경 문제는 해결됐지만 이미지 수준 백업에는 그 다음으로 큰 문제가 있었다. 바로 증분 백업이다. 드라이브, 볼륨 또는 이미지 수준에서 백업하는 경우 모든 파일은 전체 백업이다. 예를 들어 VMDK 파일 형태의 가상머신을 생각해 보자. 이 가상머신이 실행 중인 상태에서 가상머신의 한 블록이 변경된다면 이미지의 수정 시간을 통해 가상머신이 변경되었음이 표시된다. 그러면 소수의 데이터 블록만 변경된 경우라 해도 후속 백업은 전체 VMDK 파일을 백업한다.
 
이 문제도 가상머신에서 변경 블록 추적(CBT)을 통해 해결됐다. CBT는 이전 백업이 생성된 시점과 이 마지막 백업 이후 변경된 블록을 추적하는 프로토콜이다. CBT를 사용해서 어떤 블록이 변경되었는지 묻고 해당 블록만 복사함으로써 이미지 수준 백업에서 블록 수준 증분 백업을 수행할 수 있다.
 
이미지 수준 백업의 마지막 단점은 항목 수준 복구 기능의 부재다. 고객은 전체 가상머신을 복원하기보다는 가상머신 내의 파일 한두 개를 복원하고자 하는 경우가 많다. 전체 가상머신을 하나의 이미지로 백업했다면 가상머신의 파일 하나를 어떻게 복원할까? 이 문제 역시 많은 백업 소프트웨어 기업에서 해결했다. 예를 들어 VM웨어 가상머신의 경우 VMDK 파일의 형식을 인식해서 여러 가지 작업을 수행할 수 있다. 원래의 VMDK 파일을 가상 볼륨으로 마운트해서 필요한 파일을 가져올 수 있는 백업 제품도 있고, 요청한 파일을 복원하기 위해 필요한 적절한 블록을 지정할 수 있는 백업 제품도 있다.
 

두 가지 장점의 혼합

즉, 현 시점의 백업 및 복구에서는 대부분의 기업이 모든 가상머신에 대해 이미지 수준 백업을 하면서 증분 백업과 항목 수준 복원을 수행할 수 있는 역량도 계속 유지하고 있다. 이 방식은 항목 수준 증분 백업보다 훨씬 더 효율적인 블록 수준 증분 백업도 지원한다.
 
또한 가상머신 수준 백업에는 가상머신을 하나의 이미지로 손쉽게 복원할 수 있는 기능도 제공된다. 흔히 말하는 베어메탈 복구가 전보다 훨씬 더 쉬워진다. 변경 블록 문제를 붙잡고 씨름할 필요 없이 베어메탈 복구의 모든 기능을 이용할 수 있다.
 
나아가 물리적 윈도우 서버의 이미지 수준 백업도 가능하다. 대부분의 사람들이 VSS를 사용해서 백업에 앞서 각 파일 시스템의 스냅샷을 생성하고 있다. 이를 통해 백업 소프트웨어 제품은 데이터 손상 위험 없이 이미지 수준에서 백업할 수 있다.
 
이제 각 접근 방법의 장단점을 알았으니 각자의 상황에 적절한 방법을 현명하게 결정할 수 있을 것이다. 가상머신을 백업할 때 대부분의 사람들은 이미지 수준 백업을 사용하며, 파일 서버를 백업할 때는 대부분 항목 수준 백업을 사용한다. 물리적 서버를 사용하는 경우 조금 더 심층적인 연구가 필요할 것이다. editor@itworld.co.kr 


X