2018.09.06

올바른 백업 수준으로 시간과 대역폭, 공간 절약하기

W. Curtis Preston | Network World
백업과 복구를 효과적으로 수행하기 위해서는 여러 백업 수준을 신중하게 선택해 사용해야 한다. 만약 증분 백업과 차분 백업이 적절하게 이루어진다면, 전체 백업을 자주 할 필요는 없다.

백업과 복구에서 가장 기본적인 것 중 하나가 백업 수준의 개념과 의미를 이해하는 것이다. 백업 수준에 대한 적절한 이해가 없으면, 기업은 대역폭과 스토리지를 낭비하고 실제로 백업 상의 중요 데이터를 잃어버릴 수도 있는 나쁜 관행을 도입할 수 있다. 이 개념을 이해하는 것은 새로운 데이터 보호 제품이나 서비스를 선택할 때도 결정적인 역할을 한다.

Image Credit : GettyImagesBank

전체 백업(Full Backup)
전체 백업은 전체 시스템의 모든 데이터를 담고 있다. 윈도우 환경에서 C 드라이브의 전체 백업이라고 하면, C 드라이브의 모든 파일을 담는다. 윈도우 시스템의 전체 백업은 시스템이나 가상머신의 모든 드라이브에 있는 모든 파일의 사본을 담는다. 유닉스나 리눅스 시스템의 전체 백업도 마찬가지다. 시스템 상의 모든 파일 시스템의 모든 파일을 담는다.

전체 백업에서 제외되어야 하는 단 한 가지는 환경 설정에 의해 특별히 배제하도록 한 파일뿐이다. 예를 들어, 많은 시스템 관리자가 복구할 때 아무런 가치가 없는 디렉토리(/boot나 /dev 등)나 임시 파일을 담고 있는 디렉토리(/tmp 등)를 제외하도록 선택한다.

백업에 어떤 파일을 포함시키고 어떤 파일을 제외할 것인가를 논할 때 두 가지 철학이 있다. 하나는 필요없다는 것이 확실한 것만 빼고 모두 백업하는 것이고, 다른 하나는 백업하고 싶은 것만 선택하는 것이다. 전자는 안전한 선택이고, 후자는 백업 시스템의 공간을 절약할 수 있다. 일각에서는 오라클이나 SQL 서버를 로딩한 디렉토리 같은 애플리케이션 파일을 백업하는 것은 낭비라고 생각한다. 이들은 복구 과정에서 간단하게 애플리케이션을 다시 로딩할 수 있다고 믿는다. 이 접근법의 위험 요소는 누군가 중요한 데이터를 선택받지 못한 디렉토리에 둔 경우이다. 예를 들어, /home1이나 D:\Data 디렉토리를 백업하도록 선택하면, 누군가 /home2나 E:\Data를 추가한 것을 백업 시스템이 알 수는 없다. 공간이 좀 더 들더라도 필요없는 것이 확실한 파일을 제외하고는 모두 백업하는 것이 안전한 이유이다. 물론 예외도 있다. 만약 모든 데이터가 항상 일정한 곳에 놓여 있고 복구할 때 운영체제와 애플리케이션을 대체할 수 있는 잘 조화된 솔루션이 있는 엄격하게 통제되는 환경이라면 후자를 선택해도 좋을 것이다.

증분 백업
증분 백업은 보통 마지막 백업 이후 변경된 모든 데이터를 백업한다. 이런 백업은 대부분 파일 기반의 백업으로, 마지막 백업 후 변경된 모든 파일을 백업한다. 현대적인 데이터 보호 관점에서 이 방식의 과제는 백업이 서버에 미치는 I/O 영향을 최소화해야 한다는 것이다. 특히 가상머신 백업에서 이 문제가 두드러지는데, 1MB의 변경 때문에 10GB 파일을 백업하는 것은 아주 효율적이지 않다.

