의견.png

"재해복구"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
(운영방식별 유형)
잔글 (재해복구시스템)
37번째 줄: 37번째 줄:
 
*'''위탁운영''' : 재해복구시스템의 운영을 민간 IDC 운영자 등 외부의 다른 기관에 위탁하는 방식이다. 정보시스템 운영기관의 보안성 유지가 가장 큰 문제로 대두되나, 위탁 운영 업체의 보안 유지에 대한 신뢰성이 높다면 전문적인 재해복구서비스를 제공받을 수 있으며 초기투자 비용이 적게 드는 장점이 있어, 최근 사용이 증가하는 추세에 있다. 미국의 대형금융기관 및 공공기관 등에서 이러한 형태의 사용 예를 볼 수 있다.
 
*'''위탁운영''' : 재해복구시스템의 운영을 민간 IDC 운영자 등 외부의 다른 기관에 위탁하는 방식이다. 정보시스템 운영기관의 보안성 유지가 가장 큰 문제로 대두되나, 위탁 운영 업체의 보안 유지에 대한 신뢰성이 높다면 전문적인 재해복구서비스를 제공받을 수 있으며 초기투자 비용이 적게 드는 장점이 있어, 최근 사용이 증가하는 추세에 있다. 미국의 대형금융기관 및 공공기관 등에서 이러한 형태의 사용 예를 볼 수 있다.
  
===복구수준별 유형===
+
====복구수준별 유형====
 
*'''미러 사이트'''(Mirror Site) : 주요 운영 시스템 DBMS에 대한 실시간 미러링으로 주센터와 백업센터간 동일한 시스템 이미지 구성 및 데이터 손실이 없어 재해/장애 발생시에도 영향이 없는 복제 시스템을 구성한다. 또한 주 센터 및 백업센터간 네트워크 이중화 구성을 통해 신속한 복구가 가능하다. 말단 사용자는 장애 상황을 알 수가 없다.
 
*'''미러 사이트'''(Mirror Site) : 주요 운영 시스템 DBMS에 대한 실시간 미러링으로 주센터와 백업센터간 동일한 시스템 이미지 구성 및 데이터 손실이 없어 재해/장애 발생시에도 영향이 없는 복제 시스템을 구성한다. 또한 주 센터 및 백업센터간 네트워크 이중화 구성을 통해 신속한 복구가 가능하다. 말단 사용자는 장애 상황을 알 수가 없다.
 
*'''핫 사이트'''(Hot Site) : 미러 사이트와 거의 동일한 방식이나 시설 측면에서 완벽한 이중화는 아니고, 주 센터와 백업센터간의 DB를 직접 이중화하는 방안이다. 백업센터에서 LOG를 적용하여 DB를 갱신하는 시간이 소요된다.
 
*'''핫 사이트'''(Hot Site) : 미러 사이트와 거의 동일한 방식이나 시설 측면에서 완벽한 이중화는 아니고, 주 센터와 백업센터간의 DB를 직접 이중화하는 방안이다. 백업센터에서 LOG를 적용하여 DB를 갱신하는 시간이 소요된다.

2019년 9월 27일 (금) 13:25 판

