검색
이 검색창을 닫습니다.

재해 복구

재해 복구 계획 및 시스템 복구 프로세스에 대한 Cristie 소프트웨어 가이드

1. 소개

폭풍으로 본사가 침수되거나 팬데믹으로 인해 직원들이 원격 근무를 해야 하거나 사이버 공격으로 시스템이 손상되는 등 재난 상황은 어디에서든 발생할 수 있으며, 이러한 상황에서는 직원과 비즈니스가 계속 운영될 수 있도록 계획을 준비하는 것이 중요합니다. 완전한 정상 상태는 아니더라도 가능한 한 빨리 고객에게 적절한 수준의 서비스 경험을 제공할 수 있는 위치에 도달하는 것은 비즈니스의 생존을 위해 매우 중요합니다. 예상치 못한 사건으로 인한 위험을 완화하기 위한 전략을 개발하는 행위는 비즈니스 연속성 관리의 핵심이며 모든 기업이 수행해야 하는 필수적인 프로세스입니다. 안타깝게도 연구에 따르면 적절한 복구 계획을 수립한 소규모 기업은 35%에 불과하며, 복구 프로세스가 전혀 없는 기업 중 10%만이 주요 사고에서 살아남을 수 있는 것으로 나타났습니다. 시스템 재해 복구 계획(DRP)은 전체 비즈니스 연속성 계획의 하위 집합이며, 여기서는 시스템 복구 프로세스를 중점적으로 다룰 것입니다. DR 계획은 서버 시설, IT 자산, 기타 중요한 인프라 시스템 및 데이터를 포함한 중요한 지원 시스템을 복원하는 등 예기치 않은 사고에 대응하는 방법에 대한 지침이 포함된 문서화된 접근 방식입니다. 재해 복구 계획의 목적은 비즈니스 및 서비스 중단 시간을 최소화하고 가능한 한 최단 시간 내에 기술 운영을 정상 운영으로 복구하는 것입니다. 비즈니스 전략 및 계획의 많은 영역과 마찬가지로 DR 계획을 수립할 때는 비즈니스 운영의 핵심 요소에 대한 위험과 다운타임 비용에 대한 평가를 포함하는 절충안이 필요합니다.

다운타임으로 인한 비용은 얼마인가요?

중요한 IT 시스템의 다운타임은 비즈니스 프로세스의 정상적인 흐름에 어떤 식으로든 영향을 미치며 거의 모든 경우에 매출 손실로 이어집니다. 물론 다운타임의 정확한 비용은 측정하기 매우 어려운 수치입니다. 비즈니스 규모, 산업 분야, 실제 가동 중단 기간, 영향을 받은 인원 수, 시간대 등 여러 가지 요인이 작용합니다. 일반적으로 은행이나 온라인 소매점과 같이 데이터 거래량이 많은 비즈니스의 경우 시간당 손실이 훨씬 더 높습니다. 2019년 14시간 동안 정전이 발생하여 약 9천만 달러의 손실을 입은 Facebook과 2016년1에 델타항공 운영 센터에서 5시간 동안 정전이 발생하여 2,000편의 항공편이 취소되고 약 1억 5천만 달러의 손실이 발생한 델타항공2 등 유명한 사례가 많이 있었습니다. 물론 이러한 기업들은 막대한 영업 이익과 수백만 달러의 자금을 보유한 업계 선두주자이므로 하루의 재정적 폭풍을 다른 기업들보다 훨씬 잘 이겨낼 수 있습니다. 소규모 기업은 대형 사고 발생 시 손실 규모가 작을 수 있지만, 전반적인 영향은 파산에 이를 정도로 훨씬 더 큰 피해를 입을 수 있습니다. 업계 분석 기관인 Gartner는 2014년에 다운타임 비용 조사를 실시하여 IT 다운타임의 평균 비용을 분당 5,600달러로 파악했습니다. 이 보고서에 따르면 비즈니스 운영 방식에 따라 큰 차이가 있기 때문에 다운타임은 낮은 수준에서는 시간당 14만 달러, 평균적으로 시간당 30만 달러, 높은 수준에서는 시간당 54만 달러에 달할 수 있습니다3. 물론 2022년으로 앞당기면 이 수치는 훨씬 더 높아질 것입니다. 비즈니스 섹션의 다운타임 비용을 결정하는 기본적인 방법은 영향을 받은 직원 수를 파악하고 평균 시간당 급여를 계산한 다음 다운타임이 생산성에 미치는 영향을 결정하는 것입니다. 예를 들어 전체 생산 라인이 중단되면 제조 부서에 미치는 영향이 100%가 되는 경우 다음 공식을 적용합니다: 다운타임 비용 = (영향을 받는 직원 수) x (생산성에 미치는 영향) x (평균 시간당 급여)또한 직원의 도덕성, 기업의 평판, 브랜드 및 고객 충성도에 미치는 영향과 같이 다운타임에 대한 가시적이지 않은 몇 가지 비용도 고려해야 합니다. DR 계획 및 운영 복원력 구축에 대한 가치 외에도 다운타임 비용 분석은 비즈니스 모델에 대해 전략적으로 사고하고 전술적 관점에서 비즈니스를 더 잘 이해하는 데 도움이 될 수 있습니다.

비즈니스 기능에 허용되는 RTO 및 RPO는 무엇인가요?

각 비즈니스 기능에 대해 허용 가능한 복구 시간 목표(RTO)와 복구 지점 목표(RPO)를 결정하는 것이 중요합니다. 경우에 따라 이러한 매개변수는 고객과 맺은 특정 서비스 수준 계약 또는 조직 내부의 특정 서비스 수준 계약에 따라 결정될 수 있습니다. 이름에서 알 수 있듯이 RTO는 가동 중단 시나리오가 발생하기 전의 기능 상태로 시스템을 완전히 복구하는 데 걸리는 최대 허용 시간을 정의합니다. RPO는 재해 또는 이와 유사한 이벤트에서 복구한 후 데이터 손실이 조직에서 허용 가능한 수준을 초과하기 전에 손실될 수 있는 최대 데이터 양을 시간 단위로 측정한 값으로 정의됩니다. 이러한 매개변수는 최악의 시나리오를 가정하여 계산하는 것이 중요합니다. 기본 인프라에 대한 고려 없이 수동 단일 시스템 복구에 대한 추정치를 기반으로 RTO를 계산하는 경우가 많습니다. 사이버 공격이나 자연 재해와 같은 많은 상황에서 여러 시스템을 복구해야 하는 현실은 실제 RTO를 크게 증가시키고 시스템의 수동 복구가 비현실적이라는 사실을 강조합니다. 복구 프로세스에서 복구 자동화가 중요한 역할을 하는 다중 시스템 복구를 고려해야 진정한 RTO를 추정할 수 있습니다. RTO를 단축하거나 RPO를 좁히려면 일반적으로 비용이 증가하므로 이러한 매개 변수를 설정하기 전에 보호하려는 각 시스템에 대한 위험 평가와 다운타임 비용 계산을 수행해야 합니다.

2. 위험 식별

위험 평가 수행

DRP를 구현하기 전에 비즈니스에 발생할 수 있는 모든 잠재적 취약성과 위험에 대한 평가를 수행해야 합니다. DR 위험 평가는 자연 재해와 인재로 인한 조직의 기능에 대한 잠재적 위험을 결정하며, 각 시나리오의 발생 확률을 추정합니다. 그런 다음 이러한 추정 결과에 각 시나리오에 대한 다운타임 비용을 곱해야 합니다. 결정된 값은 조직이 특정 위협에 대해 고려해야 하는 보호 수준을 정의합니다. 그러나 데이터 손실로 인해 업계 규정 준수 규정을 위반할 수 있는 경우와 같이 장기적인 불이익을 고려해야 하는 경우도 있을 수 있습니다. 예를 들어, '검색 가능한 정확한 전자 보호 건강 정보 사본'의 안전한 백업을 특별히 요구하는 전자 보호 건강 정보(ePHI) 보호에 관한 HIPPA 규정이 적용되는 의료 부문 조직에서 홍수로 인해 모든 데이터가 소실된 경우, 안전한 백업 사이트가 없다면 기록이 파괴된 후에도 몇 달 또는 몇 년 동안 규정 준수 문제가 지속될 것입니다. 재해가 자연적이든 인위적이든, 시스템 손실 외에도 정상적인 비즈니스 운영 중에 익숙한 리소스와 직원에 액세스할 수 없는 상황을 파악하고 이에 대한 계획을 세우는 것도 중요합니다.

위험 유형 및 특성

자연 재해

