검수요청.png검수요청.png

"지속적 데이터 보호"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
(같이 보기)
 
(사용자 3명의 중간 판 22개는 보이지 않습니다)
1번째 줄: 1번째 줄:
'''지속적 데이터 보호''' 란
+
'''지속적 데이터 보호'''(CDP)Continuous Data Protection의 약자로서 데이터(사진, 문서파일 등) 변화 시 즉각적으로 서버에 백업을 하는 것을 의미한다. '''연속백업'''이라고도 한다. 영어 약자로 '''CDP'''(씨디피)라고 한다.
  
 
== 개요 ==
 
== 개요 ==
== 등장배경/역사 ==
+
지속적 데이터 보호는 데이터의 모든 변경 사항을 [[스토리지]] 또는 [[서버]] 에 저장한다. [[블록]] 단위로 데이터를 저장하기 때문에 외부의 [[버퍼 오버플로우]] 공격이나 자연재해로 인한 데이터 손실 시 원하는 날짜 시간 심지어는 분 단위까지 파악하여 [[백업]]을 할 수 있다. 컴퓨터의 백업은 IT 사회에서 매우 흥미로운 혁신 중 하나였다. 복제 기술은 자료를 보호하는데 훌륭한 기술이 되어왔다. 기존의 백업 방식은 일정한 시간이나 날짜를 주기로 데이터가 백업 된다. 기존의 방식은 디스크 기반 라이브러리(VTL), 그리고 소프트웨어가 자동으로 백업하는 방식이었다. 예를 들어 1주일 단위로 데이터를 백업하는 회사가 있다고 가정을 한다. 디스크 손상이나 [[해커]]의 공격으로 컴퓨터의 데이터가 손실되면 1주일 단위로 지정된 데이터를 서버에서 백업할 수있다. 하지만 중요한 데이터를 하루나 이틀 전에 수정했다고 가정해보자. 서버에 백업이 되지 않음으로 작업한 데이터는 전혀 복구할 수 없고 특정한 복구 시점이나 시간으로 복구가 불가능하다. 이렇든 중요한 데이터나 혹은 공공기관, 은행 등의 데이터들은 바로바로 백업되어야 하는데 너무 오랜 시간 텀을 두게 되면 문제가 발생한다. 이는 컴퓨터도 마찬가지이다. 수많은 고객의 정보를 담고 있기 때문에 백업하는데도 오래 걸리고 변경 사항이 자주 발생한다. 보통 백업은 주말이나 저녁에 많이 이루어진다. 그래야만 네트워크나 서버에 걸리는 과부화와 자원 낭비를 막을 수 있다. 하지만 실제로 에러 발생 시 데이터를 복구하는 데는 꽤 오랜 시간이 소요되고 만만치 않다. 이렇듯 기존의 백업방식은 상당히 긴 시간이 필요하고 비용 또한 높으며 데이터 보호에 관한 관심이 높아지면서 [[클라우드]], [[스토리지]] 등 여러 저장 서버들이 시중에 나오게 되었고 백업 데이터의 효율을 위해 중복 데이터는 제거하고 보다 효율적인 데이터 활용과 디스크 사용을 목적으로 데이터를 백업하는 지속적 데이터 보호가 탄생하게 되었다. 즉 기존의 특정 시간으로 돌아가는 스냅샷 방법보다 더 우수하다.
 +
 
 
== 특징 ==
 
== 특징 ==
===종류 ===
+
지속적 데이터 보호는 네트워크의 부하가 기존의 백업보다 낮으며 서버에 중복파일이 있다면 이를 제외하여 용량을 줄여 시스템 서버 성능 유지가 가능하다. 또한 로컬, 네트워크 폴더 외에도 클라우드, 소프트웨어, 운영체제까지도 저장 할 수 있고, 어느 시간이라도 복구 할 수 있다. 디렉터리의 모든 변화를 잡아내는 동시에 저장하는 형태로, 강력한 스토리지 기술인 클라우디안(Cloudian)을 필요로 한다. 그리고 서버의 성능에 영향을 미치지 않으며 디스크 용량을 절약한다. 이러한 장점을 가지고 있는 지속적 데이터 보호는 몇몇 문제점을 내포하고 있다. 먼저, 서버에 데이터를 올리는 유일한 방법으로 외부공격에 취약할 수 있다. 따라서 연속적인 데이터 보호를 위해 뛰어난 디스크 드라이브가 필요하다. 또한 데이터 자원에 대한 처리량이 증가함으로 중요하게 보호할 자원에 문제가 발생할 수 있다.
=== 구성 ===
+
 
