위키원
재해복구
재해복구(DR; Disaster Recovery)란, 각종 재해 및 위험요소에 의해 정보시스템이 중단됐을 때 이를 정상으로 회복시키는 것을 의미한다. 영어 약자인 디알(DR)이라고 하는 경우가 많다. IT에서의 재해는 사전적 의미를 벗어나 지진, 태풍, 홍수, 화재 등의 자연재해 및 테러로 인한 폭파, 전쟁, 해킹, 통신장애, 전력공급차단 등 외부요인에 의한 재해, 그리고 시스템 결함, 기계적 오류, 관리정책 오류, 사용자 실수 같은 내부적 요인에 의한 장애 등 다양한 사례를 포함한다.
목차
개요
공공부문 정보화 사업의 확산으로 인한, 다수의 정보 시스템이 많은 곳에 도입되었고 이를 통해 각 기관은 내부 업무 프로세스 및 대면 서비스 등을 정보시스템을 통해 수행하고 있따. 업무의 정보시스템 의존도가 높아짐에 따라 정보시스템 중단사태가 발생할 경우 기관 전체의 업무가 마비될 수도 있는 심각한 위험성을 겪을 수 있는 상황에 이르렀다. 2001년에 발생한 미국의 9.11 태러사태 이전까지만 해도 국내의 재해재난에 대한 정보시스템 대비책은 극히 미약한 실정이었으나 최근 국내외 각종 사고사례가 증가되면서 이에 대한 대비책 마련은 필수 사항으로 자리매김되었다. 재해 예방 및 복구 방식에는 여러 종류가 있는데 각 기관의 설정에 맞는 적절한 재해 예방 및 복구방식을 선택하는 것이 중요하다. 재해복구를 위해서는 사전에 재해복구를 위한 계획 및 이를 지원하는 시스템이 준비되어야 하는데, 이를 각각 재해복구계획 및 재해복구시스템이라 일컫는다.
핵심 용어
- 백업(backup) : 백업은 데이터 복구의 핵심 구성 요소이다. 백업은 데이터의 특정 시점 복사본을 만드는 것이다. 데이터는 비구조적일 수도, 구조적인 데이터일 수도 있다. 백업은 파일, 블록 또는 이미지 기반일 수 있다. 각 백업 유형마다 장단점이 있다.
- 비즈니스 연속성(BC; Business Continuity) : 비즈니스 연속성은 '비즈니스 회복성'이라고도 하며, 광범위한 형태의 데이터 보호를 지칭한다. '재해복구'의 경우와 마찬가지로 데이터와 IT 서비스의 복원을 포함하지만 재해 중 비즈니스 운영을 지속하기 위한 프로세스와 절차도 포함한다.
- 지속적 데이터 보호(CDP; Continuous Data Protection) : 지속적 데이터 보호는 '지속적 백업' 또는 '실시간 백업'이라고도 하며, 데이터에 대한 모든 변경의 복사본을 자동으로 저장하여 IT 관리자가 어느 시점으로든 데이터를 복원할 수 있도록 하는 데이터 백업을 의미한다.
- 고가용성(HA; High Availability) : 고가용성은 재해 중 비즈니스를 지속하는 데 도움이 될 수 있는 기술의 특성이다. HA 기술은 프로덕션 시스템의 예비성을 제공하여 하나가 실패하면 다른 하나로 신속하게 '페일오버(failover)'해서 원래 시스템을 대체한다. 손상에 대비한 보호 기능은 제공하지 않는다. 고가용성은 전혀 다른 요구 사항을 충족하기 위한 기술이므로 견고한 DR 전략의 대체제로 간주해서는 안된다.
- 복제(Repllication) : 복제는 재해 발생시 IT 관리자가 최신 데이터를 복원할 수 있도록 한 위치에서 다른 위치로 데이터를 복사하는 프로세스이다. 동기 복제 솔루션은 주 스토리지와 복제 사이트에 동시에 데이터를 써서 주 복사본과 복제본이 항상 동기화되도록 한다. 비동기 복제 솔루션은 이와 달리 먼저 주 스토리지에 데이터를 쓴 다음 데이터를 복제 사이트로 복사한다. 이 경우 복제는 예약에 따라 실시되는 경우가 많다. 비동기 복제는 비용이 덜 들고 대역폭이 덜 필요하며 장거리에 걸쳐 사용할 수 있다. 동기 복제는 핵심 애플리케이션의 고가용성을 제공한다. 주 스토리지에서 복제본으로의 페일오버는 거의 즉각적으로 이뤄지므로 사용자가 경험하는 다운타임은 제로에 가깝다.
요소 및 절차
- 복구 제도 : 재해 발생시 복구시점까지의 단계별 시스템 유지 수준에 따른 역할 분담 및 업무 범위 책정을 제도적으로 마련한다. 전사적 합의가 필요하다.
- 복구 조직 : 재해 발생시 체계적인 대처로 최단 시간에 업무 정상화를 꾀할 수 있는 조직을 구성한다. 때에 따라서는 인력 자원이 필요하다.
- 복구 시스템 : 재해 복구를 위한 기반 시설로서 장소, 시스템, 네트워크 등의 전산 인트라를 구축한다. 높은 비용의 투자가 필요하다.
- 복구 계획 및 절차 : 업무 중요도 및 우선 순위 파악 후 평상시 백업 요구수준을 책정하며 재해 발생 요인 및 상황에 따른 대처 방안을 마련한다.
- 데이터 백업 : 정보시스템 현황에 알맞은 백업 정책을 구성하여 효과적인 재난 대비 복구시스템을 구축 한다. 백업 방식(유형)을 결정한다.
- 백업 관리 : 백업 작업에 대한 확인 및 데이터 정합성을 파악한며 주기적인 백업 데이터 소산 작업을 실시한다. 유사시를 대비한 백업 데이터 신뢰도 검증 작업이다.
- 복구 테스트 : 백업 데이터 확인을 통한 복구 테스트를 실시하여 재난 발생 시 소요되는 시간 및 문제점을 사전에 확인 조치 할 수 있어야 한다. 모의 훈련을 실시하는 방법이 있다.
- 사후 점검 및 확인 : 재난 및 장애 상황 분석, 효과적인 대처 방안을 마련하고, IT 재해 복구 체재 최적화 작업을 실시한다. 필요시 복구계획 및 절차를 수정한다.
재해복구시스템
유형
구축형태별 구분
- 독자구축 : 재해복구시스템을 독자적으로 구축하는 방식으로, 보안유지 및 복구의 신뢰성이 가장 높으나, 구축 및 유지비용이 가장 많이 소요된다. 비교적 규모가 큰 금융기관 등에서 주로 채택하고 있는 방식이다.
- 공동구축 : 두 개 이상의 기관이 재해복구시스템을 공동으로 이용하는 방식이다. 비용측면에서 독자구축의 경우보다 적게 소요되지만 봉나과 운용측면에서는 고려할 사항이 많고, 광역재해 발생시 공동이용기관간의 동시 재해복구가 불가능하다는 단점이 있다. 이 방식에서는 공동이용기관의 합의가 매우 중요하다.
- 상호구축 : 별도의 재해복구시스템을 구축하는 대신, 두 개 이상의 기관이 상호간의 재해복구시스템의 역할을 수행하거나, 단일 기관이 여러 개의 정보시스템 사이트를 가지고 있는 경우에는 사이트 상호간에 서로 재해복구센터의 역할을 수행하도록 하는 방식이다. 구축 및 운영비용이 저렴한 장점이 있으나 서로 다른 기관과의 이러한 방식의 재해복구시스템을 구축하는 경우 보안성 및 재해복구에 대한 신뢰성이 대단히 낮다.
운영주체별 구분
- 자체운영 : 기관 자체의 인력으로 재해복구시스템을 운영하는 방식이다. 보안성 및 신뢰성이 가장 높으나, 재해복구를 위한 추가의 인력이 확보되어야 하며 운영비용이 높다. 일반적으로 독자구축 형 재해복구센터에서 사용되는 운영방식이다.
- 공동운영 : 두 개 이상의 기관이 재해복구시스템의 운영인력을 상호 공유하는 방식이다. 일반적으로 공동구축형 또는 상호구축형 재해복구시스템에서 사용되는 운영방식이다. 자체운영에 비해 운영비용을 절감할 수 있으나, 기관간 신뢰가 전제되어야 하고, 보안성 유지를 위한 협의가 중요하다.
- 위탁운영 : 재해복구시스템의 운영을 민간 IDC 운영자 등 외부의 다른 기관에 위탁하는 방식이다. 정보시스템 운영기관의 보안성 유지가 가장 큰 문제로 대두되나, 위탁 운영 업체의 보안 유지에 대한 신뢰성이 높다면 전문적인 재해복구서비스를 제공받을 수 있으며 초기투자 비용이 적게 드는 장점이 있어, 최근 사용이 증가하는 추세에 있다. 미국의 대형금융기관 및 공공기관 등에서 이러한 형태의 사용 예를 볼 수 있다.
복구수준별 유형
- 미러 사이트(Mirror Site) : 주요 운영 시스템 DBMS에 대한 실시간 미러링으로 주센터와 백업센터간 동일한 시스템 이미지 구성 및 데이터 손실이 없어 재해/장애 발생시에도 영향이 없는 복제 시스템을 구성한다. 또한 주 센터 및 백업센터간 네트워크 이중화 구성을 통해 신속한 복구가 가능하다. 말단 사용자는 장애 상황을 알 수가 없다.
- 핫 사이트(Hot Site) : 미러 사이트와 거의 동일한 방식이나 시설 측면에서 완벽한 이중화는 아니고, 주 센터와 백업센터간의 DB를 직접 이중화하는 방안이다. 백업센터에서 LOG를 적용하여 DB를 갱신하는 시간이 소요된다.
- 웜 사이트(Warm Site) : 주기적으로 시스템 및 데이터 백업 테이프를 로컬이나 원격지에 보관 및 소산하는 방식으로 전통적인 백업 방식이다. 저비용 구성이 가능하고 대부분의 테이프(TAPE) 및 디스크(DISK) 백업 방식이 여기에 속한다.
- 콜드 사이트(Cold Site) : 주요 업무에서 발생되는 데이터, 원격지 배치(Batch)형 작업 및 비 실시간 백업으로 처리한다.
구현 기술
H/W적 복제 방식
- 디스크 장치를 이용한 복제 : 자료가 최종적으로 저장되는 디스크를 복제 대상으로하여, 사용중인 원본 디스크를 원거리 지역의 복구용 디스크로 복제하는 방식이 바로 디스크 수준의 복제 방식이다. 주 센터의 원본 디스크와 재해복구센터의 복구용 디스크는 기본적으로 마이크로코드(Microcode 2) 수준에서 완벽한 호환성을 제공하여야 하지만, 디스크에 별도의 가상화 솔루션 등을 활용한다면 이기종 디스크 간에도 복제가 가능하다. 디스크 장치를 이용한 복제방식의 구성 시, 최초에는 디스크 전체를 대상으로 복제 작업을 수행하므로 많은 시간이 소요되나, 이후 운영 시에는 디스크의 변경분만을 복제하므로, 고속 복제가 가능하다.
S/W적 복제 방식
- 운영체제를 이용한 복제 : 데이터를 디스크에 저장, 관리하기 위한 논리적인 볼륨을 만들어 사용한다. 즉, 데이터는 논리적 볼륨에서 관리, 전송되어 이것이 물리적 디스크에 저장되는 것이다. 운영체제를 이용한 복제 방식은 서버에서 디스코로 데이터를 전송하고 저장하는 중간 단계에서 데이터 블록을 복제하여 재해복구센터로 보내는 방식이다. 따라서 운영체제를 이용한 복제 방식에는 주 센터와 재해복구센터의 양쪽 서버에 데이터의 복제를 관리하기 위한 동일한 복제솔루션을 설치하여야 한다. 복제솔루션은 해당 서버 자체에서 수행되거나, 별도의 디스크 관리 서버 자원을 사용하여 수행될 수 있다 그러므로 재해복구시스템 구축 시 기존의 운영환경의 용량 및 부하를 감안하여 서버 자원의 적정성을 검토하여야 한다. 일반적으로 중간 정도의 성능과 용량의 디스크를 사용하거나, 이기종 디스크를 사용하는 운영환경에서 재해복구시스템을 구축하는 경우에 주로 사용된다.
- DBMS를 이용한 복제 방식 : 주 센터의 DBMS에서 사용되는 SQL(Structured Query Language)문 혹은 변경 로그를 원격 사이트의 DBMS에 전송하여 복제하는 방식이다. 주 센터와 재해복구센터의 DBMS 및 복제 솔루션이 동일하여아 하며, 디스크, 논리적 볼륨 및 플랫폼의 종류가 다르더라도 구현이 가능하다. 또한, DBMS를 이용한 복제 솔루션은 주 센터와 재해복구센터 서버의 자원을 사용하여 동작하므로 서버 자원의 증설을 검토하여야 한다.
데이터 전송 방식
데이터 복구 시스템에서는 데이터 복제방식과 더불어 데이터전송 방식을 알맞게 혼합하여 현 시스템과 재해복구 수준에 최적화된 재해복구시스템을 구축하는 것이 중요하다. 핮지만, 주센터 운영시스템에서의 실수나 오류로 인한 잘못된 데이터의 추가 및 변경도 재해복구센터에 동일하게 복제되어 주센터의 논리적 데이터 오류에 의한 장애시 원격지에서도 동일한 장애가 발생하게 된다. 따라서 재해복구시스템만 구축되면 모든 장애와 재해를 막을 수 있는 것은 아니다.
Sync(동기 복제)
Sync 방식은 어떠한 상황에서도 완벽한 데이터 복구를 보장하여 준다. 이 방식은 사용자 혹은 작업이 주센터의 운영 시스템에서 데이터를 추가 혹은 변경하였을 경우 주센터뿐 아니라 재해복구센터에서도 정상적으로 추가 혹은 변경이 완료 되었다는 것을 시스템에서 확인한 후에 사용자 혹은 직업에게 추가 혹은 변경 완료신호를 보내게 되는 방식이다. 따라서 주센터와 재해복구센터간의 데이터 정합성은 항상 유지되므로 가장 안전하고 신뢰성이 높은 방식이다. 그러나, 주센터와 재해복구센터 간을 연결하는 고속의 회선이 필요하다. 왜냐하면, 주센터 뿐 아니라 재해복구센터에 있는 데이터 역시 빠른 시간 내에 추가, 변경하여야 응답속도의 지연을 막아 기존의 서비스 수준을 유지할 수 있기 때문이다. 결국 이러한 요구는 고속회선을 위한 많은 회선 비용과 주센터와 재해복구센터간의 거리 제한을 가져올 수 있다. 또한 주센터와 재해복구센터간의 회선 장애 혹은 재해복구시스템의 장애 및 운영 실수는 즉시 주센터의 운영 시스템에도 영향을 미치어 서비스 장애로 이어질 수 있다. 따라서 재해복구시스템 유지 관리의 어려움과 운영수준 유지를 위한 인력, 비용이 추가로 발생하게 된다.
ASync(비동기 복제)
Async 방식의 가장 큰 특징은 Sync 방식과 달리 재해복구시스템을 구축하여 데이터를 복제하더라도 기존 운영 서비스의 성능에 거의 영향을 주지 않는다는 것이다. 재해복구시스템을 Async 방식으로 구축하면 기존 운영 서비스는 기존과 동일하게 동작하고, 데이터 복제는 기존 운영 시스템의 서비스와는 별도로 디스크, 서버 및 DbMS 수준의 전송방식에 따라 운영 서비스 이후 독립적으로 동작된다. 즉, 데이터 복제를 수행하기는 하나 그것이 언제 수행되는지는 재해복구를 위한 시스템의 환경 및 여러 조건에 따라 정해진다. 하지만, Sync 방식에 비해 현 시점에서 운영시스템의 100% 데이터 복제를 보장하지는 못한다.
고려사항
- RTO(Recovery Time Objective) : RTO란 각 업무별로 서비스 중단을 감내할 수 있는 시간을 정의하는 것으로, RTO가 규정으로 정해져 있는 기관들도 있지만 그렇지 못한 기업이나 기관들은 업무 중단에 따른 손실 비용과 기업의 연속성에 어떠한 영향을 끼칠지 감안해 이를 설정해야 한다. 각 업무별 RTO에 대한 정의가 끝나면 이와 연관된 IT 자원들이 어떻게 구성돼 있으며, 이에 대한 각 요소들의 복구 절차와 RTO에 대한 정의가필요하다.
- RPO(Recovery Point Objective) : RTO에 대한 정의가 완료되면 복구시점에 대해 정의해야 한다. 이를 RPO라고 한다. 복구할 데이터의 중요도에 따라 RPO는 바로 재해 직전, 1시간, 3시간, 하루, 일주일, 한 달 등 다양한 시점이 나올 수 있다. RPO=0이 가장 이상적이겠지만 문제는 비용이다. 이는 솔루션에 대한 비용뿐만 아니라 운영센터와 재해복구센터 간 데이터를 손실 없이 동기화하기 위해 필요한 큰 네트워크 대역폭으로 인해 발생하는 과도환 회선 비용, 네트워크 장비 등에 대한 유지비용을 불러오기 때문이다. 따라서 어붐와 데이터의 중요도에 따라 RPO를 정의해야 한다.
각주
참고자료
- 정종길 기자, 〈(기획특집) '선택'아닌'필수', DR시스템〉, 《컴퓨터월드》, 2016-09-29
- 퀘스트소프트웨어, 〈재해 복구(DR) 관련 핵심 용어 정리〉, 《네이버 블로그》, 2018-09-05
- 제임스, 〈IT 재해 복구 (Disaster Recovery)개념 설명.〉, 《네이버 블로그》, 2006-07-18
- 이진현 이사, 〈(전문가 기고)취약점 드러낸 IT재해복구 진단②〉, 《디지털데일리》, 2018-12-12
- nhojimin, 〈(시스템)재해복구〉, 《구글 블로그》, 2016-01-27
같이 보기