자연재해는 종종 건물 및 지원 인프라에 대한 접근에 영향을 미치므로 위험 평가에서 그러한 이벤트가 발생할 가능성이 충분하다고 판단되는 경우 완전한 사이트 복제를 고려해야 합니다. 자연재해가 발생하기 쉬운 지역에 있는 경우에는 복제 사이트 위치를 고려해야 합니다. 예를 들어 캘리포니아주 샌프란시스코에 위치한 금융 회사를 생각해 보겠습니다. 금융은 엄격하게 규제되는 산업이며, 회사는 매우 구체적인 방식으로 기록을 유지해야 합니다. 또한 이 회사는 캘리포니아에 있기 때문에 지진에 대한 위험도 높습니다. 이러한 제약을 고려할 때 데이터 센터가 파괴될 경우 벌금을 피하기 위해 데이터 센터를 백업하고 복제 사이트는 지진에 덜 취약한 다른 위치에 있는지 확인해야 합니다. 마찬가지로 홍수 범람 지역 내에 위치한 경우 로컬 현장 복제는 가장 안전한 옵션이 아닐 수 있습니다.

인적 오류

가장 흔한 형태의 인적 오류는 실수로 파일이나 폴더를 삭제하는 것입니다. 이러한 상황을 완화하려면 중요한 데이터 볼륨을 정기적으로 백업하여 삭제된 항목을 적절한 시점의 사본에서 복원할 수 있도록 예약해야 합니다. 물론 사람이 실수로 파일을 삭제하는 것을 넘어 실수로 시스템을 종료하거나 네트워크 케이블을 분리하고 데이터를 잘못 입력하는 등 원치 않는 작업을 수행할 수 있으며, 안타깝게도 사이버 범죄를 조장할 수 있는 가장 큰 위험 요소입니다. 사이버 공격의 98%는 소셜 엔지니어링5에 의존하여 로그인 및 개인 정보를 얻거나 직원이 악성 파일 첨부파일을 열어 악성코드 페이로드를 전달합니다. 여기서 다룰 수 있는 것보다 훨씬 더 많은 논의가 필요한 인간에 의한 사이버 위험 외에도, 시스템 물리적 액세스를 필요한 직원으로 제한하고 가장 중요한 시스템에 대한 로그인 액세스를 필수 직원으로만 제한하면 실수로 인한 시스템 종료 및 파일 삭제와 같은 오류를 줄일 수 있습니다.

정전

예기치 않은 정전이 발생하면 시스템이 예기치 않게 종료되어 트랜잭션이 손실되거나 데이터 파일이 손상될 수 있습니다. 최소한 중요한 시스템에는 입력 전원 또는 주 전원에 장애가 발생했을 때 비상 전원을 공급하는 무정전 전원 장치(UPS)가 지원되어야 합니다. UPS는 일정 시간 동안 전원을 공급하여 정상적으로 시스템을 종료하거나 백업 발전기의 대체 전원을 사용할 수 있는 경우 이를 적용할 수 있어야 합니다. 클라우드 또는 별도의 물리적 사이트에 복제하면 정전 시 페일오버를 제공할 수 있지만 네트워크 액세스 및 통신 시스템도 정전의 영향을 받을 수 있으므로 대체 네트워크 액세스 방법을 DRP에 고려해야 합니다.

하드웨어 장애

기본 하드웨어로 인한 시스템 장애는 점진적으로 발생하거나 즉각적이고 치명적인 결과를 초래할 수 있습니다. 하드 디스크 드라이브(HDD)는 움직이는 기계 부품으로 인해 점진적인 장애 패턴을 보이는 경우가 많으며, 이는 다양한 수준의 RAID와 같은 데이터 보호 메커니즘을 구현하여 완화할 수 있습니다. 마찬가지로 움직이는 부품이 없는 플래시 기반 스토리지와 SSD 드라이브는 수명이 한정되어 있고 마모 특성으로 인해 시간이 지남에 따라 사용 가능한 용량이 제한됩니다. SSD는 비교적 최근에 출시된 제품이기 때문에 제조업체들은 여전히 수명을 파악하기 위해 노력하고 있습니다. 현재 추정치에 따르면 SSD의 평균 수명은 10년이지만 실제로는 이보다 더 짧은 것으로 보입니다. Google과 토론토 대학교의 공동 연구에 참여한 연구원들이 다년간에 걸쳐 SSD를 테스트한 결과, SSD는 HDD보다 교체 빈도가 약 25% 낮은 것으로 나타났습니다4. 마찬가지로 시스템 메모리는 점진적인 장애를 나타낼 수 있지만, 시스템 메모리는 일반적으로 애플리케이션 코드 명령어와 운영 데이터를 보관하기 때문에 대부분의 메모리 장애는 애플리케이션 또는 운영 체제 충돌로 이어집니다. 시스템 보드 수준의 장애는 일반적으로 치명적이어서 영향을 받은 보드를 교체하거나 전체 시스템 이미지를 교체용 물리적 머신으로 복구해야 합니다. 대체 시스템 하드웨어가 원본과 동일하지 않은 경우, 부팅에 중요한 드라이버의 차이로 인해 복구 프로세스에 문제가 발생하여 IT 지원팀의 개입 시간이 길어질 수 있습니다. 서로 다른 하드웨어로 시스템을 원활하게 복구하는 솔루션은 섹션 3에 설명되어 있습니다.

업그레이드 오류

인적 오류 가장 흔한 형태의 인적 오류는 실수로 파일이나 폴더를 삭제하는 것입니다. 이러한 상황을 완화하려면 중요한 데이터 볼륨을 정기적으로 백업하여 삭제된 항목을 적절한 시점의 사본에서 복원할 수 있도록 예약해야 합니다. 물론 사람이 실수로 파일을 삭제하는 것을 넘어 실수로 시스템을 종료하거나 네트워크 케이블을 분리하고 데이터를 잘못 입력하는 등 원치 않는 작업을 수행할 수 있으며, 안타깝게도 사이버 범죄를 조장할 수 있는 가장 큰 위험 요소입니다. 사이버 공격의 98%는 소셜 엔지니어링5에 의존하여 로그인 및 개인 정보를 얻거나 직원이 악성 파일 첨부파일을 열어 악성코드 페이로드를 전달합니다. 여기서 다룰 수 있는 것보다 훨씬 더 많은 논의가 필요한 인간에 의한 사이버 위험 외에도 실수로 인한 시스템 종료 및 파일 삭제와 같은 오류는 필요한 직원만 시스템에 물리적으로 접근할 수 있도록 제한하고, 마찬가지로 가장 중요한 시스템의 로그인 액세스도 필수 직원만 제한함으로써 줄일 수 있습니다.업그레이드 오류IT 인프라 내의 대부분의 요소는 버그 수정, 새로운 기능을 제공하고 가장 중요한 것은 장비 제조업체에서 발견한 사이버 공격 취약점을 차단하기 위해 정기적으로 소프트웨어 또는 펌웨어 업데이트가 필요합니다. 따라서 정기적인 업데이트는 일반적으로 좋은 일이며 사이버 범죄와의 전쟁에서 적극 권장됩니다. 업그레이드로 인해 애플리케이션 간의 호환성에 영향을 미치는 문제가 발생할 수 있습니다. 이 문제는 관련 애플리케이션을 올바른 순서로 업그레이드하여 해결해야 할 수도 있고, 경우에 따라 애플리케이션 간 호환성을 유지하기 위해 이전 버전으로 롤백하는 것이 유일한 옵션일 수도 있습니다. 대부분의 패치 업그레이드에는 롤백 또는 제거 기능이 있습니다. 그렇지 않은 경우에는 특정 시점 백업에서 이전 버전으로 복원하는 것이 유일한 옵션일 수 있습니다. 마찬가지로 패치 파일에 버그가 포함되어 업그레이드가 실패하여 롤백이 필요한 경우도 드물지 않습니다. 많은 소프트웨어 애플리케이션, 운영 체제 및 네트워크 장치는 자동 업데이트를 제공하므로 예기치 않은 업그레이드 문제와 예기치 않은 다운타임이 발생할 수 있으므로 패치 관리는 원치 않는 다운타임을 방지하기 위해 구체적인 계획과 집중이 필요한 중요한 작업입니다.

레거시 시스템 지원

