자료실

효과적인 데이터 백업 전략을 수립하는 7단계 - 1부


효과적인 데이터 백업 전략을 수립하는 7단계 - 1부


데이터 백업 전략의 목적은 심각한 가동 중단이나 재해를 대비하는 것입니다. 홍수, 화재, 정전, 맬웨어, 사이버 공격, 자연재해는 IT 관리자들이 가장 우려하는 사태이지만, 데이터센터의 천장에서 물이 새거나 사람의 실수로 인해 데이터베이스가 손상되는 사고도 발생합니다. 


재해는 온갖 형태와 규모로 닥치지만 한 가지 공통점이 있습니다. 언제나 대비가 부족한 상황에서 발생한다는 것입니다. 사전에 대비하려면 다음과 같은 질문에 답할 수 있어야 합니다. 


  • 기업에 데이터 백업 전략이 있습니까? 

  • 그 전략은 어떤 위험에 대처합니까? 

  • 전략을 통해 달성하고자 하는 목표는 무엇입니까? 

  • 비즈니스 관계자가 전략 수립에 참여했습니까? 

  • 전략을 문서로 만들었습니까? 

  • 전략을 테스트했습니까? 


이번 포스팅에서는 초기 평가부터 지속적인 테스트에 이르기까지 정보에 기반한 데이터 백업 전략을 수립하는 데 도움이 되는 7단계를 소개합니다.

1. 위험 파악하기 

가장 약한 연결 고리는 어디인가요? 그 고리가 끊어지면 비즈니스가 얼마나 취약해지나요? 


  • 물론 사이트 전반의 재해는 신문 헤드라인을 장식하는 가장 큰 우려 대상입니다. 지진, 홍수, 토네이도는 사이트의 가치가 얼마인지와는 무관하게 찾아와 타격을 입히고 가동을 중단시킵니다. 

  • 플랫폼 장애의 사고 범위는 인프라 내의 한 요소지만, 기술 구성요소 간의 보이지 않는 관계로 인한 연쇄 반응이 포함됩니다. 

  • 애플리케이션 문제는 패치처럼 겉보기에는 무해한 변경이 원인이 되어 발생할 수 있습니다. 보안 업데이트를 적용했는데 업데이트에 버그가 포함되어 있다면 알려진 마지막 정상 구성으로 롤백해야 할 수 있습니다. 컨트롤은 변경과 관련된 위험을 파악하기 위해 존재합니다. 

  • 데이터 손실은 랜섬웨어 공격과 관련해서 대부분 IT 관리자들이 가장 많이 신경 쓰는 부분입니다. 첫 번째 위험은 훔친 데이터에 대한 몸값을 요구하는 것이고, 두 번째 위험은 이들이 스토리지의 데이터를 암호화할 수 있다는 점입니다. 이들은 백업도 찾아서 삭제합니다. 

  • 인적 요소는 일상적인 실수로 인한 우발적인 삭제부터 불만을 품은 내부자의 보복, 국가 주도 공격에 이르기까지 다양합니다. 


여기에 위험 평가의 역할이 있습니다. 전체 IT 인벤토리를 파악하고 있다는 생각은 착각일 수 있습니다. 가상 머신(VM)의 확산이나 섀도우 IT와 같은 추세로 인해 확고한 인벤토리 파악이 어렵기 때문입니다. 더 신중한 방법은 인벤토리 프로세스를 자동화해서 누락되는 요소가 없도록 하는 것입니다. 


데이터센터의 공기 조절 상태, 바닥 아래를 지나는 파이프, 근처 기업에서 추진하는 일 등을 수시로 점검하는 것이 지나치다고 생각될 수 있습니다. 그러나 물리적 설비 관점에서 볼 때 완전히 무방비 상태로 사고에 직면하는 것보다 낫습니다. 


또한 데이터 백업 전략에는 각 데이터센터에 맞는 재해 복구 계획을 포함해야 합니다. 예를 들어, 미국 플로리다주에 위치한 데이터센터의 위험 수준은 애리조나주의 데이터센터와 다르므로 위험을 분산시켜야 하며, 이를 통해 분산된 데이터의 이점을 활용할 수 있습니다. 


