Quick Overview 데이터 백업은 비즈니스 연속성을 위해 중요하지만, 백업과 보호의 중요성은 종종 과소평가되고 여러 기술적 혁신 속에서 관심을 받지 못하는 경우가 많습니다. 기업은 데이터 보호를 높은 수준에서 노력하고, 비즈니스 변화에 따라 데이터 보호 방식을 조정해야 합니다. 여기서는 올바른 백업을 위해 피해야 할 6가지 실수를 살펴봅니다. |
백업은 IT 인프라의 핵심 요소입니다. 그러나 백업은 데이터 손실이 발생하거나 다른 재해가 닥치기 전까지 낮은 우선 순위로 뒷전으로 밀리는 경우가 많습니다. 백업이 뒷전으로 밀리면 조직적인 실수가 발생하여 비즈니스 중단으로 이어질 수 있습니다. 이번 포스팅에서는 기업에서 백업과 관련하여 흔히 저지르는 다음과 같은 실수와 이를 방지하는 데 도움이 되는 제안을 살펴봅니다.
실수 1. IT 부서가 비즈니스 요구사항을 무시하는 백업 의사 결정을 내림
많은 기업에서 IT 부서 또는 기술 파트너는 백업 구현을 많건 적건 직접 담당합니다. 또한 데이터 보호가 기업에 즉각적인 혜택이 되지 않는 비용 센터로 간주되므로 백업에 대한 예산은 논쟁의 대상이 되는 경우가 많습니다. 여기서 발생하는 실수는 백업 대상, 데이터 보존 기간, 백업의 우선 순위에 대한 의사 결정을 전적으로 IT 부서가 내리도록 하는 것입니다.
이런 실수의 근본적인 원인은 데이터 보호에 대한 경영진의 시각과 담당 IT 부서의 생각이 다르다는 데 있습니다. 농업, 제철, 영화 제작, 가구 제조 등 업종을 불문하고 경영진은 비즈니스에, IT 부서는 그 비즈니스 운영을 지원하는 기술에 각각 초점을 맞춘다는 데서 불일치가 발생합니다. IT가 비즈니스를 움직이기 위한 단순한 메커니즘 또는 수단이 될 때 데이터 보호의 중요성에 대한 오해가 발생할 가능성이 높아집니다.
백업에 대한 의사 결정은 데이터 보호에 대한 회사의 현재 요구사항을 기반으로 내리는 것이 더 적절하며, 이는 IT 부서가 비즈니스와 함께 이 의사 결정에 참여하는 것을 전제로 합니다.
예를 들어, 기업의 온프레미스 이메일 관리가 마이크로소프트 365의 클라우드 패러다임으로 발전하자 많은 사람들은 더 이상 이 데이터를 보호할 필요가 없다고 생각했습니다. 이 기능이 아웃소싱되므로 마이크로소프트가 보호해줄 것으로 전제했기 때문입니다. 그러나 얼마 지나지 않아 클라우드에 둔다 해도 그것은 여전히 자신의 데이터이며 따라서 그 데이터를 보호할 주된 책임도 기업 자체에 있음이 분명해졌습니다.
실제로 기업은 기능과 스토리지를 위해 클라우드를 사용하지만, 그렇다 해도 데이터를 보호해야 할 의무가 사라지는 것은 아닙니다. 마이크로소프트는 플랫폼을 제공하고 이 플랫폼의 가용성을 유지하기 위해 최선의 노력을 다합니다. 플랫폼에서 조직의 실수로 데이터를 잃는다면 마이크로소프트에 책임을 물을 수 없습니다. 결과적으로, IT 부서는 더 이상 온프레미스에 위치하지 않는 데이터와 애플리케이션을 위한 데이터 보호 환경을 구축하기 위한 예산이 필요하게 되었습니다.
회사의 유형에 따라 데이터 백업에 대한 IT 부서와 경영진 간의 시각 차이는 더 클 수 있습니다. 또한 고위 경영진이 현실과 달리 모든 것이 보호되고 있다고 생각하고 여기서 간극일 발생할 수도 있습니다.
일반적으로 무엇을 보관하고 무엇을 버려야 할지 IT 부서가 알기를 기대하는 것은 적절하지 않습니다. 또한 IT 부서는 보관해야 할 데이터를 얼마나 오래 보관해야 하는지도 모를 가능성이 높습니다. IT 부서가 아는 것은 모든 데이터를 영구적으로 보관하기에는 너무 많은 비용이 든다는 점입니다.
게다가 디지털 개인정보 보호 권리도 무엇을 보관하고 버릴지에 대해 영향을 미치므로 IT 부서가 직면하는 문제는 더욱 복잡해집니다. GDPR과 같은 규정은 기업이 비즈니스와 무관한 데이터를 보관하는 것을 금지하는데, 더 이상 관련성이 없는 것으로 간주되는 데이터가 여전히 장기 스토리지에 남아 있는 경우 데이터 백업 맥락에서 이 규정대로 시행하기가 까다롭게 됩니다.
실수 2. 문제 발생 시 기대치를 설정하기 위한 SLA의 부재
SLA의 역할은 특정 시나리오에서 IT 부서가 제공할 수 있는 부분에 대한 모두의 기대치를 설정하는 것입니다. 이 맥락에서 일반적인 SLA는 IT 부서가 특정 문제를 복구하기 위해 필요한 시간과 같은 요소를 다룹니다. 사용자가 실수로 파일을 삭제하여 IT 부서가 이 파일을 복구해야 하는 경우를 가정해 봅시다. 회사는 가장 최근에 백업된 버전을 복구하기 위한 SLA를 가령 3시간으로 설정할 수 있습니다.
최악의 시나리오는 아예 SLA가 없는 것입니다. 이는 데이터 손실, 랜섬웨어, 홍수, 화재 및 기타 문제에 대해 비즈니스가 어떻게 보호되는지에 관한 공통된 이해가 없음을 의미합니다. 기본적으로 “최선의 노력 SLA”라고 할 수 있는데 이 말은 “건물에 화재가 발생한다면 데이터를 복구하기 위해 최선을 다할 것”라는 뜻으로, 사실 아무 의미가 없습니다.
모든 SLA를 공식적으로 성문화해서 상세히 기술할 필요는 없습니다. SLA를 유지하기가 어려울 수 있지만 SLA가 아예 없다면 큰 공백이 존재하게 됩니다. 모든 기업에는 현재 데이터 보호 대책에서 무엇을 기대할 수 있는지에 관한 공통된 이해가 있어야 합니다. 데이터가 어떻게 보호되는지에 관한 생산, 관리, 중간 관리, 경영진 및 회사 소유자의 기대치는 당연히 서로 다릅니다. 이들이 모두 데이터가 언제나 안전하고 사용 가능하며 절대 손실되지 않을 것이라고 생각한다면 뭔가 잘못되었다는 신호입니다.
실수 3. IT가 단독으로 SLA 작성
SLA가 전적으로 IT 부서에 의해 작성되는 경우도 종종 있습니다. 이것이 왜 실수일까요? 여러분이 데이터 보호를 책임지는 IT 관리자라면 여러분이 하고 있는 일에 대해 얼마나 정직하게 경영진에게 말할 수 있을까요? 특히 IT 관리자가 충분한 툴 또는 예산도 받지 못한 상태에서 회사 데이터가 다양한 유형의 재해에 대해 제대로 보호되고 있지 않다는 사실을 보고해야 하는 경우를 생각해 보십시오.
적절한 SLA는 부정적인 특정 시나리오나 이벤트를 기술하고 이를 극복하기 위한 기대치를 설정합니다. 예를 들어, 사용자가 실수로 파일을 삭제할 경우 이들은 어떤 일이 일어날 것으로 예상할까요? 당연히 IT팀이 파일을 복원해줄 것이라고 기대합니다. 하지만 보기만큼 간단한 문제가 아닙니다. 사용자는 한 시간 전 버전이 복구될 것으로 기대할까요, 아니면 일주일 전 버전을 기대할까요? 하루 종일 문서 작업을 하던 중 갑자기 노트북이 멈춘 CFO라면 아마도 전자를, 월별 스프레드시트를 업데이트하는 보고서 관리자라면 후자를 기대할 것입니다.
SLA의 목적은 실질적인 비즈니스 요구를 기대치로 변환하는 것입니다. 중요한 직책의 직원들이 작업하는 중요한 문서라면 하루에 한 번 이상 백업하는 것이 합리적일 것입니다. 그러나 SLA는 하나의 문서보다 훨씬 더 넓은 범위에 적용됩니다. 영업 데이터베이스가 다운되어 복구해야 하는 경우에는 이야기가 달라집니다. 사용 가능한 데이터베이스 버전을 찾기 위해 얼마나 과거로 돌아가야 할까요? 순서를 바꿔서, 데이터베이스가 다시 정상 가동되기까지 시간이 얼마나 걸릴까요?
따라서 SLA에서는 일반적으로 2가지의 중요한 사항을 다룹니다. 하나는 재해가 발생할 경우 어느 정도의 데이터 손실을 용납할 수 있는지, 다른 하나는 프로덕션이 재개되기까지 얼마나 시간이 걸리는지입니다. 데이터가 전혀 손실되지 않고 다운타임도 전혀 없기를 바라겠지만 자동화할 수 없는 작업도 있습니다. 데이터 손실과 다운타임이 전혀 없도록 하려면 누군가가 하루 24시간 자리를 지켜야 합니다.
SLA 작성의 어느 시점이 되면 데이터 보호의 현실적, 재정적 한계에 도달하게 됩니다. 보호를 더 강화할 수 있는 여지는 항상 존재하지만 얼만큼의 비용을 지출할 수 있는지가 관건입니다.
다양한 위치에 있는 이해관계자와의 면담을 기반으로 한 독립적인 회사의 가이드는 기대치를 설정하는 데 도움이 될 수 있습니다. 이 회사가 모든 것을 구현할 수는 없겠지만 적어도 조직이 일체화되어 움직일 수는 있습니다.
실수 4. 백업과 재해 복구의 융합
기업의 백업과 재해 복구 계획은 서로 별개입니다. 데이터 백업은 프로덕션 환경의 복사본을 만들어 안전한 위치에 저장해 변경할 수 없도록 하는 것입니다. 반면 재해 복구는 두어 대의 시스템부터 데이터 센터 전체에 이르는 가동 중단 사태로부터 신속하게 복구하는 역량을 의미합니다. 즉, 백업은 데이터 지향적이고 재해 복구는 환경 지향적입니다. 백업이 있으면 가상 머신과 같은 특정 형식으로 데이터를 복원할 수 있지만 장애가 발생한 하드웨어를 백업으로 대체할 수는 없습니다.
여기서 주된 실수는 백업을 재해 복구용으로 사용할 수 있을 것이라는 생각입니다. 백업은 재해 복구의 일부가 될 수 있지만 둘은 동일하지 않습니다.
마찬가지로, 복원과 복구 역시 종종 융합됩니다. 복원은 이전 버전의 데이터를 원래 위치로 되돌립니다. 예를 들어 워드 문서라면 백업에서 복원이 가능합니다. 그러나 애플리케이션이 없다면 문서를 열 수 없습니다. 복원으로 문서를 다시 가져왔지만 문서에 대한 액세스는 가져오지 못했기 때문입니다. 문서와 문서에 대한 액세스를 모두 복원하려면 그 다음 수준인 복구가 필요합니다.
실수 5. 복구를 테스트하지 않음
백업은 사실상 매일 수동적으로 테스트됩니다. 여기서 실패할 경우 백업 소프트웨어가 사용자에게 실패를 알립니다. 그러나 복구 테스트는 수동적이기보다는 능동적인 연습을 필요로 합니다. 하나의 문서든 전체 데이터베이스든 데이터 복원을 테스트하는 것은 실익이 없습니다. 위에서 설명했듯이 파일을 복원할 수 있지만 그 파일 안의 데이터에 액세스할 수 있을까요? 이 부분은 복구를 테스트해야만 테스트할 수 있으며, 이는 애플리케이션 또는 프론트 엔드를 실행하고 파일 안의 데이터를 성공적으로 읽는 것까지 확장됩니다.
복구 테스트는 중요하지만, 시간이 많이 소비됩니다. 예를 들어, IT 자산에 100개의 가상머신이 포함돼 있다면 몇 개에 대해 복원을 테스트해야 할까요? 1개, 2개, 5개? 모두에 대해 복원을 테스트하는 데는 너무 많은 시간이 걸리므로 샘플을 선택해야 합니다. 따라서 재해 복구 위험을 줄이기 위한 노력에도 위험이 따릅니다.
실수 6. IT 부서를 대상으로 한 데이터 보호 교육에 소홀
데이터 보호는 그다지 흥미로운 주제가 아니지만 매우 중요합니다. 시스템 관리자와 IT 담당자는 회사의 데이터 보호 방법을 얼마나 이해하고 있나요? 관리자는 위험 경보가 울릴 때 무엇을 해야 할지 대부분 잘 압니다. 그러나 SLA, 재해 복구, 그리고 특정 서버가 다운될 경우 영향을 받는 부서가 어디인지 아는 것까지 자신의 업무라는 것을 알아두는 것이 좋습니다.
IT팀의 데이터 보호 스킬셋을 개발하면 비즈니스 요구사항의 변화를 예상하고 인지할 수 있는 팀이 될 수 있습니다. 데이터를 백업하는 데 걸리는 시간이 갈수록 길어진다는 사실을 상기시키는 사람들을 고려해 보십시오. 현명한 IT 관리자라면 그 이야기를 듣고 조직이 프로덕션 시스템과 함께 백업 소프트웨어와 하드웨어를 성장시키고 있는지 여부를 생각해볼 것입니다.
폭넓은 교육을 받은 백업 관리자는 비즈니스 요구사항에 비추어 SLA를 평가할 수 있습니다. 이들은 비현실적인 SLA를 지적하고 가동 중단이 발생하더라도 회사가 비즈니스 연속성을 유지할 가능성을 높일 수 있습니다.
결론
일반적인 데이터 백업 실수의 핵심은 결국 데이터 백업 관행과 기술을 되돌아보지 않고 방치하는 것입니다. 혁신의 시대에 IT팀은 더 효과적이고 견고하며 자동화된 백업을 위해 무엇을 할 수 있을까요? 중복 제거, 암호화, 불변성 백업과 같은 기술은 현대적 데이터 보호의 일부이며, 이를 활용하지 않는 것은 실수입니다.
데이터 백업 및 보호의 필요성은 과소평가되고 비즈니스와 조직의 빠른 변화 속에서 충분한 관심을 받지 못하는 경우가 많습니다. 회사가 성장함에 따라 IT 사용이 증가하는 상황에서 누구도 “지금 데이터 보호에 필요한 것을 갖추고 있는가?”, “더 나은 것이 필요한가, 다른 것이 필요한가?”와 같은 불편한 질문을 던지지 않는다면 기업은 정작 복구가 필요할 때, 또는 재해가 발생했을 때 준비가 제대로 되어 있지 않은 상황에 처하게 됩니다. 비즈니스 방식이 변화하면 더 높은 수준에서 데이터를 보호하는 방식도 영향을 받게 됩니다.
백업 관리에 어려움을 겪고 계시거나 관련 솔루션에 대해 궁금한 점이 있으시면 언제든 퀘스트소프트웨어코리아로 문의주시기 바랍니다.
Quick Overview
데이터 백업은 비즈니스 연속성을 위해 중요하지만, 백업과 보호의 중요성은 종종 과소평가되고 여러 기술적 혁신 속에서 관심을 받지 못하는 경우가 많습니다. 기업은 데이터 보호를 높은 수준에서 노력하고, 비즈니스 변화에 따라 데이터 보호 방식을 조정해야 합니다. 여기서는 올바른 백업을 위해 피해야 할 6가지 실수를 살펴봅니다.
백업은 IT 인프라의 핵심 요소입니다. 그러나 백업은 데이터 손실이 발생하거나 다른 재해가 닥치기 전까지 낮은 우선 순위로 뒷전으로 밀리는 경우가 많습니다. 백업이 뒷전으로 밀리면 조직적인 실수가 발생하여 비즈니스 중단으로 이어질 수 있습니다. 이번 포스팅에서는 기업에서 백업과 관련하여 흔히 저지르는 다음과 같은 실수와 이를 방지하는 데 도움이 되는 제안을 살펴봅니다.
실수 1. IT 부서가 비즈니스 요구사항을 무시하는 백업 의사 결정을 내림
많은 기업에서 IT 부서 또는 기술 파트너는 백업 구현을 많건 적건 직접 담당합니다. 또한 데이터 보호가 기업에 즉각적인 혜택이 되지 않는 비용 센터로 간주되므로 백업에 대한 예산은 논쟁의 대상이 되는 경우가 많습니다. 여기서 발생하는 실수는 백업 대상, 데이터 보존 기간, 백업의 우선 순위에 대한 의사 결정을 전적으로 IT 부서가 내리도록 하는 것입니다.
이런 실수의 근본적인 원인은 데이터 보호에 대한 경영진의 시각과 담당 IT 부서의 생각이 다르다는 데 있습니다. 농업, 제철, 영화 제작, 가구 제조 등 업종을 불문하고 경영진은 비즈니스에, IT 부서는 그 비즈니스 운영을 지원하는 기술에 각각 초점을 맞춘다는 데서 불일치가 발생합니다. IT가 비즈니스를 움직이기 위한 단순한 메커니즘 또는 수단이 될 때 데이터 보호의 중요성에 대한 오해가 발생할 가능성이 높아집니다.
백업에 대한 의사 결정은 데이터 보호에 대한 회사의 현재 요구사항을 기반으로 내리는 것이 더 적절하며, 이는 IT 부서가 비즈니스와 함께 이 의사 결정에 참여하는 것을 전제로 합니다.
예를 들어, 기업의 온프레미스 이메일 관리가 마이크로소프트 365의 클라우드 패러다임으로 발전하자 많은 사람들은 더 이상 이 데이터를 보호할 필요가 없다고 생각했습니다. 이 기능이 아웃소싱되므로 마이크로소프트가 보호해줄 것으로 전제했기 때문입니다. 그러나 얼마 지나지 않아 클라우드에 둔다 해도 그것은 여전히 자신의 데이터이며 따라서 그 데이터를 보호할 주된 책임도 기업 자체에 있음이 분명해졌습니다.
실제로 기업은 기능과 스토리지를 위해 클라우드를 사용하지만, 그렇다 해도 데이터를 보호해야 할 의무가 사라지는 것은 아닙니다. 마이크로소프트는 플랫폼을 제공하고 이 플랫폼의 가용성을 유지하기 위해 최선의 노력을 다합니다. 플랫폼에서 조직의 실수로 데이터를 잃는다면 마이크로소프트에 책임을 물을 수 없습니다. 결과적으로, IT 부서는 더 이상 온프레미스에 위치하지 않는 데이터와 애플리케이션을 위한 데이터 보호 환경을 구축하기 위한 예산이 필요하게 되었습니다.
회사의 유형에 따라 데이터 백업에 대한 IT 부서와 경영진 간의 시각 차이는 더 클 수 있습니다. 또한 고위 경영진이 현실과 달리 모든 것이 보호되고 있다고 생각하고 여기서 간극일 발생할 수도 있습니다.
일반적으로 무엇을 보관하고 무엇을 버려야 할지 IT 부서가 알기를 기대하는 것은 적절하지 않습니다. 또한 IT 부서는 보관해야 할 데이터를 얼마나 오래 보관해야 하는지도 모를 가능성이 높습니다. IT 부서가 아는 것은 모든 데이터를 영구적으로 보관하기에는 너무 많은 비용이 든다는 점입니다.
게다가 디지털 개인정보 보호 권리도 무엇을 보관하고 버릴지에 대해 영향을 미치므로 IT 부서가 직면하는 문제는 더욱 복잡해집니다. GDPR과 같은 규정은 기업이 비즈니스와 무관한 데이터를 보관하는 것을 금지하는데, 더 이상 관련성이 없는 것으로 간주되는 데이터가 여전히 장기 스토리지에 남아 있는 경우 데이터 백업 맥락에서 이 규정대로 시행하기가 까다롭게 됩니다.
실수 2. 문제 발생 시 기대치를 설정하기 위한 SLA의 부재
SLA의 역할은 특정 시나리오에서 IT 부서가 제공할 수 있는 부분에 대한 모두의 기대치를 설정하는 것입니다. 이 맥락에서 일반적인 SLA는 IT 부서가 특정 문제를 복구하기 위해 필요한 시간과 같은 요소를 다룹니다. 사용자가 실수로 파일을 삭제하여 IT 부서가 이 파일을 복구해야 하는 경우를 가정해 봅시다. 회사는 가장 최근에 백업된 버전을 복구하기 위한 SLA를 가령 3시간으로 설정할 수 있습니다.
최악의 시나리오는 아예 SLA가 없는 것입니다. 이는 데이터 손실, 랜섬웨어, 홍수, 화재 및 기타 문제에 대해 비즈니스가 어떻게 보호되는지에 관한 공통된 이해가 없음을 의미합니다. 기본적으로 “최선의 노력 SLA”라고 할 수 있는데 이 말은 “건물에 화재가 발생한다면 데이터를 복구하기 위해 최선을 다할 것”라는 뜻으로, 사실 아무 의미가 없습니다.
모든 SLA를 공식적으로 성문화해서 상세히 기술할 필요는 없습니다. SLA를 유지하기가 어려울 수 있지만 SLA가 아예 없다면 큰 공백이 존재하게 됩니다. 모든 기업에는 현재 데이터 보호 대책에서 무엇을 기대할 수 있는지에 관한 공통된 이해가 있어야 합니다. 데이터가 어떻게 보호되는지에 관한 생산, 관리, 중간 관리, 경영진 및 회사 소유자의 기대치는 당연히 서로 다릅니다. 이들이 모두 데이터가 언제나 안전하고 사용 가능하며 절대 손실되지 않을 것이라고 생각한다면 뭔가 잘못되었다는 신호입니다.
실수 3. IT가 단독으로 SLA 작성
SLA가 전적으로 IT 부서에 의해 작성되는 경우도 종종 있습니다. 이것이 왜 실수일까요? 여러분이 데이터 보호를 책임지는 IT 관리자라면 여러분이 하고 있는 일에 대해 얼마나 정직하게 경영진에게 말할 수 있을까요? 특히 IT 관리자가 충분한 툴 또는 예산도 받지 못한 상태에서 회사 데이터가 다양한 유형의 재해에 대해 제대로 보호되고 있지 않다는 사실을 보고해야 하는 경우를 생각해 보십시오.
적절한 SLA는 부정적인 특정 시나리오나 이벤트를 기술하고 이를 극복하기 위한 기대치를 설정합니다. 예를 들어, 사용자가 실수로 파일을 삭제할 경우 이들은 어떤 일이 일어날 것으로 예상할까요? 당연히 IT팀이 파일을 복원해줄 것이라고 기대합니다. 하지만 보기만큼 간단한 문제가 아닙니다. 사용자는 한 시간 전 버전이 복구될 것으로 기대할까요, 아니면 일주일 전 버전을 기대할까요? 하루 종일 문서 작업을 하던 중 갑자기 노트북이 멈춘 CFO라면 아마도 전자를, 월별 스프레드시트를 업데이트하는 보고서 관리자라면 후자를 기대할 것입니다.
SLA의 목적은 실질적인 비즈니스 요구를 기대치로 변환하는 것입니다. 중요한 직책의 직원들이 작업하는 중요한 문서라면 하루에 한 번 이상 백업하는 것이 합리적일 것입니다. 그러나 SLA는 하나의 문서보다 훨씬 더 넓은 범위에 적용됩니다. 영업 데이터베이스가 다운되어 복구해야 하는 경우에는 이야기가 달라집니다. 사용 가능한 데이터베이스 버전을 찾기 위해 얼마나 과거로 돌아가야 할까요? 순서를 바꿔서, 데이터베이스가 다시 정상 가동되기까지 시간이 얼마나 걸릴까요?
따라서 SLA에서는 일반적으로 2가지의 중요한 사항을 다룹니다. 하나는 재해가 발생할 경우 어느 정도의 데이터 손실을 용납할 수 있는지, 다른 하나는 프로덕션이 재개되기까지 얼마나 시간이 걸리는지입니다. 데이터가 전혀 손실되지 않고 다운타임도 전혀 없기를 바라겠지만 자동화할 수 없는 작업도 있습니다. 데이터 손실과 다운타임이 전혀 없도록 하려면 누군가가 하루 24시간 자리를 지켜야 합니다.
SLA 작성의 어느 시점이 되면 데이터 보호의 현실적, 재정적 한계에 도달하게 됩니다. 보호를 더 강화할 수 있는 여지는 항상 존재하지만 얼만큼의 비용을 지출할 수 있는지가 관건입니다.
다양한 위치에 있는 이해관계자와의 면담을 기반으로 한 독립적인 회사의 가이드는 기대치를 설정하는 데 도움이 될 수 있습니다. 이 회사가 모든 것을 구현할 수는 없겠지만 적어도 조직이 일체화되어 움직일 수는 있습니다.
실수 4. 백업과 재해 복구의 융합
기업의 백업과 재해 복구 계획은 서로 별개입니다. 데이터 백업은 프로덕션 환경의 복사본을 만들어 안전한 위치에 저장해 변경할 수 없도록 하는 것입니다. 반면 재해 복구는 두어 대의 시스템부터 데이터 센터 전체에 이르는 가동 중단 사태로부터 신속하게 복구하는 역량을 의미합니다. 즉, 백업은 데이터 지향적이고 재해 복구는 환경 지향적입니다. 백업이 있으면 가상 머신과 같은 특정 형식으로 데이터를 복원할 수 있지만 장애가 발생한 하드웨어를 백업으로 대체할 수는 없습니다.
여기서 주된 실수는 백업을 재해 복구용으로 사용할 수 있을 것이라는 생각입니다. 백업은 재해 복구의 일부가 될 수 있지만 둘은 동일하지 않습니다.
마찬가지로, 복원과 복구 역시 종종 융합됩니다. 복원은 이전 버전의 데이터를 원래 위치로 되돌립니다. 예를 들어 워드 문서라면 백업에서 복원이 가능합니다. 그러나 애플리케이션이 없다면 문서를 열 수 없습니다. 복원으로 문서를 다시 가져왔지만 문서에 대한 액세스는 가져오지 못했기 때문입니다. 문서와 문서에 대한 액세스를 모두 복원하려면 그 다음 수준인 복구가 필요합니다.
실수 5. 복구를 테스트하지 않음
백업은 사실상 매일 수동적으로 테스트됩니다. 여기서 실패할 경우 백업 소프트웨어가 사용자에게 실패를 알립니다. 그러나 복구 테스트는 수동적이기보다는 능동적인 연습을 필요로 합니다. 하나의 문서든 전체 데이터베이스든 데이터 복원을 테스트하는 것은 실익이 없습니다. 위에서 설명했듯이 파일을 복원할 수 있지만 그 파일 안의 데이터에 액세스할 수 있을까요? 이 부분은 복구를 테스트해야만 테스트할 수 있으며, 이는 애플리케이션 또는 프론트 엔드를 실행하고 파일 안의 데이터를 성공적으로 읽는 것까지 확장됩니다.
복구 테스트는 중요하지만, 시간이 많이 소비됩니다. 예를 들어, IT 자산에 100개의 가상머신이 포함돼 있다면 몇 개에 대해 복원을 테스트해야 할까요? 1개, 2개, 5개? 모두에 대해 복원을 테스트하는 데는 너무 많은 시간이 걸리므로 샘플을 선택해야 합니다. 따라서 재해 복구 위험을 줄이기 위한 노력에도 위험이 따릅니다.
실수 6. IT 부서를 대상으로 한 데이터 보호 교육에 소홀
데이터 보호는 그다지 흥미로운 주제가 아니지만 매우 중요합니다. 시스템 관리자와 IT 담당자는 회사의 데이터 보호 방법을 얼마나 이해하고 있나요? 관리자는 위험 경보가 울릴 때 무엇을 해야 할지 대부분 잘 압니다. 그러나 SLA, 재해 복구, 그리고 특정 서버가 다운될 경우 영향을 받는 부서가 어디인지 아는 것까지 자신의 업무라는 것을 알아두는 것이 좋습니다.
IT팀의 데이터 보호 스킬셋을 개발하면 비즈니스 요구사항의 변화를 예상하고 인지할 수 있는 팀이 될 수 있습니다. 데이터를 백업하는 데 걸리는 시간이 갈수록 길어진다는 사실을 상기시키는 사람들을 고려해 보십시오. 현명한 IT 관리자라면 그 이야기를 듣고 조직이 프로덕션 시스템과 함께 백업 소프트웨어와 하드웨어를 성장시키고 있는지 여부를 생각해볼 것입니다.
폭넓은 교육을 받은 백업 관리자는 비즈니스 요구사항에 비추어 SLA를 평가할 수 있습니다. 이들은 비현실적인 SLA를 지적하고 가동 중단이 발생하더라도 회사가 비즈니스 연속성을 유지할 가능성을 높일 수 있습니다.
결론
일반적인 데이터 백업 실수의 핵심은 결국 데이터 백업 관행과 기술을 되돌아보지 않고 방치하는 것입니다. 혁신의 시대에 IT팀은 더 효과적이고 견고하며 자동화된 백업을 위해 무엇을 할 수 있을까요? 중복 제거, 암호화, 불변성 백업과 같은 기술은 현대적 데이터 보호의 일부이며, 이를 활용하지 않는 것은 실수입니다.
데이터 백업 및 보호의 필요성은 과소평가되고 비즈니스와 조직의 빠른 변화 속에서 충분한 관심을 받지 못하는 경우가 많습니다. 회사가 성장함에 따라 IT 사용이 증가하는 상황에서 누구도 “지금 데이터 보호에 필요한 것을 갖추고 있는가?”, “더 나은 것이 필요한가, 다른 것이 필요한가?”와 같은 불편한 질문을 던지지 않는다면 기업은 정작 복구가 필요할 때, 또는 재해가 발생했을 때 준비가 제대로 되어 있지 않은 상황에 처하게 됩니다. 비즈니스 방식이 변화하면 더 높은 수준에서 데이터를 보호하는 방식도 영향을 받게 됩니다.
백업 관리에 어려움을 겪고 계시거나 관련 솔루션에 대해 궁금한 점이 있으시면 언제든 퀘스트소프트웨어코리아로 문의주시기 바랍니다.