많은 비즈니스 애플리케이션의 클라우드 전환과 서비스형 플랫폼 제공 모델이 점차 확산되고 있지만, 단기간에 클라우드 마이그레이션 계획이 없는 부문별 레거시 애플리케이션에 대해 답하는 기업이 많습니다. 특정 레거시 애플리케이션은 '지원 종료'가 지난 레거시 운영 체제를 장기간 사용해야 하는데, 이는 운영 체제 개발자가 더 이상 기술 지원을 제공하지 않으며, 더 중요한 것은 운영 체제에 대한 업데이트를 더 이상 제공하지 않는다는 것을 의미합니다. 이는 중요한 데이터를 보호하거나 특정 시스템을 주 네트워크에서 링 펜싱하기 위해 특별한 주의가 필요할 수 있는 보안 취약성을 나타낼 수 있습니다. 레거시 애플리케이션은 시스템 재구축이 설치 CD/DVD와 같은 원본 애플리케이션 미디어의 가용성과 애플리케이션을 최신 버전으로 전환하는 데 필요한 후속 패치 파일에 의존할 수 있기 때문에 DR 시나리오에서 추가적인 문제를 야기할 수 있습니다. 이는 기본 레거시 운영 체제에도 동일하게 적용됩니다. 이러한 이유로 시스템 복구 소프트웨어 및/또는 시스템 복제를 사용하는 것은 재해 발생 후 레거시 시스템의 복구를 보장하는 데 매우 중요할 수 있습니다. Cristie 소프트웨어는 현재 지원 종료 상태인 많은 레거시 운영 체제를 포함한 레거시 운영 체제에 대한 광범위한 지원 매트릭스를 통해 레거시 애플리케이션 보호를 간소화합니다. 최신 백업 소프트웨어 도구는 일반적으로 최신 OS 버전에 대한 지원과 함께 고객의 요구에 따라 나중에 추가된 이전 버전에 대한 지원을 제공하는 형태로 출시되므로 레거시 애플리케이션이 관련된 곳에서 사용하려는 모든 데이터 보호 도구에 대한 OS 호환성 매트릭스를 확인하는 것이 중요합니다.

컴퓨터 바이러스

컴퓨터 바이러스는 거의 항상 눈에 보이지 않습니다. 시스템과 엔드포인트 디바이스에 바이러스 백신 소프트웨어가 설치되어 있지 않으면 바이러스가 있다는 사실조차 모를 수 있습니다. 바이러스로 인한 피해는 다양할 수 있지만, 일반적으로 선택한 바이러스 백신 소프트웨어를 사용하여 바이러스를 삭제하거나 격리하면 피해를 최소화할 수 있습니다. 이 과정은 일반적으로 아래 단계의 순서를 따릅니다.

  • 모든 네트워크에서 시스템 연결 해제
  • OS 지침에 따라 시스템을 '안전 모드'로 재부팅합니다.
  • 임시 파일 삭제
  • 바이러스 검사 실행
  • 탐지된 파일을 삭제하거나 격리합니다.
  • 시스템을 다시 검사하여 추가 위협이 있는지 확인하세요.
  • 시스템을 정상 작동 상태로 재부팅합니다.
  • 모든 비밀번호 변경
  • 모든 OS, 애플리케이션, 브라우저 및 네트워크 요소에 최신 소프트웨어 업데이트가 있는지 확인합니다.
  • 시스템을 네트워크에 다시 연결

방화벽과 바이러스 백신 소프트웨어를 포함한 기존의 멀웨어 보호 시스템은 블랙리스팅이라는 보호 기법을 사용한다는 점을 이해해야 합니다. 이 접근 방식은 네트워크에 대한 액세스가 거부되어야 하는 멀웨어 코드의 보호 서명 목록을 유지하는 것을 기반으로 하며, 이는 효과적인 기술이지만 알려진 모든 멀웨어 코드를 탐지하고 격리하기 위해 정의 파일을 지속적으로 유지해야 하는 보안 소프트웨어 회사와 모든 시스템 패치 및 정의 파일을 최신 상태로 유지해야 하는 IT 직원 모두에게 시간이 많이 소요되는 기술입니다. 멀웨어 및 바이러스 페이로드는 운영 체제, 네트워크 인프라, 애플리케이션 또는 그 사이의 모든 기술 스택에서 발견된 취약점을 악용하도록 설계되었습니다. 이미 알려져 있고 악용되고 있는 보안 허점을 지속적으로 패치하는 것이 바로 블랙리스트 접근 방식의 핵심 실패 요인이며, 이것이 바로 IT 보안팀이 사이버 범죄에 항상 뒤처지는 이유입니다. 기존의 블랙리스트 접근 방식은 알려지지 않은 새로운 멀웨어 코드가 침투하여 피해를 입히기 전에 탐지되지 않고 전파되도록 허용하는 사후 대응 방식입니다. 이러한 새로운 취약점은 '제로 데이' 익스플로잇으로 알려져 있습니다. 이러한 취약점이 완화될 때까지 해커는 계속해서 취약점을 악용하여 시스템 애플리케이션, 회사 데이터 및 네트워크의 추가 컴퓨터에 악영향을 미칠 수 있습니다.

사이버 공격

사이버 공격은 개인 또는 해커 팀이 수동으로 개입하여 회사의 네트워크, 시스템, 인프라 및 데이터에 대한 조직적인 공격입니다. 공격자의 목표는 일반적으로 운영에 필요한 시스템과 데이터를 잠그거나 암호화하여 중요한 비즈니스 시스템을 마비시키는 것입니다. 그런 다음 돈을 지불하면 암호 해독 키를 제공한다는 전제하에 몸값을 요구합니다. 최근의 공격 추세는 이러한 정보를 공개적으로 유출하거나 다크 웹을 통해 판매하겠다는 위협으로 회사 기밀 정보 및 개인 식별 정보(PII)를 추가로 유출하는 것입니다. 사이버 공격은 앞서 설명한 대로 컴퓨터 바이러스(멀웨어 코드)의 전달을 통해 시작되는 경우가 많습니다. 이 바이러스는 일반적으로 피싱 이메일을 통해 전달되며, 수신자가 악성 코드가 포함된 첨부파일을 컴퓨터나 디바이스에 다운로드하도록 속입니다. 그런 다음 멀웨어 코드는 IT 네트워크에 백도어를 설정하고 해커에게 진입 경로가 생성되었음을 보고합니다. 또는 해커는 스위치 및 라우터, 컴퓨터 운영 체제, 탐지되지 않은 게이트웨이를 제공할 수 있는 네트워크 연결 장치 등 기업 네트워크의 요소 내에서 이전에 알려지지 않은(제로데이) 취약점을 악용할 수 있습니다.

통신 중단

일부 기업은 여전히 PBX(사설 교환기)로 응답하지만, 많은 기업은 인터넷 기반 VoIP(인터넷 프로토콜을 통한 음성 통화) 또는 클라우드 기반 통합 커뮤니케이션 서비스 플랫폼(UCaaS)을 선택했습니다. 정전이나 네트워크 중단이 통신 시스템에 영향을 미칠 수 있는 것은 분명하지만, 사이버 공격으로 인해 기업의 통신 인프라가 작동 불능 상태가 되는 경우도 드물지 않습니다. 기존 PBX를 버리고 클라우드 기반 PBX로 전환한 기업은 이러한 시스템이 제공하는 기본 제공 이중화 기능 덕분에 통신 가용성 측면에서 훨씬 더 나은 위치에 있습니다. 그럼에도 불구하고 기업은 재해 발생 시 최소한 내부적으로 소통할 수 있는 대체 커뮤니케이션 플랫폼을 준비하는 것이 중요합니다. 고려할 수 있는 옵션은 매우 다양하며, 그 중 대부분은 일상적인 비즈니스 커뮤니케이션에서 매우 인기가 있는 Microsoft Teams, Skype, Zoom, 심지어 WhatsApp 및 메타 플랫폼 메신저(이전의 Facebook)와 같은 소셜 플랫폼입니다. 최소한 주요 직원의 대체 연락처 정보는 DRP의 명령 체계 섹션에 문서화해야 합니다.

"2021년 2월, 텍사스주는 미국 전역을 휩쓴 세 차례의 심각한 겨울 폭풍으로 인해 심각한 전력 위기를 겪었습니다.이 폭풍으로 인한 피해는 최소 1,950억 달러로 추정되며, 이는 주 역사상 가장 비싼 재난일 가능성이 높습니다6. "

3. DR 계획 문서 만들기

DR 플랜이란 무엇인가요?