SaaS 제공업체는 인프라의 위험을 낮추기 위해 어떤 조치를 취했는지 고객에게 알릴 수 있어야 합니다. 제공업체의 위험도 위험 평가의 일부분이므로 반드시 반영해야 합니다. 


다음은 한 가상 기업의 데이터센터에 대한 IT 인벤토리, 위험 평가 및 위험 분류의 예입니다. 

자산, 위험 수준, 재해 또는 가동 중단 발생 시 잠재적인 비즈니스 영향이 명확하게 정의되어 있습니다. 



2. 데이터 파악하기 

기업이 보유한 데이터를 제대로 파악하지 못하면 필요 없는 백업 데이터에 비용을 지불하게 될 가능성이 큽니다. 비즈니스에 사용되는 모든 데이터가 똑같은 가치를 지니지는 않습니다. 이런 특징은 데이터 백업 전략에서 여러 가지 중요한 차원으로 이어집니다. 


  • 비용 : 데이터가 많을수록 데이터 저장에 더 많은 비용이 듭니다. 

  • 시간 : 백업하는 데이터가 많을수록 복원에 걸리는 시간도 길어집니다. 

  • 기술 : 데이터 유형에 따라 적합한 백업 스토리지 옵션이 달라집니다. 


기술 중심의 사고 방식은 비용과 시간 차원의 큰 변화로 이어질 수 있습니다. 다음과 같은 유형의 데이터를 고려해 보십시오. 


  • 정적 데이터 : 시간이 지나도 변경되지 않는 오래된 데이터. 중요하지 않은 데이터라는 의미는 아닙니다. 예를 들어, 회사의 정관이 중요하지 않다고 주장하는 사람은 없을 것입니다. 그러나 이 데이터는 수정은 고사하고 누군가가 검색할 일이 거의 없습니다. 

  • 비즈니스 핵심 데이터 : 회계 기록, 전략 문서처럼 비즈니스를 위해 필수적인 데이터. 이 데이터가 없으면 비즈니스는 기능할 수 없습니다. 

  • 미션 크리티컬 데이터 : 이 데이터가 잠깐이라도 손실되거나 사용 불가 상태가 되면 비즈니스는 피해를 입습니다. 데이터 손실을 줄이면 재해 발생 시 그만큼 적은 데이터만 복구하면 되므로 이를 위한 조밀한 복구 지점 옵션이 필요합니다. 


물론 이것은 IT 관점입니다. 사업부 관리자에게 어떤 데이터가 얼마나 중요하고 재해 발생 이후 어떤 데이터를 신속하게 복구해야 하는지 물으면 “모든 데이터”라고 말할 것입니다. IT 부서에서는 일단 “해보겠다”라고 대답은 하겠지만, 마케팅/운영/엔지니어링/영업/지원 부서의 관리자들과 비슷한 대화를 나눈 이후에는 감당할 수 없을 정도의 추정 비용이 나옵니다. 따라서 IT 부서가 “모든 데이터를 신속하게 복구할 수는 없다. 그러니까 미션 크리티컬 데이터가 무엇인지 알려 달라. 그 데이터는 고가의 기술로 백업해서 저장하고, 나머지 데이터는 덜 비싼 데이터 보호 기술을 사용할 것이다”라고 말하는 것으로 두 번째 대화가 시작될 것입니다. 


왜 2단계 프로세스로 진행되어야 할까요? 사업부 관리자는 자신의 비즈니스를 알지만, 데이터는 모르기 때문입니다. 그래서 이 단계가 중요합니다. IT 관점에서 정적 데이터에 사용하는 기술과 미션 크리티컬 데이터에 사용하는 기술이 동일하다는 것은 말이 되지 않습니다. 데이터 사용 용도가 다르므로 노출과 위험도 서로 다릅니다. 다양한 백업 및 스토리지 기술이 필요한 이유입니다. 