=== 구조 ===  
+
===기능===
=== 활용 ===  
+
지속적 데이터 보호는 어느 기업이나 개인 사용자로부터 발생하는 모든 데이터의 편집기록을 백업하기 때문에 시스템이 악성코드에 의해 해킹을 당하여도 원하는 시간대
===문제점===
+
가장 최신의 파일 데이터를 복구할 수 있다. 디렉터리 파일을 복제하고 후속 파일은 복제 원본 파일에 블록 단위로 데이터를 저장하기 때문에 오베헤더가 없고 폴더와 파일을 마지막으로 수정한 부분까지 복구가 가능하다. 기존의 백업 방식인 테이프 방식이나 아카이브보다 훨씬 더 빠르게 데이터 복구를 제동하며 기존의 있던 데이터와 충돌하지 않는다. 기존의 백업의 프로세스 낭비까지 보안을 유지하였다. 백업을 하려면 먼저 데이터를 확인해야 하고 실행 중인 프로세스를 확인해야 한다. 주로 밤이나 주말에 함으로 백업되는 데이터의 양이 제한적이고 프로세스가 실행 되는 동안 해당 프로그램은 사용하지 못한다. 지속적 데이터 보호는 프로세스를 따로 컨트롤하지 않고 백업이 가능하다. 지속적 데이터 보호 작동 방식은 현재 윈도우 7이상, 윈도우서버 2008 R2 이상에서 제공된다.<ref name="출처">N3NCLOUDE,〈[https://support.n3ncloud.co.kr/hc/ko/articles/360050613874-%EC%A7%80%EC%86%8D%EC%A0%81%EC%9D%B8-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%B3%B4%ED%98%B8-CDP-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94- 지속적인 데이터 보호(CDP)란 무엇인가요?]〉, 《아크로니스》, 2020-07-06</ref> 데이터가 실제 변경될시 즉작적으로 백업을 하는 경우도 있고 정기적인 백업이지만 예약시간을 매우 자주 실행하여 지속적인 데이터 보호 효과를 수행 할 수 있다.
==현황, 전망==
+
 
 +
[[파일:CDP 동작방식.png|썸네일|500 픽셀|지속적 데이터 보호]]
 +
[[파일:CDP.png|썸네일|500픽셀|작동원리]]
 +
 
 +
옆의 그림을 예시로 든다면 1시간을 주기로 데이터 백업을 진행하고 있다. 예상치 못한 오류나 악성 해커의 공격으로 데이터가 손실되면 해킹 받기 전 이전 시간으로 되돌릴 수 있다. 기존백업보다 훨씬 시간이 짧은 것을 알 수 있다. 그림에서는 1시간이지만 실제로는 분 단위로 백업을 올릴 수 있어서 해커의 공격에도 안전하게 데이터를 복구할 수 있다. 신속하고 정확한 복원 시간과 데이터 패킷의 어느 한 부분을 선택하여 제공함에 따라 사용자가 의도한 시점으로의 데이터 접근이 가능하고 백업이 아닌 복구에 초점이 맞추어져 있는 것이 기존 데이터 백업 방법과 가장 큰 차이점이다. 백업 방식에는 네트워크 백업 클라우드와 스토리지를 이용한 백업 SAN 백업 등 다양한 방식이 존재한다. 지속적 데이터 보호가 과거의 것을 대체하기 위해 나온 것은 사실이지만 모든 백업 업무를 처리하는 데는 많은 무리가 발생할 것이다. 지속적 데이터 보호는 깨끗한 이미지 데이터를 가지고 있어 에러가 발생하더라도 데이터 서비스를 지속해서 할 수 있어 결과적으로 비즈니스의 연결성을 제공하기 때문에 백업 기능 보안을 유지하는 그 이상의 의미를 충분히 가지게 된다.<ref>IB인포텍 , 〈[https://bns.ibinfo.co.kr/6 CDP(Continuous Data Protection) 백업 솔루션에 대해...]〉, 《아이비인포텍㈜》, 2008-01-03</ref>
 +
 
 +
=== 작동원리 ===
 +
* 지속적 데이터 보호 백업을 위해 지속해서 생성한 백업파일을 호출한다. 데이터 보호의 백업이 생성될 전체 백업 또는 증분 백업 예비 만들 수 있다.
 +
* 백업 모듈 및 연속 데이터 보호가 활성화 된 상태에서 보호 계획을 처음 실행하면 전체 백업이 먼저 생성된다. 그 후에는 컨택되거나 변경된 파일/폴더에 대한 지속적 데이터 보호 백업파일이 생성된다. 백업은 항상 최신 상태로 사용자에 의해 선택된 데이터를 포함한다.
 +
* 선택한 파일/폴더를 변경하면  지속적 데이터 보호 백업이 생성되지 않으며 모든 변경 사항이 동일한 지속적 데이터 보호 백업에 기록된다.
 +
* 예약된 증분 백업 시간이 되면 백업이 삭제되고 증분 백업이 완료된 후 새 백업이 생성된다.
 +
* C백업은 항상 보호된 파일/폴더의 최신 실제 상태를 갖는 백업 체인에서 최신 백업으로 유지된다. 백업 모듈을 활성화하고 활성화하기로 결정으로 이미 보호 계획이있는 경우 지속적인 데이터 보호는 다음 백업은 이미 전체 백업을 가지고 바로 백업 체인으로 옵션을 사용하도록 설정한 후에 작성된다.<ref name="출처"></ref> 옆의 그림에서도 자세히 볼 수 있다. 지속적 데이터 보호는 블록 기반으로 구성된 파일을 복제하고 저장하기 때문에 블록하나하나에 수정사항이 구분되어 있으며 파일변경 시에만 새로운 블록을 추가하면 된다. 원래의 정보를 가지고 있는 파일을 새로 올리므로 기존의 파일은 삭제해도 무방하며 PC는 자신이 가지고 있는 파일을 올리면 블록이 추가되어 저장되는 형태이다.
 +
 
 +
=== 유형 ===
 +
====블록 기반====
 +
응용 프로그램은 지속적 데이터 보호가 돌고 있는지도 모른다. 대다수 블록 기반 해법은(SAN 구조) 내장된 형태를 따르므로 서버나 스토리지 유형에 무관하게 동작한다. 아주 단순하게, 블록 기반 지속적 데이터 보호는 스토리지 네트워크를 건너 일어나는 모든 블록 쓰기를 감시해서, 논리적으로 시간 순서에 따른 쓰기 [[캐시]]를 유지하는 방법을 사용한다. 몇몇 해법은 이런 캐시 관리에서 아주 복잡한 방법을 따른다. 이렇게 하는 이유는 아주 값비싼 방법으로 트랜잭션을 재조합하는 방법과 비교해서) 캐시에 들어 있는 disk/LUN의 뷰를 즉각 보여주는 기능을 제공하기 위해서다. 블록 기반 해법은 투명하게 자료를 수집하는 과정에서 뛰어난 장점을 발휘하며, 과거 특정 시점의 뷰를 반영한다. 하지만 종종 역사적인 뷰를 활용하기 위해 추가 작업이 필요한 경우도 있다. 예를 들어, 지속해서 I/O를 스토리지에 스트리밍하는 데이터베이스 응용 프로그램을 상상해보자. 데이터베이스 동기화나 정지 시점과 일치하지 않는 특정 시점으로 뷰를 되돌리려면, 아마도 데이터베이스는 이 뷰를 기준으로 독자적인 비정상 종료 복구를 수행해야 할 것이다. 종종 블록 기반 해법은 디바이스가 복원점을 구분하기 위해 응용 프로그램 쪽에서 정지 시점과 일치하는 특정 "시각"을 태그로 기록해 놓는 태깅 연산을 지원한다. 이런 불연속적 사이에서도 지속적 데이터 보호 해법이 유용한 뷰를 제공해주긴 하지만 몇몇 응용 프로그램 재동기화라는 비용을 치뤄야 한다. 정말로 임의 시점으로 가고 싶다면 재동기화 비용은 엄청나게 높아진다. 그러므로 블록 기반 해법의 매력은 응용 프로그램 투명성이 아주 높고, 응용 프로그램 성능에 영향을 미치지 않으며, 일반적으로 하드웨어와 플랫폼 특성을 타지 않는다는 것이다.<ref name="홈피">Chris Stakutis,〈[https://kdata.or.kr/info/info_04_view.html?field=&keyword=&type=techreport&page=210&dbnum=127735&mode=detail&type=techreport CDP란 무엇이며, 어디에 가장 적합한 기술인가]〉, 《한국데이터산업진흥원》, 2008-09-24</ref>
 +
 +
====응용 프로그램 기반====
 +
스펙트럼의 반대쪽 끝에는 응용 프로그램 기반 지속적 데이터 보호가 놓여있다. 즉, 특정 응용 프로그램 DB2나 기타 몇몇 데이터베이스 또는 비슷한 응용 프로그램이 특정 시점으로 돌리기 위해 필요한 모든 저널링 정보를 처리할 책임을 전적으로 진다. 응용 프로그램에 밀접하게 통합되어 있다는 사실은 복구 능력에 훨씬 더 풍부한 기능을 제공하는 해법임을 의미한다. 예를 들어, 데이터베이스는 세 시간 전에 나타났던 테이블의 열이나 행을 복구하고, 동작 중인 응용 프로그램을 방해하지 않은 채로 살아있는 시스템에서 이런 복구 작업을 진행할 수 있을지도 모른다. 반면 블록 기반 해법은 테이블 열과 행을 보지 못하며, 가공되지 않은 블록만 볼 뿐이다. 블록 기반 해법은 전체 디스크에 대한 뷰만 제공하며, 데이터베이스와 같은 응용 프로그램은 실제 사용을 위해서는 이런 뷰를 물리적으로 마운트해야만 한다. 응용 프로그램 기반 해법의 매력은 강력한 복구 능력을 위해 응용 프로그램과 밀접하게 통합되어야 한다는 것이다. 반면 단점은 응용 프로그램과 협력해야만 제대로 동작하며, 응용 프로그램 서버에 부하를 주고 자원을 소비한다는 것이다.<ref name="홈피"></ref>
  
 +
====파일 기반====
 +
파일 기반 지속적 데이터 보호 해법은 파일 서버나 워크스테이션과 같은 응용 프로그램 호스트에서 동작하며 응용 프로그램 기반 기술과 상당히 비슷하다. 하지만 좀 더 범위가 넓은 이유는 여러 응용 프로그램과 사용자가 자연스럽게 파일 기반으로 구성된 자료를 사용하기 때문이다. 블록 기반 해법에서는 LUN/disk 단위로만 정책 설정이 가능했지만, 파일 기반 기술은 파일이나 파일 그룹 단위로 다양한 규약을 설정 할 수 있다. 특정 기계에 들어 있는 파일 집합은 단순한 형식으로 보호를 받을 필요가 없을지도 모르며, 어떤 파일 집합은 저장 시점을 오랫동안 유지할 필요가 있을지도 모른다. 또한 파일 기반 지속적 데이터 보호 해법은 부하가 중간 정도로 그치는데, 파일이 디스크에 자연스럽게 저장될 때, 이미 여러 캐시에 저장된 자료로 아주 쉽게 복사본을 만들 수 있기 때문이다. 복구 역시 파일 기반 지속적 데이터 보호 해법에서 좀 더 부드럽게 진행된다. 과거 특정 시각에서 전체 볼륨 뷰를 마운트하거나 제공할 필요가 없다. 그 대신 각 파일에 대한 개별 저장 인스턴스를 찾아서 필요한 버전을 찾아볼 수 있다. 아니면 파일이나 디렉터리 집합 복구를 원하는 특정 시각을 요청할 수도 있다.<ref name="홈피"></ref>
  
 +
== 활용 ==
 +
파일 유형 지속적 데이터 보호는 최종 사용자와 파일 서버에 가장 적합하다. 그 이유는 보호받을 자산 즉, 파일이 더 나은 조밀도와 복구 용이성을 제공하는 지속적 데이터 보호유형과 딱 맞아떨어지기 때문이다. 파일 해법 기반의 매력은 다음과 같다. 경량이며, 파일 기반 정책, 조밀도, 좀 더 자연스러운 복구 시나리오를 제공하며 응용 프로그램/사용자가 올바른 유형을 선택한다. 매일매일 데이터 정보를 저장하고 보호하는 웹사이트나 은행, 고객의 정보를 가지고 있는 게임회사 등에서 많이 사용된다. 백업 기능 외에도 사실 복구기반에 많은 중점을 두기도 한다. 과거에는 백업만 보았다면 오류 발생 후 데이터를 다시 복구하는 것이 중요함으로 데이터 복구 시에 강력한 효과를 발휘한다. 문서 생성과 편집 등 일반적인 사무실 직원이 사용하거나 자동화된 비즈니스 응용 프로그램 XML 패키지를 사용한다면 파일 기반 해법이 제격이다. 워크스테이션과 랩톱 같은 최종 사용자용 시스템을 보호하는 데 관심이 많다면 딱 맞는 해법이다. 컴퓨터가 대부분 여러 응용 프로그램 서비스를 제공한다면 DB2나 오라클이나 전자편지 서버는 블록 기반 해법이 수용될 것이다. 응용 프로그램이 독자적인 응용 프로그램 기반 지속적 데이터 보호 기능을 내장하고 있다면, 이런 기능을 사용할 때에는 발생하는 부하가 견딜만한지 고려해야 한다.
 +
:{|class=wikitable width=600
 +
|+기존방식과 비교
 +
!align=center|항목/구분
 +
!align=center|수동백업
 +
!align=center|이미지 백업
 +
!align=center|지속적 데이터 백업
 +
|-
 +
|align=center|백업을 위한 통합 콘솔 제공
 +
|align=center|X
 +
|align=center|O
 +
|align=center|O
 +
|-
 +
|align=center|스케쥴 백업 지원
 +
|align=center|X
 +
|align=center|O
 +
|align=center|O
 +
|-
 +
|align=center|중분 백업 지원
 +
|align=center|X
 +
|align=center|O
 +
|align=center|O
 +
|-
 +
|align=center|백업 작업 시 디스크 부하 여부
 +
|align=center|심함
 +
|align=center|심함
 +
|align=center|거의 없음
 +
|-
 +
|align=center|백업 시점 및 복원 시점 자동 관리
 +
|align=center|불가능
 +
|align=center|불가능
 +
|align=center|가능
 +
|-
 +
|align=center|네트워크 백업 전문성
 +
|align=center|X
 +
|align=center|X
 +
|align=center|O
 +
|-
 +
|align=center|OS 백업 및 복구
 +
|align=center|어려움
 +
|align=center|어려움
 +
|align=center|매우 간단함
 +
|-
 +
|align=center|백업 주기 관리 일
 +
|align=center|일
 +
|align=center|일, 시간
 +
|align=center|일, 시간, 분
 +
|} <ref> 상상이비즈, 〈[http://www.mysqlkorea.com/sub.html?mcode=goods&scode=02&cat1=2 CDP Backup]〉, 《MySQL Korea》</ref>
  
 +
* '''디스크의 크기'''
 +
: 지속적 데이터 보호는 기존 백업 기술보다 더 적은 디스크 용량을 차지한다. 그 이유는 기존 백업 기술은 증분 백업(incremental back-up)이라 하더라도 일반적으로 파일 단위의 복제인 데 비해, 지속적 데이터 보호는 바이트 혹은 블록 단위로 저장하기 때문이다. 예를 들어 한 개의 100GB 파일에서 1바이트가 변경되었다면, 지속적 데이터 보호는 1바이트만 저장하는 반면, 기존 백업 기술은 100GB를 저장한다.<ref> Continuous Data Protection 위키피디아 -https://en.wikipedia.org/wiki/Continuous_Data_Protection </ref>
  
 +
== 현황과 전망 ==
 +
과거 2006년 부로 해서 지속적 데이터 보호 기술이 주목을 받기 시작했다. 그중 팔콘스토어 라는 IT 회사가 적극적으로 참여하였고 그 당시 40억 이상 매출을 올리며 지속적 데이터 보호 기술을 발전시키게 되었다. 하지만 그 당시 국내의 서버 구축에는 엔터프라이즈급의 서버가 구축된 것도 아니고 기존의 스냅샷의 방식을 이용한 지속적 데이터 보호여서 완전한 True 방식의 지속적 데이터 보호 기술을 시스템 소프트웨어에 구현하지 못하였다. 첫 백업을 시도할 때 모든 데이터를 서버에 백업해야 하고 데이터파일의 변경이 블록 단위로 저장이 되어 보다 빠르지만, 실질적으로 백업 서버에 여러 파일을 업로드 하는데 많은 지연이 발생하기도 하였다. 회사의 규모가 큰 대기업의 아직 완벽히 구현되지 않은 지속적 데이터 보호의 기술사용은 점차 줄어들게 되었고 오늘날 여러 기업과 회사에서 사용하지만, 과거만큼 활성화되어있지는 않다. 활성화되어있지 않아 가격이 오를뿐더러 일반 사용자들이 간단하게 사용 할 수 있는 클라우드 서버가 발전함에 따라 사용 빈도가 점차 줄어들게 되었다.
 +
 
{{각주}}
 
{{각주}}
  
 +
==참고자료==
  
==참고자료==
+
* Alexa Drake,〈[https://learn.g2.com/continuous-data-protection Why Continuous Data Protection Is the Best Security Guard]〉, 《Leaning Hub》, 2020-02-19
 +
* N3NCLOUDE, 〈[https://support.n3ncloud.co.kr/hc/ko/articles/360050613874-%EC%A7%80%EC%86%8D%EC%A0%81%EC%9D%B8-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%B3%B4%ED%98%B8-CDP-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94- 지속적인 데이터 보호(CDP)란 무엇인가요?], 《아크로니스》, 2020-07-06
 +
* 상상이비즈, 〈[http://www.mysqlkorea.com/sub.html?mcode=goods&scode=02&cat1=2 CDP Backup]〉, 《MySQL Korea》
 +
* IB인포텍 , 〈[https://bns.ibinfo.co.kr/6 CDP(Continuous Data Protection) 백업 솔루션에 대해...]〉, 《아이비인포텍㈜》, 2008-01-03
 +
* Chris Stakutis,〈[https://kdata.or.kr/info/info_04_view.html?field=&keyword=&type=techreport&page=210&dbnum=127735&mode=detail&type=techreport CDP란 무엇이며, 어디에 가장 적합한 기술인가]〉, 《한국데이터산업진흥원》, 2008-09-24
 +
* Continuous Data Protection 위키피디아, -https://en.wikipedia.org/wiki/Continuous_Data_Protection
  
 
==같이 보기==
 
==같이 보기==
 +
* [[백업]]
 +
* [[서버]]
 +
* [[클라우드]]
 +
* [[블록]]
 +
* [[스토리지]]
 +
* [[디스크]]
  
 
{{하드웨어|검토 필요}}
 
{{하드웨어|검토 필요}}

2020년 8월 5일 (수) 14:24 기준 최신판

지속적 데이터 보호(CDP)란 Continuous Data Protection의 약자로서 데이터(사진, 문서파일 등) 변화 시 즉각적으로 서버에 백업을 하는 것을 의미한다. 연속백업이라고도 한다. 영어 약자로 CDP(씨디피)라고 한다.

개요[편집]

지속적 데이터 보호는 데이터의 모든 변경 사항을 스토리지 또는 서버 에 저장한다. 블록 단위로 데이터를 저장하기 때문에 외부의 버퍼 오버플로우 공격이나 자연재해로 인한 데이터 손실 시 원하는 날짜 시간 심지어는 분 단위까지 파악하여 백업을 할 수 있다. 컴퓨터의 백업은 IT 사회에서 매우 흥미로운 혁신 중 하나였다. 복제 기술은 자료를 보호하는데 훌륭한 기술이 되어왔다. 기존의 백업 방식은 일정한 시간이나 날짜를 주기로 데이터가 백업 된다. 기존의 방식은 디스크 기반 라이브러리(VTL), 그리고 소프트웨어가 자동으로 백업하는 방식이었다. 예를 들어 1주일 단위로 데이터를 백업하는 회사가 있다고 가정을 한다. 디스크 손상이나 해커의 공격으로 컴퓨터의 데이터가 손실되면 1주일 단위로 지정된 데이터를 서버에서 백업할 수있다. 하지만 중요한 데이터를 하루나 이틀 전에 수정했다고 가정해보자. 서버에 백업이 되지 않음으로 작업한 데이터는 전혀 복구할 수 없고 특정한 복구 시점이나 시간으로 복구가 불가능하다. 이렇든 중요한 데이터나 혹은 공공기관, 은행 등의 데이터들은 바로바로 백업되어야 하는데 너무 오랜 시간 텀을 두게 되면 문제가 발생한다. 이는 컴퓨터도 마찬가지이다. 수많은 고객의 정보를 담고 있기 때문에 백업하는데도 오래 걸리고 변경 사항이 자주 발생한다. 보통 백업은 주말이나 저녁에 많이 이루어진다. 그래야만 네트워크나 서버에 걸리는 과부화와 자원 낭비를 막을 수 있다. 하지만 실제로 에러 발생 시 데이터를 복구하는 데는 꽤 오랜 시간이 소요되고 만만치 않다. 이렇듯 기존의 백업방식은 상당히 긴 시간이 필요하고 비용 또한 높으며 데이터 보호에 관한 관심이 높아지면서 클라우드, 스토리지 등 여러 저장 서버들이 시중에 나오게 되었고 백업 데이터의 효율을 위해 중복 데이터는 제거하고 보다 효율적인 데이터 활용과 디스크 사용을 목적으로 데이터를 백업하는 지속적 데이터 보호가 탄생하게 되었다. 즉 기존의 특정 시간으로 돌아가는 스냅샷 방법보다 더 우수하다.

특징[편집]

지속적 데이터 보호는 네트워크의 부하가 기존의 백업보다 낮으며 서버에 중복파일이 있다면 이를 제외하여 용량을 줄여 시스템 서버 성능 유지가 가능하다. 또한 로컬, 네트워크 폴더 외에도 클라우드, 소프트웨어, 운영체제까지도 저장 할 수 있고, 어느 시간이라도 복구 할 수 있다. 디렉터리의 모든 변화를 잡아내는 동시에 저장하는 형태로, 강력한 스토리지 기술인 클라우디안(Cloudian)을 필요로 한다. 그리고 서버의 성능에 영향을 미치지 않으며 디스크 용량을 절약한다. 이러한 장점을 가지고 있는 지속적 데이터 보호는 몇몇 문제점을 내포하고 있다. 먼저, 서버에 데이터를 올리는 유일한 방법으로 외부공격에 취약할 수 있다. 따라서 연속적인 데이터 보호를 위해 뛰어난 디스크 드라이브가 필요하다. 또한 데이터 자원에 대한 처리량이 증가함으로 중요하게 보호할 자원에 문제가 발생할 수 있다.

기능[편집]

지속적 데이터 보호는 어느 기업이나 개인 사용자로부터 발생하는 모든 데이터의 편집기록을 백업하기 때문에 시스템이 악성코드에 의해 해킹을 당하여도 원하는 시간대 가장 최신의 파일 데이터를 복구할 수 있다. 디렉터리 파일을 복제하고 후속 파일은 복제 원본 파일에 블록 단위로 데이터를 저장하기 때문에 오베헤더가 없고 폴더와 파일을 마지막으로 수정한 부분까지 복구가 가능하다. 기존의 백업 방식인 테이프 방식이나 아카이브보다 훨씬 더 빠르게 데이터 복구를 제동하며 기존의 있던 데이터와 충돌하지 않는다. 기존의 백업의 프로세스 낭비까지 보안을 유지하였다. 백업을 하려면 먼저 데이터를 확인해야 하고 실행 중인 프로세스를 확인해야 한다. 주로 밤이나 주말에 함으로 백업되는 데이터의 양이 제한적이고 프로세스가 실행 되는 동안 해당 프로그램은 사용하지 못한다. 지속적 데이터 보호는 프로세스를 따로 컨트롤하지 않고 백업이 가능하다. 지속적 데이터 보호 작동 방식은 현재 윈도우 7이상, 윈도우서버 2008 R2 이상에서 제공된다.[1] 데이터가 실제 변경될시 즉작적으로 백업을 하는 경우도 있고 정기적인 백업이지만 예약시간을 매우 자주 실행하여 지속적인 데이터 보호 효과를 수행 할 수 있다.

지속적 데이터 보호
작동원리

옆의 그림을 예시로 든다면 1시간을 주기로 데이터 백업을 진행하고 있다. 예상치 못한 오류나 악성 해커의 공격으로 데이터가 손실되면 해킹 받기 전 이전 시간으로 되돌릴 수 있다. 기존백업보다 훨씬 시간이 짧은 것을 알 수 있다. 그림에서는 1시간이지만 실제로는 분 단위로 백업을 올릴 수 있어서 해커의 공격에도 안전하게 데이터를 복구할 수 있다. 신속하고 정확한 복원 시간과 데이터 패킷의 어느 한 부분을 선택하여 제공함에 따라 사용자가 의도한 시점으로의 데이터 접근이 가능하고 백업이 아닌 복구에 초점이 맞추어져 있는 것이 기존 데이터 백업 방법과 가장 큰 차이점이다. 백업 방식에는 네트워크 백업 클라우드와 스토리지를 이용한 백업 SAN 백업 등 다양한 방식이 존재한다. 지속적 데이터 보호가 과거의 것을 대체하기 위해 나온 것은 사실이지만 모든 백업 업무를 처리하는 데는 많은 무리가 발생할 것이다. 지속적 데이터 보호는 깨끗한 이미지 데이터를 가지고 있어 에러가 발생하더라도 데이터 서비스를 지속해서 할 수 있어 결과적으로 비즈니스의 연결성을 제공하기 때문에 백업 기능 보안을 유지하는 그 이상의 의미를 충분히 가지게 된다.[2]

작동원리[편집]

  • 지속적 데이터 보호 백업을 위해 지속해서 생성한 백업파일을 호출한다. 데이터 보호의 백업이 생성될 전체 백업 또는 증분 백업 예비 만들 수 있다.
  • 백업 모듈 및 연속 데이터 보호가 활성화 된 상태에서 보호 계획을 처음 실행하면 전체 백업이 먼저 생성된다. 그 후에는 컨택되거나 변경된 파일/폴더에 대한 지속적 데이터 보호 백업파일이 생성된다. 백업은 항상 최신 상태로 사용자에 의해 선택된 데이터를 포함한다.
  • 선택한 파일/폴더를 변경하면 지속적 데이터 보호 백업이 생성되지 않으며 모든 변경 사항이 동일한 지속적 데이터 보호 백업에 기록된다.
  • 예약된 증분 백업 시간이 되면 백업이 삭제되고 증분 백업이 완료된 후 새 백업이 생성된다.
  • C백업은 항상 보호된 파일/폴더의 최신 실제 상태를 갖는 백업 체인에서 최신 백업으로 유지된다. 백업 모듈을 활성화하고 활성화하기로 결정으로 이미 보호 계획이있는 경우 지속적인 데이터 보호는 다음 백업은 이미 전체 백업을 가지고 바로 백업 체인으로 옵션을 사용하도록 설정한 후에 작성된다.[1] 옆의 그림에서도 자세히 볼 수 있다. 지속적 데이터 보호는 블록 기반으로 구성된 파일을 복제하고 저장하기 때문에 블록하나하나에 수정사항이 구분되어 있으며 파일변경 시에만 새로운 블록을 추가하면 된다. 원래의 정보를 가지고 있는 파일을 새로 올리므로 기존의 파일은 삭제해도 무방하며 PC는 자신이 가지고 있는 파일을 올리면 블록이 추가되어 저장되는 형태이다.

유형[편집]

블록 기반[편집]

응용 프로그램은 지속적 데이터 보호가 돌고 있는지도 모른다. 대다수 블록 기반 해법은(SAN 구조) 내장된 형태를 따르므로 서버나 스토리지 유형에 무관하게 동작한다. 아주 단순하게, 블록 기반 지속적 데이터 보호는 스토리지 네트워크를 건너 일어나는 모든 블록 쓰기를 감시해서, 논리적으로 시간 순서에 따른 쓰기 캐시를 유지하는 방법을 사용한다. 몇몇 해법은 이런 캐시 관리에서 아주 복잡한 방법을 따른다. 이렇게 하는 이유는 아주 값비싼 방법으로 트랜잭션을 재조합하는 방법과 비교해서) 캐시에 들어 있는 disk/LUN의 뷰를 즉각 보여주는 기능을 제공하기 위해서다. 블록 기반 해법은 투명하게 자료를 수집하는 과정에서 뛰어난 장점을 발휘하며, 과거 특정 시점의 뷰를 반영한다. 하지만 종종 역사적인 뷰를 활용하기 위해 추가 작업이 필요한 경우도 있다. 예를 들어, 지속해서 I/O를 스토리지에 스트리밍하는 데이터베이스 응용 프로그램을 상상해보자. 데이터베이스 동기화나 정지 시점과 일치하지 않는 특정 시점으로 뷰를 되돌리려면, 아마도 데이터베이스는 이 뷰를 기준으로 독자적인 비정상 종료 복구를 수행해야 할 것이다. 종종 블록 기반 해법은 디바이스가 복원점을 구분하기 위해 응용 프로그램 쪽에서 정지 시점과 일치하는 특정 "시각"을 태그로 기록해 놓는 태깅 연산을 지원한다. 이런 불연속적 사이에서도 지속적 데이터 보호 해법이 유용한 뷰를 제공해주긴 하지만 몇몇 응용 프로그램 재동기화라는 비용을 치뤄야 한다. 정말로 임의 시점으로 가고 싶다면 재동기화 비용은 엄청나게 높아진다. 그러므로 블록 기반 해법의 매력은 응용 프로그램 투명성이 아주 높고, 응용 프로그램 성능에 영향을 미치지 않으며, 일반적으로 하드웨어와 플랫폼 특성을 타지 않는다는 것이다.[3]

응용 프로그램 기반[편집]

스펙트럼의 반대쪽 끝에는 응용 프로그램 기반 지속적 데이터 보호가 놓여있다. 즉, 특정 응용 프로그램 DB2나 기타 몇몇 데이터베이스 또는 비슷한 응용 프로그램이 특정 시점으로 돌리기 위해 필요한 모든 저널링 정보를 처리할 책임을 전적으로 진다. 응용 프로그램에 밀접하게 통합되어 있다는 사실은 복구 능력에 훨씬 더 풍부한 기능을 제공하는 해법임을 의미한다. 예를 들어, 데이터베이스는 세 시간 전에 나타났던 테이블의 열이나 행을 복구하고, 동작 중인 응용 프로그램을 방해하지 않은 채로 살아있는 시스템에서 이런 복구 작업을 진행할 수 있을지도 모른다. 반면 블록 기반 해법은 테이블 열과 행을 보지 못하며, 가공되지 않은 블록만 볼 뿐이다. 블록 기반 해법은 전체 디스크에 대한 뷰만 제공하며, 데이터베이스와 같은 응용 프로그램은 실제 사용을 위해서는 이런 뷰를 물리적으로 마운트해야만 한다. 응용 프로그램 기반 해법의 매력은 강력한 복구 능력을 위해 응용 프로그램과 밀접하게 통합되어야 한다는 것이다. 반면 단점은 응용 프로그램과 협력해야만 제대로 동작하며, 응용 프로그램 서버에 부하를 주고 자원을 소비한다는 것이다.[3]

파일 기반[편집]

파일 기반 지속적 데이터 보호 해법은 파일 서버나 워크스테이션과 같은 응용 프로그램 호스트에서 동작하며 응용 프로그램 기반 기술과 상당히 비슷하다. 하지만 좀 더 범위가 넓은 이유는 여러 응용 프로그램과 사용자가 자연스럽게 파일 기반으로 구성된 자료를 사용하기 때문이다. 블록 기반 해법에서는 LUN/disk 단위로만 정책 설정이 가능했지만, 파일 기반 기술은 파일이나 파일 그룹 단위로 다양한 규약을 설정 할 수 있다. 특정 기계에 들어 있는 파일 집합은 단순한 형식으로 보호를 받을 필요가 없을지도 모르며, 어떤 파일 집합은 저장 시점을 오랫동안 유지할 필요가 있을지도 모른다. 또한 파일 기반 지속적 데이터 보호 해법은 부하가 중간 정도로 그치는데, 파일이 디스크에 자연스럽게 저장될 때, 이미 여러 캐시에 저장된 자료로 아주 쉽게 복사본을 만들 수 있기 때문이다. 복구 역시 파일 기반 지속적 데이터 보호 해법에서 좀 더 부드럽게 진행된다. 과거 특정 시각에서 전체 볼륨 뷰를 마운트하거나 제공할 필요가 없다. 그 대신 각 파일에 대한 개별 저장 인스턴스를 찾아서 필요한 버전을 찾아볼 수 있다. 아니면 파일이나 디렉터리 집합 복구를 원하는 특정 시각을 요청할 수도 있다.[3]

활용[편집]

파일 유형 지속적 데이터 보호는 최종 사용자와 파일 서버에 가장 적합하다. 그 이유는 보호받을 자산 즉, 파일이 더 나은 조밀도와 복구 용이성을 제공하는 지속적 데이터 보호유형과 딱 맞아떨어지기 때문이다. 파일 해법 기반의 매력은 다음과 같다. 경량이며, 파일 기반 정책, 조밀도, 좀 더 자연스러운 복구 시나리오를 제공하며 응용 프로그램/사용자가 올바른 유형을 선택한다. 매일매일 데이터 정보를 저장하고 보호하는 웹사이트나 은행, 고객의 정보를 가지고 있는 게임회사 등에서 많이 사용된다. 백업 기능 외에도 사실 복구기반에 많은 중점을 두기도 한다. 과거에는 백업만 보았다면 오류 발생 후 데이터를 다시 복구하는 것이 중요함으로 데이터 복구 시에 강력한 효과를 발휘한다. 문서 생성과 편집 등 일반적인 사무실 직원이 사용하거나 자동화된 비즈니스 응용 프로그램 XML 패키지를 사용한다면 파일 기반 해법이 제격이다. 워크스테이션과 랩톱 같은 최종 사용자용 시스템을 보호하는 데 관심이 많다면 딱 맞는 해법이다. 컴퓨터가 대부분 여러 응용 프로그램 서비스를 제공한다면 DB2나 오라클이나 전자편지 서버는 블록 기반 해법이 수용될 것이다. 응용 프로그램이 독자적인 응용 프로그램 기반 지속적 데이터 보호 기능을 내장하고 있다면, 이런 기능을 사용할 때에는 발생하는 부하가 견딜만한지 고려해야 한다.

기존방식과 비교
항목/구분 수동백업 이미지 백업 지속적 데이터 백업
백업을 위한 통합 콘솔 제공 X O O
스케쥴 백업 지원 X O O
중분 백업 지원 X O O
백업 작업 시 디스크 부하 여부 심함 심함 거의 없음
백업 시점 및 복원 시점 자동 관리 불가능 불가능 가능
네트워크 백업 전문성 X X O
OS 백업 및 복구 어려움 어려움 매우 간단함
백업 주기 관리 일 일, 시간 일, 시간, 분
[4]
  • 디스크의 크기
지속적 데이터 보호는 기존 백업 기술보다 더 적은 디스크 용량을 차지한다. 그 이유는 기존 백업 기술은 증분 백업(incremental back-up)이라 하더라도 일반적으로 파일 단위의 복제인 데 비해, 지속적 데이터 보호는 바이트 혹은 블록 단위로 저장하기 때문이다. 예를 들어 한 개의 100GB 파일에서 1바이트가 변경되었다면, 지속적 데이터 보호는 1바이트만 저장하는 반면, 기존 백업 기술은 100GB를 저장한다.[5]

현황과 전망[편집]

과거 2006년 부로 해서 지속적 데이터 보호 기술이 주목을 받기 시작했다. 그중 팔콘스토어 라는 IT 회사가 적극적으로 참여하였고 그 당시 40억 이상 매출을 올리며 지속적 데이터 보호 기술을 발전시키게 되었다. 하지만 그 당시 국내의 서버 구축에는 엔터프라이즈급의 서버가 구축된 것도 아니고 기존의 스냅샷의 방식을 이용한 지속적 데이터 보호여서 완전한 True 방식의 지속적 데이터 보호 기술을 시스템 소프트웨어에 구현하지 못하였다. 첫 백업을 시도할 때 모든 데이터를 서버에 백업해야 하고 데이터파일의 변경이 블록 단위로 저장이 되어 보다 빠르지만, 실질적으로 백업 서버에 여러 파일을 업로드 하는데 많은 지연이 발생하기도 하였다. 회사의 규모가 큰 대기업의 아직 완벽히 구현되지 않은 지속적 데이터 보호의 기술사용은 점차 줄어들게 되었고 오늘날 여러 기업과 회사에서 사용하지만, 과거만큼 활성화되어있지는 않다. 활성화되어있지 않아 가격이 오를뿐더러 일반 사용자들이 간단하게 사용 할 수 있는 클라우드 서버가 발전함에 따라 사용 빈도가 점차 줄어들게 되었다.

각주[편집]

  1. 1.0 1.1 N3NCLOUDE,〈지속적인 데이터 보호(CDP)란 무엇인가요?〉, 《아크로니스》, 2020-07-06
  2. IB인포텍 , 〈CDP(Continuous Data Protection) 백업 솔루션에 대해...〉, 《아이비인포텍㈜》, 2008-01-03
  3. 3.0 3.1 3.2 Chris Stakutis,〈CDP란 무엇이며, 어디에 가장 적합한 기술인가〉, 《한국데이터산업진흥원》, 2008-09-24
  4. 상상이비즈, 〈CDP Backup〉, 《MySQL Korea》
  5. Continuous Data Protection 위키피디아 -https://en.wikipedia.org/wiki/Continuous_Data_Protection

참고자료[편집]

같이 보기[편집]


  검수요청.png검수요청.png 이 지속적 데이터 보호 문서는 하드웨어에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.