재해 복구 계획은 조직이 IT 인프라에 중대한 장애가 발생했을 때 복구하는 데 사용하는 절차와 리소스를 문서화합니다. 재해 복구 계획은 조직의 기존 자산과 복구 목표에 따라 다양한 도구를 사용할 수 있습니다. DR 계획에는 일반적으로 다음과 같은 매개변수가 포함됩니다:

  • 중요 시스템 및 애플리케이션 감사
  • 각 비즈니스 프로세스에 대한 복구 지점 목표(RPO).
  • 각 비즈니스 프로세스에 대한 복구 시간 목표(RTO).
  • 데이터 백업 및 복제 사이트의 위치. 가장 중요한 시스템과 데이터의 보조 오프사이트 백업 또는 복제본을 만드는 것은 모든 재해 복구 솔루션의 핵심 부분입니다.
  • 지휘 체계/책임 차트. 재해 복구 계획을 실행할 책임이 있는 사람 목록입니다. 역할과 책임이 할당되어 있으면 계획을 신속하고 일관성 있게 따르고 시행하기가 더 쉬워집니다.
  • DR 테스트 계획. DR 계획은 복구 절차가 작동하는지 확인하고 실제 비상 상황에서 RTO, RPO 및 SLA를 충족할 수 있는지 확인하기 위해 빈번한 테스트가 필요합니다.

DR 계획 준비의 일반적인 단계

아래 단계는 강력한 DR 계획을 개발하기 위해 일반적으로 수행해야 하는 작업의 개략적인 개요입니다.

1단계: IT 리소스 감사 완료

감사는 가능한 한 많은 세부 정보를 포함하여 모든 업무상 중요한 시스템에 대해 수행되어야 합니다. 정보에는 머신 및 스토리지 용량 사양, OS 버전, 설치된 애플리케이션 및 버전, 머신 위치와 같은 항목이 포함되어야 합니다. 서버 외에도 토폴로지 다이어그램과 중요한 구성 매개변수에 대한 세부 정보를 포함한 기업 네트워크 구성 요소도 소홀히 하지 않는 것이 중요합니다. 직원의 모바일 기기 및 노트북과 같은 기업 엔드포인트 장치도 포함되어야 합니다. 네트워크에 있는 모든 IT 리소스와 각 리소스에 어떤 애플리케이션과 데이터가 있는지 인벤토리를 작성하면 향후 백업과 복구를 더 쉽게 할 수 있도록 모든 것을 통합하고 간소화하기 시작할 수 있습니다.

2단계: 2단계: 미션 크리티컬 시스템의 계층 구조 결정하기

DR 계획은 비즈니스 프로세스를 자세히 살펴보고 운영 유지에 중요한 요소를 진정으로 결정할 수 있는 좋은 기회를 제공합니다. 비즈니스 운영 유지에 중요하지 않은 많은 중복 데이터를 포함하여 예상보다 훨씬 많은 데이터를 처리하고 저장하고 있을 가능성이 높습니다. IT 리소스 감사 중에 중요하지 않으므로 백업 리소스를 소비할 가치가 없는 데이터 세트를 여러 개 발견할 수 있습니다. 어떤 시스템과 애플리케이션이 미션 크리티컬한지 결정하려면 다운타임 비용 분석을 통해 어떤 RTO/RPO와 데이터 보호 방법을 사용해야 할지 결정해야 합니다.

3단계 3단계: 역할 및 책임 설정

조직의 모든 직원은 재해 복구 계획에서 각자의 역할을 수행해야 합니다. 사이버 보안 취약점을 연차가 높거나 DR 계획 수립에 대한 노하우가 있는 사람에게 보고하는 것 같은 간단한 일도 매우 중요할 수 있습니다. 역할과 책임에 대한 명확한 문서화 목록이 있으면 DR 계획이 훨씬 더 효과적입니다.

4단계: 복구 목표 정의

가장 중요한 시스템에 대한 복구 목표를 결정한 다음 이 수치를 모든 복구 목표의 최저 공통 분모로 적용하는 함정에 빠지기 쉽습니다. 시스템에 지나치게 야심찬 RTO/RPO 목표를 설정하면 내부 팀에 불필요한 부담을 주게 되어 전체 복구 프로세스에 해가 될 수 있습니다. 섹션 4와 5에서 위험 분석과 복구 유형 및 복구 목표의 적절한 선택에 대해 살펴보겠습니다.

5단계: 백업 및 복제 위치를 선택하고 문서화하기

데이터 백업 및 시스템 복제를 위한 위치를 선택할 때는 다양한 선택지가 있습니다. 이러한 위치가 외부에 있거나 타사 조직에서 관리하는 경우 주요 연락 지점을 포함한 위치 세부 정보를 계획에 포함해야 합니다. 또한 교체 하드웨어의 조달 프로세스를 계획하고 문서화해야 합니다. 복구 시스템 제공을 위해 제3자를 이용하는 경우 장비 제공에 소요되는 리드 타임과 많은 기업에 영향을 미치는 주 전역의 이벤트 발생 시 고객 할당 우선순위에 대해 질문해야 합니다. 특히 하드웨어가 충분한지, 선착순으로 할당되는지, 아니면 다른 고객 등급 구조에 따라 할당되는지 등을 문의해야 합니다.

6단계: DR 테스트 계획 개발 및 문서화

"백업을 믿는 것과 백업을 사용하는 것은 별개입니다. 백업을 사용해야 하는 것은 또 다른 문제입니다. 복구를 테스트하지 않았다면 실제로 백업이 없는 것입니다." DR 절차를 진정으로 테스트하는 것의 중요성은 아무리 강조해도 지나치지 않습니다. 자동화가 없는 테스트는 어렵고 시간이 많이 소요되는 작업이며, 많은 기업이 복구 절차를 정기적으로 테스트하지 않는 주요 이유이기도 합니다. 섹션 6과 7에서 DR 테스트에 대해 자세히 살펴봅니다.

4. 복구 옵션 선택

조직과 관련이 있고 중요한 것으로 확인된 각 위험 유형에 대해 적절한 복구 전략이 필요합니다. RPO는 재해 발생 시 중요한 데이터를 복구하는 데 필요한 데이터 백업 빈도를 결정하는 데 사용되는 핵심 요소입니다. 트랜잭션 무결성이 매우 중요한 시스템에는 장애 조치-장애 복구 쌍으로 작동하거나 다중 노드 클러스터 구성의 일부로 작동하는 CDP(지속적 데이터 보호)가 있는 복제된 시스템이 필요한 경우가 많습니다. 따라서 비즈니스 프로세스 아키텍처 내의 각 시스템에 대해 DRP는 시스템 복구를 최근 백업에서 파일을 복원하여 수행할지, 아니면 라이브 DR 환경 내에서 실행 중인 복제된 시스템으로 서비스를 전송하여 수행할지 지정해야 합니다. 시스템 복구에 백업에서 복원이 포함되는 경우, 원래 시스템을 복구 및 재구축할지 아니면 운영 체제, 애플리케이션 및 데이터를 다른 플랫폼으로 복원할지 여부를 추가로 선택해야 합니다. 후자를 선택할 경우 이 섹션의 뒷부분에서 다루게 될 추가적인 구체적인 문제가 발생합니다.

백업과 복제 - 주요 차이점 및 사용 시나리오

백업과 복제라는 용어에 대해 약간의 혼란이 있을 수 있습니다. 이 두 용어는 종종 상호 교환 가능한 용어로 사용되거나 DRP 내에서 둘 중 하나 또는 둘 중 하나의 접근 방식으로 간주되기도 합니다. 백업과 복구, 복제는 모두 완벽한 재해 복구 계획의 중요한 부분입니다. 각각은 시스템을 보호하는 데 중요한 역할을 하지만 그 역할은 서로 다릅니다. 먼저 재해 복구 계획의 일부로서 백업의 역할을 살펴보겠습니다.

백업의 중요성

백업은 데이터를 장기간 일관되게 백업할 수 있도록 설계되었습니다. 백업은 서버 장애 발생 후 가장 최근의 백업에서 복구하거나 실수로 삭제된 단일 파일을 세분화하여 복구하는 데 사용할 수 있습니다. 규정 준수 목표를 달성하기 위해 백업을 장기적으로 배포할 수도 있습니다. 기본적으로 백업은 최후의 방어선이며, 복구 지점과 복구 시간 간의 균형을 맞추는 데 중점을 둡니다. 또한 백업을 프로덕션 환경으로부터 에어 갭(격리)하여 악성 소프트웨어로부터 시스템을 더욱 안전하게 보호할 수 있습니다. 사이버 범죄자들은 랜섬웨어 방어에 있어 백업이 중요하다는 것을 알고 있기 때문에 랜섬웨어를 요구하기 전에 백업을 먼저 표적으로 삼고 손상시키는 경우가 많습니다. 따라서 변경되지 않는 격리 백업은 이제 많은 사이버 보안 전략의 핵심 부분이 되고 있습니다. 비즈니스 애플리케이션을 기억해야 할 핵심 포인트는 손상된 시스템을 완전히 재구축하고 다시 프로비저닝하는 데 필요한 전체 운영 체제 및 디스크 스토리지 인프라 정보가 포함되어 있지 않다는 점입니다.

