| Quick Overview
재해 복구 테스트는 기업의 재해 복구 계획이 예상대로 작동하는지 확인하는 방법입니다. 테스트 시나리오는 시간과 리소스, 현실성에 따라 광범위한 시나리오로 확장할 수 있는 것이 가장 좋습니다. 반복적인 프로세스를 통해 발견된 문제점은 일상적인 데이터 보호 활동에 반영할 수 있는 귀중한 정보가 될 수 있습니다. |
재해 복구 테스트는 기업의 재해 복구 계획이 백업 및 복구 프로세스 체인 전반에서 실제 작동하도록 보장하기 위한 베스트 프랙티스이며, 적절한 데이터를 안전하게 백업하고 있는지 확인하는 방법입니다. 가장 중요한 것은 재해 복구 테스트를 통해 데이터와 애플리케이션이 저장/백업되고 원활하게 복구돼 비즈니스 연속성을 유지하는 기반이 된다는 확신을 가질 수 있다는 점입니다.
재해 복구 테스트는 가동 중단 이후 데이터와 시스템을 복구하는 역량을 입증할 뿐 아니라, 재해 발생 시 고객과 파트너에게 정보를 제공해야 하는 기업의 계획을 개선하는 효과도 제공합니다. 전체적인 목표는 어떤 재해가 닥치더라도 복구하고 비즈니스를 정상적으로 속개할 수 있는 최적의 환경을 보장하는 것입니다.
이번 포스팅에서는 재해 복구 테스트의 주요 측면을 살펴보고 철저한 재해 복구 테스트를 기업의 우선순위로 두는 데 도움이 되는 정보를 소개합니다.
재해 복구 테스트가 중요한 이유
재해 복구 테스트는 비상 사태 발생 시 조직의 재해 복구 계획이 예상대로 작동할지 확인하기 위한 행동입니다. 정기적인 재해 복구 테스트는 정상 운영 상태로 돌아가는 시간을 지연시킬 수 있는 복구 프로세스의 빈틈을 찾는 데 도움이 됩니다.
재해 복구는 한번 만들고 나면 잊어도 되는 프로세스라고 생각하기 쉽지만, 노련한 IT팀은 데이터 보호를 다음과 같은 여러 활동과 관행의 모음으로 간주합니다.
위의 각 구성요소는 효과적인 재해 복구 계획의 필수적인 부분입니다. 테스트를 재해 복구 프로세스의 필수 요소로 인식하면 데이터 보호 관행이 적절히 이뤄지도록 보장할 수 있으며, 필요한 때가 오면 원하는 방식으로 복구할 수 있다는 확신을 얻을 수 있습니다. 즉, 재해 복구 테스트가 빠진 데이터 보호 계획은 불완전한 계획입니다.
확인해야 할 재해 복구 테스트 시나리오
이상적으로 재해 복구 테스트는 시간과 리소스, 현실성에 따라 광범위한 시나리오로 확장할 수 있는 것이 가장 좋습니다. 일반적인 문제는 다음을 포함한 그 이상의 모든 파괴적인 재해 시나리오를 테스트하는 것은 현실적으로 어렵다는 것입니다.
미국 애리조나 주에 본사와 데이터센터가 있는 기업은 허리케인이 수시로 발생하는 플로리다 소재의 기업보다 홍수에 대한 걱정은 당연히 덜 할 것입니다. 마찬가지 맥락으로 사람의 실수로 인한 재해에서 복구하는 것과 대규모 장비 고장 또는 파괴에서 복구하는 것은 다릅니다.
복구가 필요한 상황이 언제 닥칠지는 예견할 수 없습니다. 현명한 접근 방법은 조사를 통해 회사에서 발생할 가능성이 가장 높은 5개 또는 10개의 재해 시나리오 목록을 만드는 것입니다. 이 목록을 기반으로 재해 발생 시 비즈니스를 보존할 수 있는 가능성이 높은 복구 계획을 수립할 수 있습니다.
재해 복구 계획을 수립할 때는 다양한 종류의 재해에 대한 복구의 상대적 어려움을 고려해야 합니다. 다음 질문을 던지고 답을 제시해 보십시오.
하드웨어가 손상되거나 사용할 수 없게 되는 경우 회사 데이터를 어디에 호스팅하는가? 예비 데이터센터인가? 가동할 수 있는 클라우드 서비스인가?
예비 인프라를 프로비저닝하거나 클라우드에서 가동하는 데 얼마나 오랜 시간이 걸리는가?
각 옵션의 비용은 얼마인가?
계획을 적절히 실행하기 위해서는 어떤 사람들과 리소스가 필요한가?
회사가 여러 지역에 걸쳐 운영되는 경우 백업과 복구에 지역별 규정이 적용되는가?
재해 복구 테스트를 시작하는 방법
물론 모든 재해 복구 계획에서 가장 중요한 규칙은 백업이 실행되고 있으며, 우선순위가 높은 애플리케이션과 데이터를 보호하고 있는지 확인하는 것입니다. 이를 확인했다면 다음 단계에 집중하십시오.
시스템 복구에 높은 우선 순위 지정
재해 복구 계획에서 중요한 부분은 기업에서 보호/복구해야 할 가장 중요한 시스템이 무엇인지 파악하는 것입니다. 기업의 모든 시스템을 동일하게 취급할 수는 없으므로 중요도에 따라 시스템을 분류해야 합니다. 그렇게 하면 재해 이후 비즈니스 연속성을 위해 반드시 필요한 시스템부터 시작하는 시스템 계층 구조가 만들어집니다. 그런 다음 적절히 테스트를 구성하면 됩니다.
온라인 스토어라면 핵심 시스템은 전자상거래 사이트, 장바구니 및 결제 시스템일 것입니다. 체계적인 영업 조직이 있는 회사라면 CRM(Customer Relationship Management) 애플리케이션 및 관련 데이터베이스일 것입니다. 병원 및 의료 제공업체는 EMR(Electronic Medical Records) 및 처방 자동화에 대한 의존도가 높습니다.
백업 관리자는 재해 복구 계획의 일부로 백업할 대상과 백업 빈도, 저장해야 하는(기업에서 감당할 수 있는) 복사본의 수를 정해야 합니다. 그리고 이 모든 것은 “비즈니스에서 보호하고 복구해야 할 가장 중요한 시스템은 무엇인가?”라는 질문을 통해 좌우됩니다.
시스템 종속성 파악
관리자는 백업을 검증하기 위해 서버, 데이터베이스, 애플리케이션 백업을 개별적으로 테스트합니다. 그러나 이런 방식은 진정한 재해 복구 테스트가 아닙니다. 실제 재해가 발생하면 연계해서 작동해야 하는 여러 자산으로 구성된 전체 시스템을 시급하게 복원해야 합니다. 개별 구성요소를 테스트하는 방식에서는 시스템 간의 상호작용과 종속성이 무시됩니다. 구성요소를 개별적으로 테스트하는 것보다 모든 시스템 복원하고 이전과 같이 작동하는지 확인하는 시나리오가 훨씬 좋습니다.
예를 들어, DHCP 서버는 이 서버에 의존하는 기기를 위해 가동되어 IP 주소를 할당해야 합니다. AD(Active Directory)에는 DHCP 서버가 필요하고 프론트엔드 서버에는 오라클 데이터베이스가 필요합니다.
개별 구성요소를 따로따로 복원할 수 있지만, 이런 구성요소가 함께 제대로 작동하지 않으면 잘못된 결론을 도출할 위험이 있습니다. 백업-복원 사이클이 손상되지 않아도 종속 항목이 누락될 가능성이 높기 때문입니다.
예를 들어, 데이터베이스를 복원하고 시작해서 로그인하고 데이터가 보이는 것까지 확인한다고 가정해 보겠습니다. 프론트엔드 애플리케이션도 복원해서 실행하고 이후 데이터베이스에 의존하는 몇몇 트랜잭션을 실행해보기 전까지는 그 이상의 결론은 내리지 못할 것입니다.
테스트를 하면 재해 시나리오에서 필요한 작업 순서에 대한 많은 정보를 얻게 됩니다. 목적과 의도를 갖고 재해 복구 테스트를 설계하면 계획을 훨씬 쉽게 검증할 수 있습니다.
테스트 일정 수립
정기적인 테스트 일정은 재해 복구 계획의 여러 요소가 예상대로 작동하는지 확인하기 위해 매우 중요합니다. 테스트 일정을 수립할 때 중요한 점은 테스트할 모든 항목을 목록으로 작성하고 테스트 빈도를 설정하고 테스트 일정을 지키는 것입니다. 매년, 학기별, 분기별, 월별 등으로 테스트 시기를 지정해 중요도 계층에 맞게 조정하십시오. 사용할 테스트 방법도 명시해야 합니다. 검토, 모의 훈련, 병렬 또는 전체 중단 테스트 등의 재해 복구 테스트 유형을 통해 잠재적인 빈틈을 찾을 수 있습니다.
모든 기업에 적용되는 중요 시사점
우선 복잡성의 수준에 관계없이 첫 시도에 완벽하게 재해복구 테스트를 수행할 수 있는 IT 환경은 없습니다. 반복적인 프로세스를 통해 변경 및 개선할 부분에 대한 시사점을 얻어 향후 재해 복구 테스트를 개선할 수 있습니다.
재해 복구 테스트를 통해 몇몇 시스템과 기기는 비즈니스에 극히 중요해서 재시작되는 경우가 거의 없다는 사실을 발견할 수도 있습니다. 즉, 해당 시스템에 어떤 일이 발생하면 문제가 드러나기까지 몇 개월 또는 몇 년이 걸릴 수 있습니다.
예를 들어, 재해 복구 테스트 중에 데이터베이스를 복원했는데 시작되지 않는 경우를 가정해 보겠습니다. 확인해 보니 지난 2년 동안 데이터베이스가 재시작된 적이 없어 시스템 업데이트가 필요한 상태이기 때문에 재시작이 되지 않았던 겁니다. 실제 재해가 아니라 테스트 중에 이런 사실을 알게 된다면 일상적인 데이터 보호 활동에 반영할 수 있는 귀중한 정보가 될 것입니다.
재해 복구 테스트에서 저지르는 가장 큰 실수
물론 가장 큰 실수는 재해 복구 계획을 두지 않는 것입니다. 다음으로 큰 실수는 계획을 정기적으로 테스트하지 않고 테스트 일정을 지키지 않으며, 비즈니스 연속성을 위해 필요하다고 이미 판단한 재해 복구 계획을 보호하지 않는 것입니다.
발생 가능성이 낮은 시나리오를 간과하는 것 또한 큰 실수입니다. 예를 들어, 홍수 또는 자연 재해 시나리오에서는 복원 작업에 사용할 수 있는 데이터센터 하드웨어가 없을 수 있습니다.
이런 시나리오에서는 다른 데이터센터로 페일오버하거나 클라우드 서비스를 가동해서 부하를 처리하기 위한 충분한 용량을 확보하는 것을 테스트해야 합니다. 또한 용량이 충분하다 해도 복원에 용인하기 어려울 정도로 많은 시간이 걸리는지, 6TB 용량의 데이터베이스를 클라우드로 복원하는 동안 비즈니스가 얼마나 오래 오프라인 상태로 유지될지를 확인해야 합니다.
실제 가동 중단을 극복하기 위한 철저한 재해 복구 테스트만이 이런 질문에 대한 답을 줄 수 있습니다.
결론
재해 복구만으로는 모든 IT 문제를 해결할 수 없습니다. 하지만 위험을 감수한 채 재해 복구 테스트의 중요성을 무시하는 기업이 많습니다. 재해 복구 테스트는 백업의 품질과 가용성에 대한 확신을 얻는 유용한 방법입니다.
시스템 계층에 따른 정기적인 재해 복구 테스트를 철저히 수행하면 비즈니스 연속성을 위해 실제 복원이 필요한 경우를 대비할 수 있습니다. 현명한 기업과 IT팀은 데이터 보호 약속을 지키기 위해 리소스를 투입해서 재해 복구 계획을 테스트합니다.
재해 복구 계획에 어려움을 겪고 계시거나 관련 솔루션에 대해 궁금한 점이 있으시면 퀘스트소프트웨어코리아로 언제든 문의주시기 바랍니다.
재해 복구 테스트는 기업의 재해 복구 계획이 예상대로 작동하는지 확인하는 방법입니다. 테스트 시나리오는 시간과 리소스, 현실성에 따라 광범위한 시나리오로 확장할 수 있는 것이 가장 좋습니다. 반복적인 프로세스를 통해 발견된 문제점은 일상적인 데이터 보호 활동에 반영할 수 있는 귀중한 정보가 될 수 있습니다.
재해 복구 테스트는 기업의 재해 복구 계획이 백업 및 복구 프로세스 체인 전반에서 실제 작동하도록 보장하기 위한 베스트 프랙티스이며, 적절한 데이터를 안전하게 백업하고 있는지 확인하는 방법입니다. 가장 중요한 것은 재해 복구 테스트를 통해 데이터와 애플리케이션이 저장/백업되고 원활하게 복구돼 비즈니스 연속성을 유지하는 기반이 된다는 확신을 가질 수 있다는 점입니다.
재해 복구 테스트는 가동 중단 이후 데이터와 시스템을 복구하는 역량을 입증할 뿐 아니라, 재해 발생 시 고객과 파트너에게 정보를 제공해야 하는 기업의 계획을 개선하는 효과도 제공합니다. 전체적인 목표는 어떤 재해가 닥치더라도 복구하고 비즈니스를 정상적으로 속개할 수 있는 최적의 환경을 보장하는 것입니다.
이번 포스팅에서는 재해 복구 테스트의 주요 측면을 살펴보고 철저한 재해 복구 테스트를 기업의 우선순위로 두는 데 도움이 되는 정보를 소개합니다.
재해 복구 테스트가 중요한 이유
재해 복구 테스트는 비상 사태 발생 시 조직의 재해 복구 계획이 예상대로 작동할지 확인하기 위한 행동입니다. 정기적인 재해 복구 테스트는 정상 운영 상태로 돌아가는 시간을 지연시킬 수 있는 복구 프로세스의 빈틈을 찾는 데 도움이 됩니다.
재해 복구는 한번 만들고 나면 잊어도 되는 프로세스라고 생각하기 쉽지만, 노련한 IT팀은 데이터 보호를 다음과 같은 여러 활동과 관행의 모음으로 간주합니다.
데이터 보호를 위한 시스템 및 프로세스의 설계와 아키텍처
상호 의존적인 백업 및 운영 작업
재해 복구 테스트
위의 각 구성요소는 효과적인 재해 복구 계획의 필수적인 부분입니다. 테스트를 재해 복구 프로세스의 필수 요소로 인식하면 데이터 보호 관행이 적절히 이뤄지도록 보장할 수 있으며, 필요한 때가 오면 원하는 방식으로 복구할 수 있다는 확신을 얻을 수 있습니다. 즉, 재해 복구 테스트가 빠진 데이터 보호 계획은 불완전한 계획입니다.
확인해야 할 재해 복구 테스트 시나리오
이상적으로 재해 복구 테스트는 시간과 리소스, 현실성에 따라 광범위한 시나리오로 확장할 수 있는 것이 가장 좋습니다. 일반적인 문제는 다음을 포함한 그 이상의 모든 파괴적인 재해 시나리오를 테스트하는 것은 현실적으로 어렵다는 것입니다.
지진, 홍수, 기상 이변과 같은 자연 재해
화재
장비 고장
사람의 실수
랜섬웨어
반달리즘
불만을 품은 직원 및 내부 공격
귀중한 서버 및 고가 스토리지의 도난
미국 애리조나 주에 본사와 데이터센터가 있는 기업은 허리케인이 수시로 발생하는 플로리다 소재의 기업보다 홍수에 대한 걱정은 당연히 덜 할 것입니다. 마찬가지 맥락으로 사람의 실수로 인한 재해에서 복구하는 것과 대규모 장비 고장 또는 파괴에서 복구하는 것은 다릅니다.
복구가 필요한 상황이 언제 닥칠지는 예견할 수 없습니다. 현명한 접근 방법은 조사를 통해 회사에서 발생할 가능성이 가장 높은 5개 또는 10개의 재해 시나리오 목록을 만드는 것입니다. 이 목록을 기반으로 재해 발생 시 비즈니스를 보존할 수 있는 가능성이 높은 복구 계획을 수립할 수 있습니다.
재해 복구 계획을 수립할 때는 다양한 종류의 재해에 대한 복구의 상대적 어려움을 고려해야 합니다. 다음 질문을 던지고 답을 제시해 보십시오.
하드웨어가 손상되거나 사용할 수 없게 되는 경우 회사 데이터를 어디에 호스팅하는가? 예비 데이터센터인가? 가동할 수 있는 클라우드 서비스인가?
예비 인프라를 프로비저닝하거나 클라우드에서 가동하는 데 얼마나 오랜 시간이 걸리는가?
각 옵션의 비용은 얼마인가?
계획을 적절히 실행하기 위해서는 어떤 사람들과 리소스가 필요한가?
회사가 여러 지역에 걸쳐 운영되는 경우 백업과 복구에 지역별 규정이 적용되는가?
재해 복구 테스트를 시작하는 방법
물론 모든 재해 복구 계획에서 가장 중요한 규칙은 백업이 실행되고 있으며, 우선순위가 높은 애플리케이션과 데이터를 보호하고 있는지 확인하는 것입니다. 이를 확인했다면 다음 단계에 집중하십시오.
시스템 복구에 높은 우선 순위 지정
재해 복구 계획에서 중요한 부분은 기업에서 보호/복구해야 할 가장 중요한 시스템이 무엇인지 파악하는 것입니다. 기업의 모든 시스템을 동일하게 취급할 수는 없으므로 중요도에 따라 시스템을 분류해야 합니다. 그렇게 하면 재해 이후 비즈니스 연속성을 위해 반드시 필요한 시스템부터 시작하는 시스템 계층 구조가 만들어집니다. 그런 다음 적절히 테스트를 구성하면 됩니다.
온라인 스토어라면 핵심 시스템은 전자상거래 사이트, 장바구니 및 결제 시스템일 것입니다. 체계적인 영업 조직이 있는 회사라면 CRM(Customer Relationship Management) 애플리케이션 및 관련 데이터베이스일 것입니다. 병원 및 의료 제공업체는 EMR(Electronic Medical Records) 및 처방 자동화에 대한 의존도가 높습니다.
백업 관리자는 재해 복구 계획의 일부로 백업할 대상과 백업 빈도, 저장해야 하는(기업에서 감당할 수 있는) 복사본의 수를 정해야 합니다. 그리고 이 모든 것은 “비즈니스에서 보호하고 복구해야 할 가장 중요한 시스템은 무엇인가?”라는 질문을 통해 좌우됩니다.
시스템 종속성 파악
관리자는 백업을 검증하기 위해 서버, 데이터베이스, 애플리케이션 백업을 개별적으로 테스트합니다. 그러나 이런 방식은 진정한 재해 복구 테스트가 아닙니다. 실제 재해가 발생하면 연계해서 작동해야 하는 여러 자산으로 구성된 전체 시스템을 시급하게 복원해야 합니다. 개별 구성요소를 테스트하는 방식에서는 시스템 간의 상호작용과 종속성이 무시됩니다. 구성요소를 개별적으로 테스트하는 것보다 모든 시스템 복원하고 이전과 같이 작동하는지 확인하는 시나리오가 훨씬 좋습니다.
예를 들어, DHCP 서버는 이 서버에 의존하는 기기를 위해 가동되어 IP 주소를 할당해야 합니다. AD(Active Directory)에는 DHCP 서버가 필요하고 프론트엔드 서버에는 오라클 데이터베이스가 필요합니다.
개별 구성요소를 따로따로 복원할 수 있지만, 이런 구성요소가 함께 제대로 작동하지 않으면 잘못된 결론을 도출할 위험이 있습니다. 백업-복원 사이클이 손상되지 않아도 종속 항목이 누락될 가능성이 높기 때문입니다.
예를 들어, 데이터베이스를 복원하고 시작해서 로그인하고 데이터가 보이는 것까지 확인한다고 가정해 보겠습니다. 프론트엔드 애플리케이션도 복원해서 실행하고 이후 데이터베이스에 의존하는 몇몇 트랜잭션을 실행해보기 전까지는 그 이상의 결론은 내리지 못할 것입니다.
테스트를 하면 재해 시나리오에서 필요한 작업 순서에 대한 많은 정보를 얻게 됩니다. 목적과 의도를 갖고 재해 복구 테스트를 설계하면 계획을 훨씬 쉽게 검증할 수 있습니다.
테스트 일정 수립
정기적인 테스트 일정은 재해 복구 계획의 여러 요소가 예상대로 작동하는지 확인하기 위해 매우 중요합니다. 테스트 일정을 수립할 때 중요한 점은 테스트할 모든 항목을 목록으로 작성하고 테스트 빈도를 설정하고 테스트 일정을 지키는 것입니다. 매년, 학기별, 분기별, 월별 등으로 테스트 시기를 지정해 중요도 계층에 맞게 조정하십시오. 사용할 테스트 방법도 명시해야 합니다. 검토, 모의 훈련, 병렬 또는 전체 중단 테스트 등의 재해 복구 테스트 유형을 통해 잠재적인 빈틈을 찾을 수 있습니다.
모든 기업에 적용되는 중요 시사점
우선 복잡성의 수준에 관계없이 첫 시도에 완벽하게 재해복구 테스트를 수행할 수 있는 IT 환경은 없습니다. 반복적인 프로세스를 통해 변경 및 개선할 부분에 대한 시사점을 얻어 향후 재해 복구 테스트를 개선할 수 있습니다.
재해 복구 테스트를 통해 몇몇 시스템과 기기는 비즈니스에 극히 중요해서 재시작되는 경우가 거의 없다는 사실을 발견할 수도 있습니다. 즉, 해당 시스템에 어떤 일이 발생하면 문제가 드러나기까지 몇 개월 또는 몇 년이 걸릴 수 있습니다.
예를 들어, 재해 복구 테스트 중에 데이터베이스를 복원했는데 시작되지 않는 경우를 가정해 보겠습니다. 확인해 보니 지난 2년 동안 데이터베이스가 재시작된 적이 없어 시스템 업데이트가 필요한 상태이기 때문에 재시작이 되지 않았던 겁니다. 실제 재해가 아니라 테스트 중에 이런 사실을 알게 된다면 일상적인 데이터 보호 활동에 반영할 수 있는 귀중한 정보가 될 것입니다.
재해 복구 테스트에서 저지르는 가장 큰 실수
물론 가장 큰 실수는 재해 복구 계획을 두지 않는 것입니다. 다음으로 큰 실수는 계획을 정기적으로 테스트하지 않고 테스트 일정을 지키지 않으며, 비즈니스 연속성을 위해 필요하다고 이미 판단한 재해 복구 계획을 보호하지 않는 것입니다.
발생 가능성이 낮은 시나리오를 간과하는 것 또한 큰 실수입니다. 예를 들어, 홍수 또는 자연 재해 시나리오에서는 복원 작업에 사용할 수 있는 데이터센터 하드웨어가 없을 수 있습니다.
이런 시나리오에서는 다른 데이터센터로 페일오버하거나 클라우드 서비스를 가동해서 부하를 처리하기 위한 충분한 용량을 확보하는 것을 테스트해야 합니다. 또한 용량이 충분하다 해도 복원에 용인하기 어려울 정도로 많은 시간이 걸리는지, 6TB 용량의 데이터베이스를 클라우드로 복원하는 동안 비즈니스가 얼마나 오래 오프라인 상태로 유지될지를 확인해야 합니다.
실제 가동 중단을 극복하기 위한 철저한 재해 복구 테스트만이 이런 질문에 대한 답을 줄 수 있습니다.
결론
재해 복구만으로는 모든 IT 문제를 해결할 수 없습니다. 하지만 위험을 감수한 채 재해 복구 테스트의 중요성을 무시하는 기업이 많습니다. 재해 복구 테스트는 백업의 품질과 가용성에 대한 확신을 얻는 유용한 방법입니다.
시스템 계층에 따른 정기적인 재해 복구 테스트를 철저히 수행하면 비즈니스 연속성을 위해 실제 복원이 필요한 경우를 대비할 수 있습니다. 현명한 기업과 IT팀은 데이터 보호 약속을 지키기 위해 리소스를 투입해서 재해 복구 계획을 테스트합니다.
재해 복구 계획에 어려움을 겪고 계시거나 관련 솔루션에 대해 궁금한 점이 있으시면 퀘스트소프트웨어코리아로 언제든 문의주시기 바랍니다.