많은 백업 솔루션 업체가 블록 기반의 증분 백업으로 전환하는 이유도 이 때문이다. 변경된 블록만 백업하면 된다. 이 작업을 하는 가장 일반적인 방법은 백업 소프트웨어가 자체 API로 VM웨어나 하이퍼-V를 백업하는 것이다.

차등 백업
차등 백업은 그동안 여러 가지 의미로 사용됐지만, 현재는 마지막 전체 백업 이후 변경된 모든 데이터를 백업하는 것으로 이해되고 있다. 이 방식은 테이프 백업 시절에 널리 유행됐는데, 복구할 때 필요한 테이프의 수를 최소화할 수 있기 때문이다. 복구에는 최신 전체 백업과 최신 차등 백업, 그리고 최신 증분 백업이 필요하다.

만약 아직도 테이프 백업을 하고 있다면, 주간 전체 백업을 월간 전체 백업과 주간 차등 백업, 일간 증분 백업으로 바꾸는 것을 고려해 보기 바란다. 기존 주간 전체 백업 구성보다 복구에 백업본이 하나 더 필요하지만, 테이프의 양과 네트워크 대역폭을 극적으로 줄여준다. 테이프 백업 환경에서는 한동안 상당한 인기를 누린 구성이다.

영구 증분 백업
디스크 백업의 발전과 중복 제거 기술의 등장으로 전체 백업과 차등 백업은 구시대 유물이 됐다. 앞서 언급한 것처럼 전체 백업과 차등 백업의 회수를 줄이는 것은 복구에 필요한 테이프의 수를 최소화하기 위한 것이다. 하지만 이는 디스크 백업 세계에는 더는 적용되지 않는다. 제품이 디스크를 온전하게 활용하는 아키텍처라면, 수천의 증분 백업에서 데이터를 복구하는 데 하나의 전체 백업을 복구하는 것보다 오래 걸리지 않는다. 이는 백업 시스템이 모든 파일과 블록이 스토리지 내에 어디에 있는지 기록을 가지고 있다가 이들 파일과 블록 데이터를 스토리지에서 클라이언트로 전송해주기 때문이다. 이들 파일과 블록이 어떻게 그 자리에 있는지는 현대 백업에서는 중요하지 않다. 특히 블록 기반 접근 방식을 사용하는 백업 시스템은 영구 증분 백업이 백업 저장소를 각 백업 클라이언트의 최신 정보로 업데이트하는 가장 효율적인 방법이다.

아카이브 비트(Archive bit)
윈도우 시스템은 아카이브 비트란 파일 속성을 사용해 마지막 백업 이후 변경된 파일을 판단한다. 파일이 어떤 수정이라도 있으며, 아카이브 비트가 설정되고, 이후 어떤 수준의 백업이라도 이 파일을 백업한다. 파일이 백업된 후에는 백업 애플리케이션이 아카이브 비트를 지워 다음 전체 백업까지는 백업되지 않도록 한다.

많은 백업 순혈주의자가 아카이브 비트를 좋아하지 않는데, 당연히 백업 비트라고 불러야 한다는 이유 때문이다. 백업과 아카이브는 완전히 다른 것이다. 이외에 아카이브 비트는 두 가지 백업 애플리케이션을 동시에 구동하면 아카이브 비트를 지우는 것 때문에 서로 겹친다는 문제가 있다.

하지만 최근 대부분 기업이 가상화를 도입하고, 가상화 수준에 연결하는 백업 API를 사용하고, 블록 기반 증분 백업을 사용하면서 아카이브 비트는 이제 호스트 기반 백업에만 적용된다. 사실 이 방식은 날이 갈수록 드물어지고 있다.

*W. Curtis Preston은 25년 경력의 백업 및 스토리지, 복구 전문가로, 최근 클라우드 기반 데이터 보호 전문업체인 드루바(Druva)에 합류했다.  editor@itworld.co.kr