복제 소개

백업 및 복구 소프트웨어는 일반적으로 시스템과 데이터를 신속하게 복구할 수 있지만, 프로세스의 일부로 복제를 사용하는 것에 비해 일반적으로 RTO가 느려집니다. 이는 애플리케이션과 데이터를 복원하기 전에 먼저 시스템을 프로비저닝해야 하기 때문에 시간이 오래 걸리기 때문입니다.

복제 소프트웨어

복제 소프트웨어는 전체 시스템 구성을 포함할 수 있는 비즈니스 크리티컬 시스템의 라이브 사본을 생성하고, 이 데이터를 기본 프로덕션 시스템과 해당 시스템의 보조 사본 간에 정기적으로 동기화합니다. 재해가 발생하면 기본 복사본에서 실행 중인 비즈니스를 보조 복사본으로 신속하게 이전할 수 있으며, 이를 페일오버라고 합니다. 이렇게 하면 두 시스템 간의 동기화가 전체 백업, 즉 RPO보다 훨씬 더 자주 이루어질 가능성이 높으므로 비즈니스 다운타임(RTO)과 잠재적인 데이터 손실을 최소화할 수 있습니다. 시스템 장애 조치 및 장애 복구를 자동화하여 시스템 다운타임을 더욱 줄일 수 있으며, 대부분의 경우 시스템 사용자가 중단을 인지할 수 없을 정도로 0에 가까운 RTO를 달성할 수 있습니다. Cristie 복구 소프트웨어는 Cristie 가상 어플라이언스(VA) 소프트웨어 구성을 통해 장애를 감지하고 페일오버/페일백 자동화를 제공할 수 있습니다. 기본적으로 복제는 백업에서 보조 시스템을 복구하는 동안 비즈니스 연속성과 재해가 비즈니스에 미치는 영향을 최소화하는 데 더 중점을 둡니다.

Cristie CloneManager™ 소프트웨어

Cristie CloneManager 소프트웨어는 비즈니스 크리티컬 머신의 동기화된 복제본을 생성하여 DR 시나리오에서 다운타임과 비즈니스에 미치는 영향을 최소화하면서 비즈니스를 계속 운영할 수 있도록 합니다. 동기화는 사용자 정의 일정에 따라 설정할 수 있어 두 시스템 간의 데이터 손실 또는 RPO를 몇 분 단위로 낮출 수 있습니다. 또한, 자동 페일오버 및 페일백 등의 기능을 통해 페일오버 프로세스를 자동화하고 RTO와 비즈니스 다운타임을 더욱 줄일 수 있습니다. 향상된 테스트 기능을 통해 동기화 프로세스에 영향을 주지 않고 프로덕션 환경에서 벗어나 복제된 사본을 테스트할 수 있으므로 재해 복구 계획에 대한 확신을 가질 수 있습니다.

공급업체 종속을 방지하기 위한 복제 이동성 유지

가상화 기술과 클라우드 컴퓨팅의 등장으로 조직은 시스템 복제를 위한 대상 플랫폼을 선택할 때 다양한 선택의 폭을 갖게 되었습니다. 더 이상 물리적 시스템을 DR 위치 내에서 실행 중인 유사한 물리적 시스템으로 복제할 필요가 없습니다. 고성능 컴퓨팅이 필요한 경우에는 물리적 시스템 간 복제가 필수적일 수 있습니다. 그러나 대부분의 경우 재해 복구를 위해 물리적 시스템을 가상 또는 클라우드 타깃으로 복제하는 것은 이제 매우 실용적인 옵션이며, 많은 조직에서 표준 관행이 되고 있습니다. 가상 또는 클라우드 기반 복제 대상을 구성한 다음 여러 머신에 대한 복제 작업을 관리하는 작업은 어려운 작업으로 보일 수 있습니다. 많은 클라우드 백업 및 복제 서비스 공급업체는 가상 클라우드 환경으로 시스템을 복제하는 온보딩 프로세스를 지원하는 마이그레이션 및 복제 도구를 무료로 제공합니다. 언뜻 보기에는 매우 유용한 기능으로 보일 수 있습니다. 단점은 제공되는 도구가 일반적으로 공급업체의 특정 클라우드 환경으로만 시스템을 복제하도록 설계되었기 때문에 복제 이동성이라는 측면에서 이러한 도구 중 상당수가 단방향적이라는 점입니다. 물론 공급업체의 입장에서는 고객을 유치하고 유지하는 데 관심이 있기 때문에 고객에게 공급업체 종속 시나리오를 만들 수 있는 단점이 있습니다. 최대한의 보호와 클라우드 공급업체 선택의 자유를 보장하려면 DRP는 완전한 복제 이동성을 달성하기 위해 노력해야 하며, 이는 DR 인프라가 클라우드 공급업체 선택에 대한 완전한 독립성과 함께 물리적, 가상, 클라우드 타깃으로 중요한 시스템을 어느 방향으로든 복제할 수 있어야 한다는 것을 의미합니다. Cristie VA는 이러한 기능을 제공하여 공급업체와 플랫폼 유형 간에 DR 시스템을 완전히 자유롭게 이동할 수 있습니다.

온프레미스, 클라우드, 코로케이션 또는 하이브리드 복제 대상 선택

온프레미스

온프레미스 시스템 복제의 가장 큰 장점은 아마도 데이터 보호일 것입니다. 데이터가 사내에 로컬로 저장되므로 데이터와 보안을 완벽하게 제어할 수 있습니다. 민감한 데이터가 회사를 떠날 필요가 없으므로 특히 규정 준수 문제와 데이터 주권 보장에 있어 결정적인 이점이 될 수 있습니다. 또 다른 주요 이점은 성능입니다. 오프사이트 복제 솔루션의 복구 성능은 코로케이션 또는 클라우드 제공업체와의 인터넷, SD-WAN 또는 MPLS 연결에 의해 좌우되며, 경우에 따라서는 온프레미스 시스템 복제의 가장 큰 장점인 데이터 보호보다 훨씬 낮을 수 있습니다. 데이터가 사내에 로컬로 저장되므로 데이터와 보안을 완벽하게 제어할 수 있습니다. 민감한 데이터가 회사를 떠날 필요가 없으므로 특히 규정 준수 문제와 데이터 주권 보장에 있어 결정적인 이점이 될 수 있습니다. 또 다른 주요 이점은 성능입니다. 오프사이트 복제 솔루션의 복구 성능은 코로케이션 또는 클라우드 제공업체에 연결된 인터넷, SD-WAN 또는 MPLS 연결에 의해 결정되며, 경우에 따라 내부 네트워크에서 사용할 수 있는 성능보다 훨씬 낮을 수 있습니다. 또한 내부 네트워크는 언제든지 액세스할 수 있어야 하며, 인터넷 연결 상태에 관계없이 시스템이 복제되도록 해야 합니다. 또한 백업 및 복제를 위해 인터넷이나 클라우드 기반 서비스에 의존하지 않는 비즈니스의 경우 이러한 고속 연결에 대한 비용을 지불할 필요가 없어 월 인터넷 비용을 절감할 수 있습니다. 앞서 설명한 바와 같이, 온프레미스 DR 솔루션을 선택할 때는 지역 또는 자연 재해 발생 시 생산 시스템과의 근접성에 따른 위험을 신중하게 고려해야 합니다.

장점

  • 손쉬운 액세스 및 배포 유연성
  • 데이터 보안 및 데이터 주권에 대한 완벽한 제어
  • 시스템 및 네트워크 성능 이점
  • 잠재적으로 인터넷 비용 절감

단점

  • 설비 투자 비용
  • 관리 오버헤드
  • 유지 관리 비용
  • 자연재해 또는 기타 지역 재해 시나리오에 취약함

코로케이션

