재해 복구(disaster recovery, DR)는 장비 장애 및 국지적 정전부터 사이버 공격, 시민 긴급 상황, 범죄 또는 군대 공격 및 자연 재해까지 모든 재해 상황으로 인한 데이터 손실 및 비즈니스 운영 중단을 예방 또는 최소화하기 위한 IT 기술 및 베스트 프랙티스로 구성되어 있습니다.

많은 기업들, 특히 중소기업은 신뢰할 수 있고 실현 가능한 재해 복구 계획 개발을 소홀히 합니다. 이러한 계획이 없으면 조직은 상당히 파괴적인 이벤트의 영향으로부터 거의 보호받지 못합니다.

인프라 장애는 시간당 최대 미화 100,000 달러 (IBM 외부 링크)의 비용을 초래할 수 있으며, 중요한 애플리케이션의 장애는 시간당 미화 500,000 ~ 100만 달러의 비용을 초래할 수 있습니다. 그러한 손실을 입고 회복할 수 있는 기업은 많지 않습니다. 소규모 기업 중 40% 이상이 재해를 경험한 후 사업을 재개하지 못하며, 사업을 재개하는 기업 중 25%는 위기를 겪은 이후 1년 안에 실패합니다. 재해 복구 계획은 이러한 리스크를 대폭 줄일 수 있습니다.

재해 복구 계획에는 전략 수립, 계획, 적절한 기술 활용 및 지속적 테스트가 수반됩니다. 데이터를 백업하는 것은 재해 복구 계획의 중요한 구성 요소지만, 백업 및 복구 프로세스 자체로 완전한 재해 복구 계획이 완성되는 것은 아닙니다.

또한 재해 복구를 위해서는 강력한 페일오버 및 페일백 절차를 수행하기 위해 적절한 스토리지와 컴퓨팅을 이용할 수 있어야 합니다. 페일오버 는 프로덕션 프로세스와 최종 사용자 경험이 최소한으로 중단되도록 워크로드를 백업 시스템으로 보내는 프로세스입니다. 페일백 은 원래의 주 시스템으로 전환하는 작업을 수반합니다.

IBM의 글을 읽고  백업과 재해 복구 계획 사이의 중요한 차이점에 대한 정보를 확인해 보세요.

비즈니스 연속성 계획은 위기 또는 긴급 상황 발생 시 기업의 모든 부문이 필수적 운영을 유지할 수 있거나 최대한 빨리 필수적 운영을 재개할 수 있도록 하는 시스템과 프로세스를 제공합니다. 재해 복구 계획은 IT 인프라와 시스템의 복구에 집중하는 비즈니스 연속성 계획의 하위 그룹입니다.

비즈니스 영향 분석

포괄적인 재해 복구 계획을 수립하려면 비즈니스 영향 분석부터 시작해야 합니다. 이 분석을 수행할 때는 특정 비즈니스 프로세스가 중단될 경우 발생할 수 있는 손실의 규모와 범위를 예측하기 위한 일련의 상세한 재해 시나리오를 작성합니다. 예를 들면, 고객 서비스 콜센터가 화재로 파괴될 경우 어떻게 해야 할까요? 또는 본사에 지진이 발생하면 어떻게 해야 할까요?

재해 영향 분석을 통해 가장 중요한 비즈니스 부문과 부서가 어디인지 파악하고 이러한 중대한 부서가 견딜 수 있는 다운타임이 얼마인지 결정할 수 있습니다. 이러한 정보를 확보하면 다양한 시나리오에서 가장 중요한 운영을 유지할 수 있도록 계획을 수립하기 시작합니다.

IT 재해 복구 계획은 비즈니스 연속성 계획의 내용을 따르고 이를 지원해야 합니다. 예를 들어, 비즈니스 연속성 계획에서 고객 서비스 담당자에게 콜센터 화재로 인해 재택근무를 수행하도록 규정하고 있는 경우, 이 계획을 지원하기 위해 어떤 유형의 하드웨어, 소프트웨어, IT 리소스를 제공해야 할까요?

리스크 분석