2018.09.06

올바른 백업 수준으로 시간과 대역폭, 공간 절약하기

W. Curtis Preston | Network World
백업과 복구를 효과적으로 수행하기 위해서는 여러 백업 수준을 신중하게 선택해 사용해야 한다. 만약 증분 백업과 차분 백업이 적절하게 이루어진다면, 전체 백업을 자주 할 필요는 없다.

백업과 복구에서 가장 기본적인 것 중 하나가 백업 수준의 개념과 의미를 이해하는 것이다. 백업 수준에 대한 적절한 이해가 없으면, 기업은 대역폭과 스토리지를 낭비하고 실제로 백업 상의 중요 데이터를 잃어버릴 수도 있는 나쁜 관행을 도입할 수 있다. 이 개념을 이해하는 것은 새로운 데이터 보호 제품이나 서비스를 선택할 때도 결정적인 역할을 한다.

Image Credit : GettyImagesBank

전체 백업(Full Backup)
전체 백업은 전체 시스템의 모든 데이터를 담고 있다. 윈도우 환경에서 C 드라이브의 전체 백업이라고 하면, C 드라이브의 모든 파일을 담는다. 윈도우 시스템의 전체 백업은 시스템이나 가상머신의 모든 드라이브에 있는 모든 파일의 사본을 담는다. 유닉스나 리눅스 시스템의 전체 백업도 마찬가지다. 시스템 상의 모든 파일 시스템의 모든 파일을 담는다.

전체 백업에서 제외되어야 하는 단 한 가지는 환경 설정에 의해 특별히 배제하도록 한 파일뿐이다. 예를 들어, 많은 시스템 관리자가 복구할 때 아무런 가치가 없는 디렉토리(/boot나 /dev 등)나 임시 파일을 담고 있는 디렉토리(/tmp 등)를 제외하도록 선택한다.

백업에 어떤 파일을 포함시키고 어떤 파일을 제외할 것인가를 논할 때 두 가지 철학이 있다. 하나는 필요없다는 것이 확실한 것만 빼고 모두 백업하는 것이고, 다른 하나는 백업하고 싶은 것만 선택하는 것이다. 전자는 안전한 선택이고, 후자는 백업 시스템의 공간을 절약할 수 있다. 일각에서는 오라클이나 SQL 서버를 로딩한 디렉토리 같은 애플리케이션 파일을 백업하는 것은 낭비라고 생각한다. 이들은 복구 과정에서 간단하게 애플리케이션을 다시 로딩할 수 있다고 믿는다. 이 접근법의 위험 요소는 누군가 중요한 데이터를 선택받지 못한 디렉토리에 둔 경우이다. 예를 들어, /home1이나 D:\Data 디렉토리를 백업하도록 선택하면, 누군가 /home2나 E:\Data를 추가한 것을 백업 시스템이 알 수는 없다. 공간이 좀 더 들더라도 필요없는 것이 확실한 파일을 제외하고는 모두 백업하는 것이 안전한 이유이다. 물론 예외도 있다. 만약 모든 데이터가 항상 일정한 곳에 놓여 있고 복구할 때 운영체제와 애플리케이션을 대체할 수 있는 잘 조화된 솔루션이 있는 엄격하게 통제되는 환경이라면 후자를 선택해도 좋을 것이다.

증분 백업
증분 백업은 보통 마지막 백업 이후 변경된 모든 데이터를 백업한다. 이런 백업은 대부분 파일 기반의 백업으로, 마지막 백업 후 변경된 모든 파일을 백업한다. 현대적인 데이터 보호 관점에서 이 방식의 과제는 백업이 서버에 미치는 I/O 영향을 최소화해야 한다는 것이다. 특히 가상머신 백업에서 이 문제가 두드러지는데, 1MB의 변경 때문에 10GB 파일을 백업하는 것은 아주 효율적이지 않다.