여러 고객을 위해 가동 시간의 안정성을 보장하기 위해 특별히 설계된 센터입니다. 코로케이션 데이터 센터는 보안 케이지와 프라이빗 스위트가 있는 공간을 임대하여 기업의 물리적 IT 자산을 유지 관리할 수 있는 이상적인 IT 환경을 제공합니다. 적합한 코로케이션 제공업체를 찾으면 통신사 중립적인 네트워크 연결, 하이브리드 연결을 위한 클라우드 온보딩, 견고한 네트워크 인프라를 통한 멀티 클라우드 연결 등의 측면에서 엄청난 이점을 얻을 수 있습니다. 대부분의 경우 코로케이션 데이터센터는 초기 설정 비용이 일반적으로 더 높지만 온프레미스 솔루션보다 단점이 적고 총비용이 낮은 우수한 IT 솔루션을 고객에게 제공할 수 있습니다. 각 고객은 특정 장단점이 있는 자체 시스템을 사용하고 있습니다. 데이터센터의 소유자가 아니므로 특정 기간 동안 액세스를 제한할 수 있는 테넌시에 적용되는 특정 규정을 따라야 할 수도 있습니다. 장비 유지보수를 수행하려면 코로케이션 데이터센터 위치를 방문해야 하므로 액세스 규정을 이해하고 이러한 요구 사항이 비즈니스의 요구 사항을 충족하는지 확인하는 것이 중요합니다. 대부분의 경우, 입주자는 유지보수 및 운영 작업을 위해 컨시어지 서비스와 코로케이션 시설의 사내 IT 전문가를 활용하여 불필요한 데이터센터 방문을 피할 수 있습니다. 전반적으로 중견 및 대기업 비즈니스의 경우 코로케이션의 이점이 초기 설정 비용보다 크므로 성능과 경제성을 적절히 조합할 수 있습니다. 특히 선택한 파트너가 배포와 관련된 모든 문제를 해결하기 위해 고도의 고객 서비스를 제공할 수 있는 경우 더욱 그렇습니다.

장점

  • 시간 및 비용 절감. 
  • 추가 서버 및 인프라 시설 필요 없음
  • 전체 IT 관리 비용 절감
  • 전력 용량 문제 방지
  • 광범위한 연결성
  • 유연성
  • 물리적 및 사이버 보안 강화

단점

  • 초기 비용이 더 높습니다.
  • 설비 투자 비용
  • 통제력 저하 가능성
  • 시간 또는 리소스와 관련된 유지 관리 제한 사항
  • 근접성, 가격, 서비스 측면에서 적합한 제공업체 찾기

하이브리드

클라우드 컴퓨팅은 매우 잘 확립되어 있지만 많은 기업이 여전히 시스템과 데이터를 이 환경으로 마이그레이션하는 것을 두려워하고 있습니다. 가장 자주 우려하는 부분은 정보의 기밀성, 서비스 품질, 마이그레이션 후 비즈니스 애플리케이션의 성능입니다. 하이브리드 IT 인프라를 구축하면 '두 가지 장점을 모두 갖춘' 솔루션으로 이러한 우려를 해소할 수 있으며, 기업은 퍼블릭 클라우드로 이전할 항목과 온프레미스에 유지할 항목을 선택하고, 어떤 클라우드 백업 및 복제 서비스를 어떤 용도로 사용할지 결정할 수 있습니다. 또한, 기업은 이 아키텍처에 퍼블릭 클라우드 서비스의 모든 확장성을 제공하지만 회사 전용이며 회사에서만 액세스할 수 있는 내부 클라우드 컴퓨팅 환경인 프라이빗 클라우드를 포함할 수 있습니다. 온프레미스, 퍼블릭 및 프라이빗 클라우드 인프라는 모두 독립적으로 작동하거나 필요에 따라 연결할 수 있습니다. 예를 들어, 강력한 보안 요구 사항이나 규정 준수가 필요한 중요한 워크로드는 프라이빗 클라우드에 복제하고 덜 중요한 프로세스는 퍼블릭 클라우드 서비스를 활용할 수 있습니다. 이를 통해 기업은 인프라와 DR 애플리케이션 스택을 완벽하게 제어할 수 있습니다.

장점

  • 유연성
  • 확장성 및 배포
  •  이동성 향상
  • 데이터 보안 강화

단점

  • 구현하기 어려움
  • 퍼블릭 클라우드보다 비싸다
  • 비공개 플랫폼과 공용 플랫폼 간의 파일 호환성
  • 정보에 대한 가시성 손실 가능성

복제 대상 유형

물리적 머신

물리적 컴퓨터에서 실행되는 운영 체제는 시스템 보드에서 사용되는 주변 장치에 특정한 드라이버를 통해 기본 하드웨어에 긴밀하게 연결됩니다. 예를 들어 스토리지 컨트롤러, 그래픽 어댑터, 네트워크 어댑터 등이 있습니다. 물리적 복제 대상 시스템이 원래 소스 시스템과 동일하지 않으면 하나 이상의 부팅에 중요한 시스템 수준 드라이버의 불일치로 인해 시스템 복제 이미지가 대상 시스템에서 부팅되지 않을 수 있습니다. 이는 많은 IT 시스템 관리자에게 익숙한 상황으로, 애플리케이션과 데이터에 액세스하기 전에 대상 시스템을 부팅 준비 상태로 프로비저닝하는 데 어느 정도 어려움과 시간이 소요됩니다.

서로 다른 하드웨어로 복구하는 골치 아픈 문제 극복하기

반면, Cristie 복구 소프트웨어를 사용하면 전체 시스템을 하드웨어, 가상 또는 클라우드 플랫폼으로 복구할 수 있는 간편한 도구를 제공합니다. 저희 소프트웨어는 백업과 함께 저장되는 시스템 구성 파일을 생성합니다. 이 구성 파일에는 유사한 대상에서 복구를 준비하는 데 필요한 모든 정보가 포함되어 있습니다. 특정 시점의 복구를 포함하여 한 번에 원본 시스템의 복제본으로 시스템을 복구할 수 있습니다. 즉, 필요한 모든 것이 백업에 포함되어 있으므로 소프트웨어를 찾느라 시간을 낭비할 필요가 없습니다. 다른 하드웨어로 복구하는 경우, 대상 복구 시스템의 초기 부팅 전에 새 드라이버 주입을 자동으로 처리합니다. 마찬가지로 가상 또는 클라우드 환경으로 복구하는 경우, 원래 물리적 시스템에서 사용 가능했던 것과 동일한 CPU, RAM 및 디스크를 사용하여 가상 머신을 완전히 자동화할 수 있습니다.

가상 머신(VM) 실행

가상 머신(VM)은 일반적으로 단일 컴퓨터에서 실행되는 별도의 운영 체제(OS) 설치를 의미하며, 각 OS는 컴퓨터의 시스템 리소스를 할당받습니다. 예를 들어, Windows PC 위에 Linux VM을 설치할 수 있습니다. 컴퓨터의 하드웨어가 충분히 강력하다면 동일한 물리적 컴퓨터에서 여러 개의 OS를 동시에 설치할 수 있습니다. 따라서 VM은 데스크톱 및 서버 환경을 확장하는 편리한 방법입니다. VM의 다른 이점으로는 간단하고 빠른 프로비저닝, 고가용성, 뛰어난 확장성 등이 있습니다. DR 관점에서 볼 때 VM을 매력적인 복제 대상으로 만드는 것은 신속한 프로비저닝과 확장성입니다. Cristie 가상 어플라이언스(VA)를 통해 물리적 또는 클라우드 소스에서 가상 머신으로 시스템을 복제하거나 복구할 수 있으며, 프로비저닝 중에 VM 리소스를 소스 시스템과 일치하도록 확장하거나 특정 리소스를 상향 또는 하향 수정하는 옵션이 있습니다. 예를 들어, 정상적인 프로덕션 환경으로 장애 복구할 때까지 일시적인 상황이므로 비용을 절감하기 위해 시스템 장애 조치 중에 약간 낮은 성능을 감수하고 DR 목적으로 소스 머신보다 시스템 리소스가 낮은 실행 중인 VM에 복제할 수 있습니다.

가상 디스크 이미지 파일

지금까지 시스템 장애 또는 재해 시나리오가 발생할 경우 주 시스템에서 즉시 인수할 준비가 되어 있는 실행 중인 시스템을 '온라인' 타깃이라고 하는 복제 대상에 대해 설명했습니다. '온라인' 복제 대상의 장점은 실행할 준비가 되어 있고 작업을 매우 빠르게 인수인계할 수 있다는 것입니다. 단점은 사고 발생을 기다리는 동안 물리적 또는 가상 컴퓨팅 리소스를 지속적으로 소비한다는 것입니다. 이러한 오버헤드를 극복하기 위해 가상 디스크 이미지 파일 형태로 대기 머신을 유지하는 대안이 존재합니다. 가상 머신은 물리적 머신의 시스템 드라이브를 단일 디스크 이미지로 캡처하는 것과 같은 방식으로 완전한 이미지로 캡처할 수 있습니다. 이미지 파일에는 OS 구성, 애플리케이션, 모든 데이터를 포함한 모든 것이 포함됩니다. 시스템 복제는 실행 중인 머신이 아닌 프라이빗 또는 퍼블릭 클라우드 환경 내에 저장된 가상 디스크 이미지 파일로 수행할 수 있습니다. 이러한 이미지 파일을 유지 관리하는 데 스토리지와 컴퓨팅 리소스가 아닌 클라우드 스토리지 비용만 필요하므로 비용 면에서 상당한 이점이 있습니다. 단점은 실행 중인 머신보다 온라인 전환 속도가 느리다는 것이지만, 많은 DR 시나리오에서 제공하는 RTO로 충분합니다. Cristie 복제 솔루션은 온라인 및 오프라인 복제 기능을 모두 제공하며 .vhdx, .qcow2, .vmdk 파일 형식을 포함한 모든 일반적인 시스템 이미지 표준을 Cristie VA를 통해 지원합니다.