기업이 직면한 리스크의 가능성 또는 그로 인해 발생할 수 있는 결과를 평가하는 것 역시 재해 복구 계획의 필수적 구성 요소입니다. 사이버 공격과 랜섬웨어가 더 만연해지고 있으므로 현재 모든 기업이 직면한 일반적 사이버 보안 리스크뿐만 아니라 특정 산업 및 지리적 위치에서 발생하는 리스크도 이해해야 합니다.

자연 재해, 장비 장애, 내부자 위협, 사보타주 및 직원의 실수 등 다양한 시나리오를 가정하고 리스크를 평가하고 비즈니스에 대한 전반적 영향을 고려해야 합니다. 스스로에게 다음 질문을 해보세요.

• 놓친 영업 기회 또는 수익 창출 활동의 중단으로 인해 재무적 손실이 얼마나 발생할까요?
  
  
• 브랜드 평판이 어떻게 훼손될까요? 고객 만족도가 어떤 영향을 받을까요?
  
  
• 직원 생산성에는 어떤 영향이 발생할까요? 노동 시간이 얼마나 손실될까요?
  
  
• 인시던트가 건강과 안전에 어떤 리스크를 제기할까요?
  
  
• 비즈니스 이니셔티브 또는 목표를 향해 나아가는 데 영향이 발생할까요? 그렇다면 어떤 방식일까요?

애플리케이션 우선 순위 지정

비즈니스 운영을 지속하는 데 모든 워크로드의 중요성이 똑같지는 않습니다. 특정 애플리케이션은 다른 애플리케이션보다 다운타임을 훨씬 더 잘 견딜 수 있습니다. 견딜 수 있는 중단 시간과 데이터 손실로 인한 결과의 심각성에 따라 시스템과 애플리케이션을 세 가지 계층으로 분리하세요.

1. 미션 크리티컬: 비즈니스의 생존에 필수적인 애플리케이션입니다.
   
   
2. 중요: 비교적 짧은 다운타임을 견딜 수 있는 애플리케이션입니다.
   
   
3. 비필수: 임시적으로 수동 프로세스로 대체하거나 없는 상태에서 운영을 유지할 수 있는 애플리케이션입니다.

의존성 문서화

재해 복구 계획의 다음 단계는 모든 하드웨어 및 소프트웨어 자산의 목록을 작성하는 것입니다. 이 단계에서는 중요한 애플리케이션의 상호의존성을 이해하는 것이 필수적입니다. 하나의 소프트웨어 애플리케이션이 중단될 경우 영향을 받는 다른 애플리케이션은 무엇인가요?

시스템이 처음 구축될 때 시스템에 복원력을 구현하고 재해 복구 모델을 적용하는 것이 애플리케이션 상호의존성을 관리하는 가장 좋은 방법입니다. 오늘날의 마이크로서비스 기반 아키텍처에서는 다른 시스템이나 프로세스가 중단되면 시작할 수 없는 프로세스를 너무 흔히 볼 수 있습니다. 이러한 상황에서는 복구가 어렵습니다. 그러므로 실제로 재해가 발생하기 전에 시스템과 프로세스를 위한 대안적 계획을 개발할 수 있는 시간이 있을 때 이러한 문제를 반드시 찾아내야 합니다.

복구 목표 시간, 복구 목표 시점, 복구 목표 일관성 설정

리스크와 비즈니스 영향 분석을 고려하여 시스템을 다시 가동하는 데 걸리는 시간, 사용 가능한 데이터의 양, 견딜 수 있는 데이터 손상 또는 이탈의 정도에 관한 목표를 설정할 수 있을 것입니다.

복구 목표 시간(recovery time objective, RTO)은 서비스 중단 후 애플리케이션 또는 시스템의 기능을 복원하는 데 걸려야 하는 최대 시간입니다.

복구 목표 시점(recovery point objective, RPO)은 정상적 비즈니스 운영을 재개하려면 복구되어야 하는 데이터의 최대 연령입니다. 어떤 기업은 몇 분 분량의 데이터 손실도 파괴적인 결과를 가져올 수 있지만, 어떤 산업은 더 오랜 시간을 견딜 수 있습니다.