많은 백업 솔루션 업체가 블록 기반의 증분 백업으로 전환하는 이유도 이 때문이다. 변경된 블록만 백업하면 된다. 이 작업을 하는 가장 일반적인 방법은 백업 소프트웨어가 자체 API로 VM웨어나 하이퍼-V를 백업하는 것이다.

차등 백업
차등 백업은 그동안 여러 가지 의미로 사용됐지만, 현재는 마지막 전체 백업 이후 변경된 모든 데이터를 백업하는 것으로 이해되고 있다. 이 방식은 테이프 백업 시절에 널리 유행됐는데, 복구할 때 필요한 테이프의 수를 최소화할 수 있기 때문이다. 복구에는 최신 전체 백업과 최신 차등 백업, 그리고 최신 증분 백업이 필요하다.

만약 아직도 테이프 백업을 하고 있다면, 주간 전체 백업을 월간 전체 백업과 주간 차등 백업, 일간 증분 백업으로 바꾸는 것을 고려해 보기 바란다. 기존 주간 전체 백업 구성보다 복구에 백업본이 하나 더 필요하지만, 테이프의 양과 네트워크 대역폭을 극적으로 줄여준다. 테이프 백업 환경에서는 한동안 상당한 인기를 누린 구성이다.

영구 증분 백업
디스크 백업의 발전과 중복 제거 기술의 등장으로 전체 백업과 차등 백업은 구시대 유물이 됐다. 앞서 언급한 것처럼 전체 백업과 차등 백업의 회수를 줄이는 것은 복구에 필요한 테이프의 수를 최소화하기 위한 것이다. 하지만 이는 디스크 백업 세계에는 더는 적용되지 않는다. 제품이 디스크를 온전하게 활용하는 아키텍처라면, 수천의 증분 백업에서 데이터를 복구하는 데 하나의 전체 백업을 복구하는 것보다 오래 걸리지 않는다. 이는 백업 시스템이 모든 파일과 블록이 스토리지 내에 어디에 있는지 기록을 가지고 있다가 이들 파일과 블록 데이터를 스토리지에서 클라이언트로 전송해주기 때문이다. 이들 파일과 블록이 어떻게 그 자리에 있는지는 현대 백업에서는 중요하지 않다. 특히 블록 기반 접근 방식을 사용하는 백업 시스템은 영구 증분 백업이 백업 저장소를 각 백업 클라이언트의 최신 정보로 업데이트하는 가장 효율적인 방법이다.

아카이브 비트(Archive bit)
윈도우 시스템은 아카이브 비트란 파일 속성을 사용해 마지막 백업 이후 변경된 파일을 판단한다. 파일이 어떤 수정이라도 있으며, 아카이브 비트가 설정되고, 이후 어떤 수준의 백업이라도 이 파일을 백업한다. 파일이 백업된 후에는 백업 애플리케이션이 아카이브 비트를 지워 다음 전체 백업까지는 백업되지 않도록 한다.

많은 백업 순혈주의자가 아카이브 비트를 좋아하지 않는데, 당연히 백업 비트라고 불러야 한다는 이유 때문이다. 백업과 아카이브는 완전히 다른 것이다. 이외에 아카이브 비트는 두 가지 백업 애플리케이션을 동시에 구동하면 아카이브 비트를 지우는 것 때문에 서로 겹친다는 문제가 있다.

하지만 최근 대부분 기업이 가상화를 도입하고, 가상화 수준에 연결하는 백업 API를 사용하고, 블록 기반 증분 백업을 사용하면서 아카이브 비트는 이제 호스트 기반 백업에만 적용된다. 사실 이 방식은 날이 갈수록 드물어지고 있다.

*W. Curtis Preston은 25년 경력의 백업 및 스토리지, 복구 전문가로, 최근 클라우드 기반 데이터 보호 전문업체인 드루바(Druva)에 합류했다.  editor@itworld.co.kr


X