5. 애플리케이션의 복구 우선순위 식별

복구 우선 순위(공유 서비스 및 인프라스트럭처)

강력한 DRP는 기본 기업 네트워크의 중요성을 간과해서는 안 됩니다. 인프라 내에서 데이터를 이동하는 데 네트워크 서비스를 사용할 수 없다면 조직은 제대로 기능할 수 없습니다. 따라서 네트워크 서비스의 중요성을 과소평가해서는 안 되며, 견고한 DRP에는 네트워크 재해 복구 계획도 포함되어야 하고 네트워크 장애 위험을 줄이는 방법도 포함되어야 합니다. IT 인프라가 고정된 하드웨어 중심 토폴로지에서 소프트웨어 정의 아키텍처로 계속 이동함에 따라 네트워크 프로필은 인프라 재해 발생 후 네트워크 장치를 구성하기 위한 초기 매개변수 및 설정을 포함한 네트워크 구성 파일을 포함하는 정기 백업 세트의 일부로 더 쉽게 구성할 수 있습니다.

복구할 애플리케이션 그룹의 우선 순위

DRP의 핵심은 비즈니스 프로세스 애플리케이션에 대한 복구 우선순위 목록입니다. 재해 복구 계획자는 계층적 접근 방식을 취함으로써 복구 프로세스를 구성하여 다운타임을 줄이고 우선순위가 높은 시스템을 보호할 수 있습니다. 개념적으로 '다운타임 비용' 분석 단계에서 계산된 복구 지점 목표(RPO)와 복구 시간 목표(RTO)는 애플리케이션 복구 우선순위를 결정하기 위한 좋은 출발점이 될 수 있습니다.

애플리케이션 그룹 내에서 복구할 시스템 순서

분명히 많은 애플리케이션이 다른 애플리케이션에 종속되어 있으므로 복구 우선순위 목록에는 비즈니스 프로세스 운영이 병목 현상 없이 원활하게 진행될 수 있도록 특정 순서대로 복구하고 온라인 상태로 전환해야 하는 애플리케이션 그룹이 포함될 가능성이 높습니다. 가장 먼저 복구해야 할 시스템 및 애플리케이션 그룹에는 컴퓨터 네트워크의 각 도메인에서 보안 인증 요청에 응답하고 사용자를 확인하는 데 필요한 도메인 컨트롤러와 같은 기본 인프라 서버가 포함될 가능성이 높습니다. 이 컨트롤러는 모든 도메인 리소스에 대한 호스트 액세스를 허용하는 게이트키퍼 역할을 합니다.

6. 수동 또는 자동 복구?

수동으로 복구해야 하나요?

견고한 DRP가 구축되어 있다면 다행입니다. 하지만 시스템을 수동으로 복구하려는 경우 프로세스가 생각보다 훨씬 더 복잡할 수 있습니다. 시스템을 수동으로 복구하는 것이 불가능한 것은 아니지만 운영 체제, 애플리케이션, 네트워크 및 스토리지를 관리하는 데 있어 특정 기술이 필요하고 많은 시간이 소요됩니다. 일반적으로 애플리케이션이 있는 서버를 완전히 수동으로 재구축하려면 데이터 복구에 필요한 시간 외에 2시간에서 8시간이 소요됩니다. 게다가 수동 복구는 계획되지 않은 경우가 많기 때문에 이미 스트레스가 많은 상황에서 시간에 쫓기며 작업하게 됩니다. 수동 복구 프로세스를 단계별로 살펴보겠습니다.

  • 시작하려면 설치할 시스템(물리적, 가상 또는 클라우드)을 식별해야 합니다. 가상 또는 클라우드인 경우 애플리케이션의 설치 미디어를 찾기 전에 수동으로 가상 머신을 생성하고, OS를 수동으로 설치하고, 패치 업데이트를 실행해야 한다는 점에 유의하세요. 
  • 그런 다음 복구 소프트웨어 및 기타 프로그램과 애플리케이션을 설치하기 전에 이러한 애플리케이션 버전이 설치된 OS 버전에서 작동하는지 확인해야 합니다. 마지막으로 데이터 복원을 시작할 수 있습니다.
  • 다음으로 머신 이름과 IP 주소 정보를 변경해야 다시 실행할 수 있지만, 그 이후에 더 이상 문제가 발생하지 않는다는 보장은 없습니다.

자동화 또는 오케스트레이션 제품이 필요한가요?

수동 복구는 복잡하고 시간이 많이 걸리는 작업입니다. 복구 자동화 및 오케스트레이션을 제공하는 전용 베어 머신 복구 소프트웨어로 복구하는 데 필요한 10~15분과 비교하면 "예"라는 대답에 동의하실 것입니다.

7. 작동 여부

"Storage Magazine에 따르면 34% 이상의 기업이 백업을 테스트하지 않으며, 테스트한 기업 중 77%가 테이프 백업이 복구에 실패한 것으로 나타났습니다."Microsoft에 따르면 지난 1년간 테이프 백업에서 시도한 복구 중 42%가 실패했습니다."워싱턴의 국립 기록 보관소에서 실시한 연구에 따르면 "재해로 인해 10일 이상 데이터 센터를 잃은 기업의 93%가 재해 후 1년 이내에 파산을 신청했다"고 결론을 내렸습니다. 백업 세트에 대한 적절한 테스트가 없다면 재해가 발생했을 때 조직에 치명적인 결과를 초래할 수 있습니다.

백업 복구를 정기적으로 테스트하는 것은 세 가지 이유로 중요한데, 첫째는 문제를 미리 파악하고, 둘째는 문제를 해결하고, 마지막으로 백업에 대한 신뢰를 구축하여 실제로 백업이 필요할 때 신속하고 효율적으로 복구하여 RPO와 RTO를 충족할 수 있도록 하기 위해서입니다. 백업 또는 복구 프로세스에서 문제를 발견하는 최악의 시기는 실제 재해가 발생했을 때이며, 비즈니스를 복구하고 운영하기 위해 백업에 가장 많이 의존하고 있을 때입니다. 재해 중에 문제가 발생하면 복구가 지연될 뿐만 아니라 시스템을 완전히 복구할 수 없게 될 수도 있습니다. 안타깝게도 서버를 정기적으로 수동으로 테스트하는 것은 시간이 많이 걸리는 작업이며, 특히 전체 데이터 센터에서 테스트하려는 경우 더욱 그렇습니다. 따라서 Cristie 소프트웨어에는 모든 시스템 복구 고객을 위한 자동 복구 테스트 기능이 라이선스의 일부로 포함되어 있습니다.

테스트를 자동화해야 하나요?

수동 복구 테스트를 고려하고 있다면 신중하게 생각하세요. 수동 테스트는 가장 중요한 시스템만 효과적으로 테스트할 수 있는 경우가 많습니다. 타사 소프트웨어를 사용하시나요? 저희는 타사 소프트웨어를 사용하여 테스트를 실행하는 많은 고객과 이야기를 나눴습니다. 때로는 시스템의 샘플만 테스트하는 경우도 있으며, 그 샘플이 10~20%에 불과한 경우도 많습니다. 그런 다음 이 샘플을 사용하여 백업 상태에 대한 일반화된 그림을 구축하는데, 이 그림이 반드시 현실을 반영하는 것은 아닙니다. 복구 테스트에 Cristie 소프트웨어를 사용하면 프로세스가 자동화되고 예약됩니다. 이를 통해 고객은 전체 서버 자산을 테스트하고 재해 발생 후 모든 시스템을 복구할 수 있다는 확신을 가질 수 있습니다.

DR 오케스트레이션(수동 개입을 피하는 작업 자동화)

DR 오케스트레이션은 중단 시 서버 환경을 질서 있게 복구하여 중요한 서버, 애플리케이션, 데이터를 사고 없이 자동화된 방식으로 온라인 상태로 전환하는 데 도움을 줄 수 있습니다. Cristie DR 오케스트레이션은 자동 복구보다 한 단계 더 나아가 서버 재해 발생 후 비즈니스 크리티컬 시스템을 백업하고 실행하는 데 필요한 모든 단계를 미리 계획하고 구성할 수 있는 기능을 제공합니다. DR 오케스트레이션은 Cristie 가상 어플라이언스(VA)의 부가 가치 기능 중 하나로 포함되어 있습니다. VA와 DR 오케스트레이션은 모든 시스템 복구 및 복제 고객이 무료로 사용할 수 있습니다.