복구 목표 일관성(recovery consistency objective, RCO)은 지속적 데이터 보호 서비스를 위해 서비스 수준 계약(service level agreement, SLA)에서 설정됩니다. RCO는 복구된 프로세스 또는 시스템의 비즈니스 데이터 중 일관적이지 않은 항목을 몇 개까지 견딜 수 있는지 나타내는 지표로, 복잡한 애플리케이션 환경에서 비즈니스 데이터의 무결성을 보여줍니다.

규정 준수 문제

기업이 설치한 모든 재해 복구 소프트웨어와 솔루션은 의무적으로 준수해야 하는 데이터 보호 및 보안 요구 사항을 모두 충족해야 합니다. 즉, 모든 데이터 백업 및 페일오버 시스템이 데이터 기밀성과 무결성 유지를 위해 주 시스템과 동일한 기준을 충족해야 합니다.

이와 동시에 여러 규제 표준은 모든 기업이 재해 복구 및/또는 비즈니스 연속성 계획을 관리해야 한다고 규정하고 있습니다. 예를 들면, SOX(Sarbanes-Oxley Act)에 따르면 미국 내 모든 공개 기업은 모든 비즈니스 기록의 사본을 최소한 5년간 보관해야 합니다. 이 규정을 준수하지 않으면(적절한 데이터 백업 시스템을 마련하고 테스트하지 않는 경우 포함) 기업은 상당한 벌금을 물을 수 있으며, 리더는 심지어 감옥에 갈 수도 있습니다.

기술 선택

백업은 견고한 재해 복구 계획 수립의 토대로서 역할을 수행합니다. 과거에는 대부분의 기업들이 데이터의 사본을 여러 개 보관하고 최소한 하나의 사본은 오프사이트 위치에 저장하면서 백업을 위해 테이프와 회전하는 디스크(HDD)에 의존했습니다.

오늘날처럼 상시 가동되고 디지털 혁신이 진행되는 세상에서는 오프사이트 저장소에 테이프 백업을 보관하면 비즈니스 크리티컬 운영을 지속하는 데 필요한 RTO를 달성하지 못하는 경우가 많습니다. 자체 재해 복구 솔루션을 설계할 경우 프로덕션 환경의 기능 다수를 복제해야 하고, 지원 담당 직원, 관리, 시설, 인프라와 관련된 비용을 초래할 것입니다. 이러한 이유로 많은 조직들이 클라우드 기반 백업 솔루션 또는 종합 DRaaS(Disaster-Recovery-as-a-Service) 제공업체로 관심을 돌리고 있습니다.

복구 사이트 위치 선택

자체 재해 복구 데이터 센터 를 구축하려면 여러 가지 목표들 사이의 균형을 유지해야 합니다. 한편으로는 데이터 사본 하나를 주 사이트에서 발생한 지진, 환경적 위협 또는 기타 위험의 영향을 받지 않도록 본사 또는 사무실에서 충분히 지리적으로 멀리 떨어진 곳에 저장해야 합니다. 그러나 다른 한편으로는 오프사이트에 저장된 백업은 주 사이트의 온프레미스에 위치한 백업보다 복구하는 데 항상 시간이 더 걸리며, 거리가 멀기 때문에 네트워크 레이턴시가 훨씬 더 클 수 있습니다.

지속적인 테스트 및 검토

간단히 말해, 재해 복구 계획을 테스트하지 않았다면 그 계획은 신뢰할 수 없습니다. 관련 책임이 있는 모든 직원은 재해 복구 테스트 연습에 참여해야 합니다. 이 연습에는 한동안 페일오버 사이트로부터 운영을 유지하는 것도 포함될 수 있습니다.

포괄적인 재해 복구 테스트 수행이 예산 또는 능력 범위 밖일 경우, 테스트 절차를 훑어보는 "탁상 훈련"을 계획할 수도 있습니다. 물론 이러한 종류의 테스트는 완전한 테스트보다 DR 절차의 이상 또는 약점을 드러내기 어렵다는 점을 알아야 합니다. 특히, 이전에 발견하지 못한 애플리케이션 상호의존성이 존재하는 경우 더욱 그러합니다.

시간이 흐르면서 하드웨어 및 소프트웨어 자산이 변경되면 재해 복구 계획도 업데이트되어야 합니다. 계속해서 정기적으로 계획을 검토하고 수정해야 합니다.