재해복구(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 관리자가 최신 데이터를 복원할 수 있도록 한 위치에서 다른 위치로 데이터를 복사하는 프로세스이다. 동기 복제 솔루션은 주 스토리지와 복제 사이트에 동시에 데이터를 써서 주 복사본과 복제본이 항상 동기화되도록 한다. 비동기 복제 솔루션은 이와 달리 먼저 주 스토리지에 데이터를 쓴 다음 데이터를 복제 사이트로 복사한다. 이 경우 복제는 예약에 따라 실시되는 경우가 많다. 비동기 복제는 비용이 덜 들고 대역폭이 덜 필요하며 장거리에 걸쳐 사용할 수 있다. 동기 복제는 핵심 애플리케이션의 고가용성을 제공한다. 주 스토리지에서 복제본으로의 페일오버는 거의 즉각적으로 이뤄지므로 사용자가 경험하는 다운타임은 제로에 가깝다.

요소 및 절차

  1. 복구 제도 : 재해 발생시 복구시점까지의 단계별 시스템 유지 수준에 따른 역할 분담 및 업무 범위 책정을 제도적으로 마련한다. 전사적 합의가 필요하다.
  2. 복구 조직 : 재해 발생시 체계적인 대처로 최단 시간에 업무 정상화를 꾀할 수 있는 조직을 구성한다. 때에 따라서는 인력 자원이 필요하다.
  3. 복구 시스템 : 재해 복구를 위한 기반 시설로서 장소, 시스템, 네트워크 등의 전산 인트라를 구축한다. 높은 비용의 투자가 필요하다.
  4. 복구 계획 및 절차 : 업무 중요도 및 우선 순위 파악 후 평상시 백업 요구수준을 책정하며 재해 발생 요인 및 상황에 따른 대처 방안을 마련한다.
  5. 데이터 백업 : 정보시스템 현황에 알맞은 백업 정책을 구성하여 효과적인 재난 대비 복구시스템을 구축 한다. 백업 방식(유형)을 결정한다.
  6. 백업 관리 : 백업 작업에 대한 확인 및 데이터 정합성을 파악한며 주기적인 백업 데이터 소산 작업을 실시한다. 유사시를 대비한 백업 데이터 신뢰도 검증 작업이다.
  7. 복구 테스트 : 백업 데이터 확인을 통한 복구 테스트를 실시하여 재난 발생 시 소요되는 시간 및 문제점을 사전에 확인 조치 할 수 있어야 한다. 모의 훈련을 실시하는 방법이 있다.
  8. 사후 점검 및 확인 : 재난 및 장애 상황 분석, 효과적인 대처 방안을 마련하고, IT 재해 복구 체재 최적화 작업을 실시한다. 필요시 복구계획 및 절차를 수정한다.

재해복구시스템

유형

구축형태별 구분

  • 독자구축 : 재해복구시스템을 독자적으로 구축하는 방식으로, 보안유지 및 복구의 신뢰성이 가장 높으나, 구축 및 유지비용이 가장 많이 소요된다. 비교적 규모가 큰 금융기관 등에서 주로 채택하고 있는 방식이다.
  • 공동구축 : 두 개 이상의 기관이 재해복구시스템을 공동으로 이용하는 방식이다. 비용측면에서 독자구축의 경우보다 적게 소요되지만 봉나과 운용측면에서는 고려할 사항이 많고, 광역재해 발생시 공동이용기관간의 동시 재해복구가 불가능하다는 단점이 있다. 이 방식에서는 공동이용기관의 합의가 매우 중요하다.
  • 상호구축 : 별도의 재해복구시스템을 구축하는 대신, 두 개 이상의 기관이 상호간의 재해복구시스템의 역할을 수행하거나, 단일 기관이 여러 개의 정보시스템 사이트를 가지고 있는 경우에는 사이트 상호간에 서로 재해복구센터의 역할을 수행하도록 하는 방식이다. 구축 및 운영비용이 저렴한 장점이 있으나 서로 다른 기관과의 이러한 방식의 재해복구시스템을 구축하는 경우 보안성 및 재해복구에 대한 신뢰성이 대단히 낮다.

운영주체별 구분

  • 자체운영 : 기관 자체의 인력으로 재해복구시스템을 운영하는 방식이다. 보안성 및 신뢰성이 가장 높으나, 재해복구를 위한 추가의 인력이 확보되어야 하며 운영비용이 높다. 일반적으로 독자구축 형 재해복구센터에서 사용되는 운영방식이다.
  • 공동운영 : 두 개 이상의 기관이 재해복구시스템의 운영인력을 상호 공유하는 방식이다. 일반적으로 공동구축형 또는 상호구축형 재해복구시스템에서 사용되는 운영방식이다. 자체운영에 비해 운영비용을 절감할 수 있으나, 기관간 신뢰가 전제되어야 하고, 보안성 유지를 위한 협의가 중요하다.
  • 위탁운영 : 재해복구시스템의 운영을 민간 IDC 운영자 등 외부의 다른 기관에 위탁하는 방식이다. 정보시스템 운영기관의 보안성 유지가 가장 큰 문제로 대두되나, 위탁 운영 업체의 보안 유지에 대한 신뢰성이 높다면 전문적인 재해복구서비스를 제공받을 수 있으며 초기투자 비용이 적게 드는 장점이 있어, 최근 사용이 증가하는 추세에 있다. 미국의 대형금융기관 및 공공기관 등에서 이러한 형태의 사용 예를 볼 수 있다.

복구수준별 유형

  • 미러 사이트(Mirror Site) : 주요 운영 시스템 DBMS에 대한 실시간 미러링으로 주센터와 백업센터간 동일한 시스템 이미지 구성 및 데이터 손실이 없어 재해/장애 발생시에도 영향이 없는 복제 시스템을 구성한다. 또한 주 센터 및 백업센터간 네트워크 이중화 구성을 통해 신속한 복구가 가능하다. 말단 사용자는 장애 상황을 알 수가 없다.
  • 핫 사이트(Hot Site) : 미러 사이트와 거의 동일한 방식이나 시설 측면에서 완벽한 이중화는 아니고, 주 센터와 백업센터간의 DB를 직접 이중화하는 방안이다. 백업센터에서 LOG를 적용하여 DB를 갱신하는 시간이 소요된다.
  • 웜 사이트(Warm Site) : 주기적으로 시스템 및 데이터 백업 테이프를 로컬이나 원격지에 보관 및 소산하는 방식으로 전통적인 백업 방식이다. 저비용 구성이 가능하고 대부분의 테이프(TAPE) 및 디스크(DISK) 백업 방식이 여기에 속한다.
  • 콜드 사이트(Cold Site) : 주요 업무에서 발생되는 데이터, 원격지 배치(Batch)형 작업 및 비 실시간 백업으로 처리한다.

고려사항

  • RTO(Recovery Time Objective) : RTO란 각 업무별로 서비스 중단을 감내할 수 있는 시간을 정의하는 것으로, RTO가 규정으로 정해져 있는 기관들도 있지만 그렇지 못한 기업이나 기관들은 업무 중단에 따른 손실 비용과 기업의 연속성에 어떠한 영향을 끼칠지 감안해 이를 설정해야 한다. 각 업무별 RTO에 대한 정의가 끝나면 이와 연관된 IT 자원들이 어떻게 구성돼 있으며, 이에 대한 각 요소들의 복구 절차와 RTO에 대한 정의가필요하다.
  • RPO(Recovery Point Objective) : RTO에 대한 정의가 완료되면 복구시점에 대해 정의해야 한다. 이를 RPO라고 한다. 복구할 데이터의 중요도에 따라 RPO는 바로 재해 직전, 1시간, 3시간, 하루, 일주일, 한 달 등 다양한 시점이 나올 수 있다. RPO=0이 가장 이상적이겠지만 문제는 비용이다. 이는 솔루션에 대한 비용뿐만 아니라 운영센터와 재해복구센터 간 데이터를 손실 없이 동기화하기 위해 필요한 큰 네트워크 대역폭으로 인해 발생하는 과도환 회선 비용, 네트워크 장비 등에 대한 유지비용을 불러오기 때문이다. 따라서 어붐와 데이터의 중요도에 따라 RPO를 정의해야 한다.

각주

참고자료

같이 보기


  의견.png 이 재해복구 문서는 하드웨어에 관한 토막글입니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 이 문서의 내용을 채워주세요.