참고로 모든 기업이 이런 방식을 사용하지는 않습니다. 일부 IT 부서는 다른 방법을 사용합니다. 비즈니스에 대한 SLA(service level agreement)을 설정하고 “이것이 우리가 사용하는 백업 및 스토리지 기술이다. 어떤 상황에서도 이 데이터를 n개월 동안 유지할 수 있다. 그 이후에는 다른 곳으로 옮기거나 삭제할 것이다”라고 말합니다. 


혹은 중요도별로 애플리케이션을 그룹화할 수도 있습니다. 예를 들어, 고객 거래 데이터베이스의 변화율이 높은데 1년 동안 스냅샷을 보관해야 할까요? 아마도 아닐 것입니다. 1년 동안 너무 많은 부분이 변경되어 쓸모가 없어지기 때문입니다. 


3. 목표 파악하기 

데이터 백업 전략의 주된 목표는 당연히 재해가 발생했을 때 데이터를 복구하는 것입니다. 이를 세분화해 데이터 복구에 대해 생각하면서 각 데이터 집합의 중요도를 평가해야 합니다. 그 이유는 사용할 백업 및 복구 메커니즘의 유형은 이런 중요도와 해당 데이터 집합 없이 얼마나 오래 운영할 수 있는지의 함수이기 때문입니다. 


‘데이터 파악’ 단계에서 IT 부서는 비즈니스 관리자들과 백업에 대해 대화를 나누었습니다. ‘목표 파악’ 단계에서는 복구, 다운타임, SLA에 대해 대화를 나눕니다. 관리자들은 “무엇을 백업할 수 있는지는 알겠다. 그렇다면 얼마나 빨리 복구할 수 있는가”라고 물을 것입니다. 무엇을, 어느 정도의 시간 안에 복구할 수 있는지 답하는 것은 이제 여러분의 몫입니다. 


  • 어떤 종류의 가동 중단이 발생할 수 있는가? 

  • 애플리케이션이 오프라인 상태로 머무는 시간을 어느 정도로 예상하는가? 

  • 얼마나 오랫동안 업무 수행을 할 수 없는가? 

  • 고객과 비즈니스 파트너는 우리 시스템을 얼마나 오랫동안 사용할 수 없는가? 


이런 식으로 애플리케이션에 기초해 비즈니스의 나머지 부분으로 SLA를 설정해 나갑니다. 예를 들어, 재무 부서에는 “ERP가 주요 비즈니스 애플리케이션이므로 재해가 발생하면 이를 복구하기 위해 이런 기술을 사용할 것이다. n시간 내에 다시 가동될 것”이라고 대답할 수 있습니다. 


또한 IT팀은 계속해서 SLA를 기반으로 애저, AWS, 구글과 같은 외부 서비스 제공업체와 함께 작업합니다. 결국 이 SLA는 IT가 내부적으로 제공하는 서비스에도 똑같이 적용됩니다. 


지금까지 재해에 대비한 효과적인 데이터 백업 전략을 수립하는 데 도움이 되는 3단계 과정을 살펴보았습니다. 2부에서는 나머지 4단계를 다루겠습니다. 데이터 백업에 대해 궁금한 점이 있으시거나 관련 솔루션 상담이 필요하시면 언제든 퀘스트소프트웨어 코리아로 문의주시기 바랍니다.




퀘스트소프트웨어코리아(주)

서울특별시 강남구 테헤란로 445 본솔빌딩10F
전화 번호 02-3420-9000 | 팩스 번호 02-569-3600

전자 메일 KoreaMarketing@quest.com 


Copyright © Quest. All Rights Reserved.

Hosting by I'MWEB


퀘스트소프트웨어코리아(주) 서울특별시 강남구 테헤란로 445 본솔빌딩10F
전화 번호 02-3420-9000 | 팩스 번호 02-569-3600 | 전자 메일 KoreaMarketing@quest.com


Copyright © Quest. All Rights Reserved.

Hosting by I'MWEB