오케스트레이션 작동 방식

각 오케스트레이션 작업은 일련의 단계를 거쳐 실행되며, 각 단계 내에서 원하는 만큼 다양한 작업을 병렬로 실행할 수 있습니다. 예를 들어, 복제 또는 복구 작업(IBM Spectrum Protect, Dell Networker/Avamar 또는 Cohesity 백업 서버에서 바로 복구), 재부팅, 스크립트 및 오케스트레이션 작업에 대한 자세한 요약을 제공하는 보고 작업을 실행할 수 있습니다. 테이프 드라이브 로딩과 같은 수동 작업을 추가하여 해당 작업이 수행되는 동안 자동화를 중지한 후 작업이 완료되면 오케스트레이션을 계속하는 등의 작업도 수행할 수 있습니다.

자동화를 사용하여 시간 절약 및 DR 테스트 개선하기

이 모든 기능은 자동화를 통해 가장 중요한 순간에 시간을 절약하고, 지금까지 수작업으로 진행되던 프로세스에서 사람의 상호 작용과 인적 오류 가능성을 최소화하도록 설계되었습니다. DR 오케스트레이션을 사용하면 복구를 테스트할 수 있을 뿐만 아니라 비즈니스를 다시 가동하는 데 필요한 주변 프로세스도 테스트할 수 있으므로 DR 테스트 체계를 개선하는 데에도 사용할 수 있습니다. 시스템 재부팅, 애플리케이션 간 통합 또는 부팅 후 스크립트와 같은 주변 프로세스를 테스트할 수 있으므로 실제 DR 시나리오에서 필요하기 전에 전체 프로세스에서 문제를 미리 발견하고 수정할 수 있습니다. 즉, 실제 복구가 필요한 경우 비즈니스 크리티컬 시스템을 빠르고 쉽게 복구할 수 있다는 확신을 가질 수 있습니다.

DR 오케스트레이션 작업을 미리 예약하세요.

복구 테스트 기능과 마찬가지로 DR 오케스트레이션 작업은 몇 달 전에 미리 구성하고 예약할 수 있으며, 성공 및 실패에 대한 전체 이메일 보고를 통해 감사, 규정 준수, 업계 규정 또는 서비스 제공업체의 경우 고객에 대한 SLA 보고의 일부로 사용할 수 있습니다.

DR 복구: 일반적인 장애 시나리오

DR 복구 테스트 과정에서 많은 장애 시나리오가 드러나지만, 실제 긴급 상황의 압박감보다는 테스트 단계에서 처리하기가 훨씬 더 편합니다. 테스트 중에는 다양한 기술적 및 인적 요인으로 인한 장애가 발생하며, 다음은 소프트웨어에서 가장 자주 보고되거나 고객이 경험한 장애 중 일부입니다.

  • 잘못된 백업 파일: 종종 수정 및 교체가 필요한 손상된 백업 파일이 감지됩니다.
  • 불완전한 백업 작업: 백업 작업을 구성하는 동안 불완전한 파일/폴더 선택은 실패의 또 다른 일반적인 원인입니다. 이는 관리자의 관리 소홀 또는 부서 간 내부 커뮤니케이션이 제대로 이루어지지 않은 경우일 수 있습니다. 예를 들어, 사업부에서 새로운 애플리케이션을 요청하거나 설치할 수 있지만, 사업부와 IT 지원팀 간의 잘못된 가정으로 인해 백업에 대한 책임이 누락될 수 있습니다.
  • 호환되지 않는 하드웨어: 이는 조직이 코로케이션 또는 데이터 센터 제공업체에 베어 메탈 DR 대상을 요청하여 복구 시스템을 부팅하기 위해 다른 또는 추가 시스템 수준 드라이버가 필요한 경우의 일반적인 시나리오입니다. 이 시나리오는 Cristie 복구 소프트웨어가 자동화된 이기종 하드웨어 기술을 사용하여 많은 경우 극복할 수 있습니다.
  • 네트워크 구성: 일반적인 네트워크 구성 오류는 특히 물리적 대상과 가상 대상 간에 이동할 때 흔히 발생합니다.

규정 준수를 위한 테스트 및 보고

Cristie의 복구 테스트는 내부적으로 백업에 대한 신뢰를 구축하는 것 외에도 의료 및 금융 서비스 등의 분야에서 일반적으로 적용되는 정부 또는 업계 기반 감사 및 규정 준수 조치(예: HIPPA 및 FSA 규정)를 충족하는 데 도움이 될 수 있습니다. 모든 자동 복구 테스트는 성공, 실패, 복구에 걸린 시간, 발생한 모든 문제에 대한 자세한 이메일 보고를 통해 테스트 결과에 대한 전체 기록을 제공합니다. 이러한 보고서 외에도 디스크 공간을 확보하기 위해 성공한 테스트를 삭제하고 복구 실패 원인을 조사하는 동안 실패한 복구는 그대로 두는 등의 추가 구성을 통해 테스트를 후속 조치할 수도 있습니다.

8. 유용한 리소스

유용한 계획 도구 및 정보 사이트 링크

미국 정부. 2003년 2월에 시작된 Ready는 자연재해와 인재를 포함한 비상사태에 대비하고, 대응하고, 완화할 수 있도록 미국 국민을 교육하고 권한을 부여하기 위해 고안된 국가 공익 캠페인입니다. 이 캠페인의 목표는 대중의 참여를 통해 대비를 촉진하는 것입니다.

IT 재해 복구 계획 https://www.ready.gov/it-disaster-recovery-plan

인디애나 대학교 - IT 전문가를 위한 리소스 재해 복구 계획 https://informationsecurity.iu.edu/resources-professionals/disaster-recovery-planning.html

IBM 예시: 재해 복구 계획 https://www.ibm.com/docs/en/i/7.1?topic=system-example-disaster-recovery-plan

EATON 다운타임 비용 계산기 https://powerquality.eaton.com/Products-services/Help-Me-Choose/DowntimeCostCalculator/Default.asp

9. 결론

재해 복구 계획과 재해 복구 프로세스 자체는 많은 조직에서 매우 중요하고 당연히 어려운 작업입니다. 백업 및 이중화를 위한 시스템 프로비저닝 비용은 적지 않지만, 많은 경우 다운타임 비용이나 랜섬웨어 공격으로 인한 광범위한 요구사항과 비교하면 이 비용은 미미한 수준에 불과합니다. 비즈니스 프로세스 설계의 대부분의 결정과 달리 재해 복구 계획에는 위험 분석과 고객, 공급업체 및 직원이 요구하는 서비스 수준에 따라 많은 절충안이 수반됩니다. 이 가이드가 백업과 복제 모두 강력한 DR 전략에서 중요한 역할을 하며, 대부분의 경우 둘 중 하나만 단독으로 사용하는 경우는 드물다는 것을 설명해 주었기를 바랍니다. 클라우드 컴퓨팅의 발전으로 이제 조직은 물리적, 가상, 클라우드 등 위치와 유형에 따라 백업 및 복제 대상을 폭넓게 선택할 수 있게 되었습니다. 또한 백업 및 복제 이동성은 공급업체 종속 또는 이중화 계획의 단일 장애 지점 발생 가능성을 방지하기 위해 모든 DRP에 포함되어야 하는 핵심 기능입니다. 시스템 복구, 복제 및 마이그레이션에 관한 자세한 내용은 Cristie 소프트웨어 팀에 문의하시면 언제든지 답변해 드립니다.

10. 참조

1. [온라인] 2022년 2월 9일 액세스, https://www.ccn.com/facebooks-blackout-90-million-lost-revenue/

2. [온라인] 2022년 2월 9일 액세스, https://money.cnn.com/2016/09/07/technology/delta-computer-outage-cost

3. [온라인] 2022년 2월 9일 액세스, https://blogs.gartner.com/andrew-lerner/2014/07/16/the-cost-of-downtime/

4. [온라인] 2022년 2월 9일 액세스, https://www.usenix.org/conference/fast16/technical-sessions/presentation/schroeder

5. [온라인] 2022년 2월 9일 액세스, https://purplesec.us/resources/cyber-security-statistics/

6. [온라인] 2022년 2월 9일 액세스, https://en.wikipedia.org/wiki/2021_Texas_power_crisis

문의하기

문의해 주셔서 감사합니다. 요청을 받았습니다.