IBM Knowledge Center는 재해 복구 계획의 예를 제공합니다.

DRaaS(Disaster-Recovery-as-a-Service)는 오늘날 제공되는 것 중 가장 인기 있고 빠르게 성장 중인 매니지드 IT 서비스 오퍼링 중 하나입니다. 공급업체는 다운타임 한계치와 애플리케이션 복구에 대한 기대치를 설명하는 서비스 수준 계약(SLA)에 RTO와 RPO를 기재할 것입니다.

DRaaS 공급업체는 일반적으로 클라우드 기반 페일오버 환경을 제공합니다. 이 모델은 자체 데이터 센터에 중복된 전담 하드웨어 리소스를 두는 경우에 비해 상당한 비용 절감 효과를 제공합니다. 계약을 통해 고객은 페일오버 기능에 대한 비용과 더불어 재해 복구 상황에서 소비된 리소스에 대한 사용량 기반 비용을 지불할 수 있습니다. 공급업체는 일반적으로 페일오버 환경 구성 및 관리에 대한 모든 책임을 집니다.

재해 복구 서비스 오퍼링은 공급업체마다 다릅니다. 포괄적인 일체형 솔루션인 오퍼링을 제공하는 공급업체도 있고, 한 번의 애플리케이션 복원부터 클라우드에 전체 데이터 센터를 복제하는 일까지 단편적 서비스를 제공하는 공급업체도 있습니다. 재해 복구 계획 또는 테스트 서비스를 포함하는 오퍼링도 있고, 이러한 오퍼링에 대해 추가 컨설팅 요금을 부과하는 오퍼링도 있습니다.

협력 중인 퍼블릭 클라우드 제공업체뿐만 아니라 사용 중인 엔터프라이즈 소프트웨어 애플리케이션도 지원되는지 반드시 확인해야 합니다. 또한 페일오버 환경에서 애플리케이션 성능이 만족스러운지, 페일오버 및 페일백 절차에 대한 테스트가 잘 수행되었는지도 확인해야 합니다.

온프레미스 재해 복구(DR) 솔루션을 이미 구축했다면 월간 DRaaS 구독으로 이동할 경우와 비교하여 그 비용 및 이점을 평가하기가 어려울 수 있습니다.

대부분의 온프레미스 DR 솔루션은 하드웨어, 전력, 유지 및 관리 노동력, 소프트웨어, 네트워크 연결을 위한 비용이 발생합니다. DR 환경의 초기 설정에 수반되는 초기 자본 지출뿐만 아니라 정기적 소프트웨어 업그레이드를 위한 예산도 확보해야 합니다. DR 솔루션은 주 프로덕션 환경과 호환되어야 하므로 DR 솔루션에 동일한 소프트웨어 버전이 설치되어 있는지 확인해야 합니다. 라이센스 계약의 구체적 내용에 따라 이로 인해 사실상 소프트웨어 비용이 두 배로 늘어날 수 있습니다.

DRaaS 구독으로 이동하면 하드웨어 및 소프트웨어에 대한 지출을 줄일 수 있을 뿐만 아니라 페일오버 사이트 관리 부담을 공급업체에 넘겨 인건비도 낮출 수 있습니다.

타사 DRaaS 솔루션을 고려 중이라면 공급업체가 지역 간 다중 사이트 백업을 수행할 수 있는 능력이 있는지 확인해야 합니다. 허리케인과 같은 중대한 날씨 상황이 주 사무소의 위치에 영향을 준다면 페일오버 사이트는 이 폭풍의 영향을 받지 않을 만큼 멀리 떨어져 있나요? 또한, 많은 고객이 동시에 영향을 받는 경우 해당 지역의 모든 고객의 요구 사항을 충족하기에 적절한 역량을 공급업체가 갖추고 있나요? 위기 발생 시 DRaaS 공급업체는 RTO 및 RPO를 충족할 것으로 믿을 수 있어야 합니다. 그러므로 신뢰성이 높다는 우수한 평판을 보유한 서비스 제공업체를 찾으세요.

“DRaaS(Disaster Recovery as a Service)와 DR(Disaster Recovery): 어느 것이 필요할까요?”를 읽고 이 두 솔루션을 대략적으로 비교해 보세요.