빅데이터와 인공지능 분석 기술이 확산하게 되면서 기업이 보유한 데이터의 활용도와 가치가 갈수록 높아지고 있습니다. 또한, 클라우드 서비스를 기반으로 한 사업 모델이 보편화되면서 기업의 비즈니스 환경이 전보다 복잡해지고, 생성되는 데이터의 크기와 종류가 다양해지고 있습니다. 이처럼 데이터 분석과 클라우드를 기반으로 한 비즈니스가 유례없이 거대해지고 있지만, 동시에 데이터 손실에 따른 피해 규모 또한 높아지고 있습니다.

여기서 말하는 데이터 손실이란 원본 데이터의 손실로 인해 복구가 어려운 상태를 말합니다. 보통 하드웨어 장애나 데이터 깨짐, 버그 등과 같은 내부 요인과 사용자의 실수나 재해, 랜섬웨어와 같은 외부적인 요인으로 인해 발생합니다.

글로벌 보안 컨설팅 업체인 Ponemon Institute에 의하면, 지난 2020년 전 세계적으로 데이터 유출로 인한 기업의 평균 피해 금액이 무려 386만 달러(약 45억 원)였다고 합니다1. 게다가 백업 소프트웨어 기업인 Veeam의 보고서에 의하면, 2020년 다운타임으로 발생한 기업의 손실은 시간당 약 84,650 달러(약 1억원)에 달한다고 합니다2. 기업 입장에서는 단순히 금전적인 손실뿐만이 아니라, 고객들의 신뢰와 브랜드 이미지에도 타격을 받게 됩니다. 이 때문에 기업들은 항상 데이터 손실과 서비스 다운이라는 최악의 상황을 상정하고 자사의 IT 인프라에 가장 적합한 데이터 백업 및 복구 계획을 수립하고 있습니다.

 

데이터 백업이란

데이터 백업은 원본 데이터를 잃게 되는 상황에 대비해 다른 위치에 안전하게 복제해 놓은 사본 데이터를 말합니다. 원본 데이터에 문제가 발생할 시 사본 데이터를 통해 신속하게 원래의 상태로 복구하는 것이 주목적으로, 이와 같은 일련의 작업을 재해 복구(disaster recovery)라고 합니다.

백업 작업은 주로 백업 전용 어플라이언스(Purpose-Built Backup Appliance, 이하 PBBA)에서 관리합니다. 현재는 하드디스크 기반의 백업 어플라이언스가 주류를 이루고 있지만, 2000년대만 해도 많은 기업들이 테이프 기반의 스토리지를 주요 백업 스토리지로 사용해 왔습니다. 요즘에도 테이프 스토리지를 활용하기는 하지만 주로 빠른 복구가 필요 없는 데이터를 장기 보관하기 위한 아카이브 용도로 사용되고 있습니다. SSD의 경우에는 내구성과 가격 때문에 주 저장용으로 활용하기보다는 주로 캐싱이나 티어링 기능을 목적으로 하드디스크와 같이 활용됩니다.

최근에는 로컬에 백업 시스템을 구축하고 운용하는 비용보다 클라우드 기반 백업 서비스(Backup-as-a-Service, 이하 BaaS)를 쓰는 것이 더 저렴해 클라우드 서비스의 비중이 증가하고 있는 추세입니다. ESG Research의 보고서에 따르면, 조사에 응답한 기업 중 BaaS를 도입한 기업이 2016년에는 39%에 불과했던 반면, 2021년에는 전체의 절반 이상인 69%가 BaaS를 도입했다고 합니다3. 백업 서비스 프로바이더에 백업 인프라의 관리 및 운영을 위임하기 때문에 유지비용이 비교적 저렴하고, 분산 환경과 체계적인 보안 시스템을 갖추기 때문에 데이터 보호 측면에 있어서도 비교적 뛰어나다고 볼수 있기 때문입니다.

 

백업 및 복구 정책

이와 같이 재해 복구에 대비한 데이터 백업은 중앙화된 IT 인프라 내에서 사전에 정해진 백업 정책에 따라 수행됩니다. 주로 생성할 사본의 수나 백업 빈도 및 스케줄, 복구 시간에 대한 서비스 수준 협약(Service Level Agreement, 이하 SLA) 등이 정해집니다. 그리고 IT 관리자는 자사 IT 환경 내 스토리지 공간, 네트워크 속도, 업무 시간, 관리 인력 등을 고려해 가장 적합한 백업 정책을 수립합니다.

백업의 목표

백업 시스템 도입 시 IT 관리자 입장에서는 문제 발생 시 얼마나 빨리 기존의 데이터를 복구하고 접근할 수 있는지가 가장 신경 쓰이기 마련입니다. 백업 대상인 데이터의 비즈니스적 의존도가 높을수록 재해 발생 시 데이터를 손실한 만큼의 피해가 발생하고, 데이터에 접근 못 하는 시간 동안 손실이 계속 발생하기 때문입니다. 이 때문에 관리자는 기업 입장에서 데이터 손실을 얼마나 허용할지와 데이터를 얼마나 빨리 복구해야 할지를 결정해야 합니다.

  • RPO(recovery point objective)는 재해로 인한 데이터 손실의 허용량에 따라 백업 주기의 간격을 결정하는 지표입니다. 백업 주기의 간격이 짧을수록 재해 발생 시 손실되는 데이터의 양이 적고, 주기가 길수록 손실될 데이터의 양은 비교적 많다고 볼 수 있습니다. 예를 들어 설정한 RPO가 24시간이면, 24시간 간격으로 백업이 수행됩니다.

  • RTO(recovery time objective)는 재해 발생 시점으로부터 복구까지 걸리는 시간을 얼마나 허용할 수 있는지를 나타내는 지표입니다. 예를 들어 설정한 RTO가 6시간이면 데이터에 접근 못 하는 시간이 6시간을 넘을 경우 기업이 감내하기 힘들다는 것입니다.

백업의 종류

백업의 빈도와 최소 복구 시간을 결정했으면 데이터 백업을 어떤 방식으로 수행할지에 대해 고민해 봐야 합니다. 백업 대상의 서버에 사용자가 몰리는 시간대와 보유한 시스템 리소스에 따라 RTO를 설정하고, 백업 수행 방안을 고려해야 합니다. 게다가, 백업 대상인 데이터를 RPO에 따라 모두 백업하게 되면 재해 발생 시 완전한 복구가 가능하겠지만, 그만큼 백업 수행에 걸리는 시간 및 시스템 리소스가 그대로 소모됩니다. 이 때문에 관리자는 기업이 요구하는 RPO와 RTO를 기준으로, 가지고 있는 시스템 리소스와의 균형을 고려한 백업 정책을 수립할 필요가 있습니다.

백업은 서비스의 운영 시간과 중요도에 따라 크게 콜드 백업과 핫 백업으로 구분할 수 있습니다. 콜드 백업(cold backup)은 서버의 운영을 중단한 상태에서 백업을 수행하는 것을 말하며, 다른 말로는 오프라인 백업이라고도 합니다. 서버를 운영하지 않는 상태에서 백업을 수행하기 때문에 시스템 리소스 활용에 제한이 없을뿐더러, 백업 도중에 변경되는 데이터가 없고 외부의 위협으로부터 안전하기 때문에 백업을 안정적으로 수행할 수 있습니다. 다만, 콜드 백업 수행 중에는 서버에 접근할 수 없다는 점과 콜드 백업으로부터 복구를 수행할 시 시간이 걸린다는 단점은 있습니다.

핫 백업(hot backup)은 서비스 운영과 함께 백업을 수행하는 것을 말합니다. 일반적인 데이터베이스 환경이나 서버를 24시간 내내 운영해야 하는 환경에서 주로 사용되며, 다이나믹 백업이라고도 합니다. 서비스 중단 없이 백업을 수행한다는 장점이 있지만, 백업 수행 시 스토리지 읽기 성능 부하로 서비스 운영에 지장을 줄 수 있다는 점과 백업 시점에 따라 변경된 데이터가 백업에 반영이 안 되는 경우가 있는 등의 단점이 있습니다. 이와 같은 단점을 보완하기 위해 대체로 사용자 접근이 적은 시간에 백업을 수행하는 방안을 수립합니다. 웜 백업(warm backup)과 같이 서버가 운영 중이나 접근이 많지 않을 때 백업을 수행하는 방법이 있습니다. 또는 사용자가 많은 주중에는 핫 백업을 수행하고, 사용자가 적은 주말에 콜드 백업을 수행하는 방법도 있습니다.

이처럼 서버 운영 상황에 따라 백업을 수행하는 방안을 알아보았는데요, 이번에는 백업을 한 번에 얼마나 수행할지에 대한 방안을 다음과 같이 소개해 보고자 합니다:

 

Alt text

< 전체 백업 예시 >

 

  • 전체 백업(full backup)은 말 그대로 원본 데이터 전체를 매번 백업하는 방식을 말합니다. 원본 전체가 백업되기 때문에 가장 신뢰도가 높은 방법이라고 볼 수 있습니다만, 그만큼 시간도 가장 많이 소모되고 한 번에 차지하는 스토리지 공간도 많습니다. 이 때문에 대부분은 전체 백업을 다른 백업 기능들과 병행해서 기간을 두고 설정합니다.

 

Alt text

< 증분 백업 예시 >

 

  • 증분 백업(incremental backup)은 매번 모든 데이터를 백업하지 않고 지난번 백업 데이터에서 추가 및 변경된 부분만 백업하는 방법입니다. 보통 전체 백업 주기 사이에 증분 백업을 설정하고, 증분 백업 전후로 중복되는 데이터가 없기 때문에 스토리지 공간과 백업 시간을 최소화할 수 있습니다. 다만, 증분 백업 데이터로 복구를 수행할 경우 시간이 오래 걸리는 단점이 있습니다.

 

Alt text

< 차등 백업 예시 >

 

  • 차등 백업(differential backup)은 지난번 전체 백업에서 추가된 부분을 모두 백업하는 방법으로, 이전 차등 백업 부분을 포함해 추가된 부분까지 백업하기 때문에 증분 백업과는 약간 다릅니다. 차등 백업 데이터로 복구하는 경우 증분 백업 방식에 비해 빠르다는 장점이 있습니다.

백업의 위치

백업 정책을 수립하기에 앞서 가장 먼저 결정이 필요한 사안 중 하나는 바로 백업의 위치입니다. 백업 데이터를 백업 대상(target)과 같은 로컬 환경(on-premise)에만 둘지, 또는 원격의 데이터센터(offsite)에도 둘지를 결정해야 합니다. 로컬 백업의 경우, 백업 스토리지가 백업 대상과 같은 내부 네트워크에 연결되어 있기 때문에 백업 속도와 관리 측면에서 이점을 가집니다. 원격 백업은 백업 스토리지가 외부의 데이터센터에 위치한 것을 말합니다. 로컬 백업과 같은 이점은 없지만, 로컬 데이터센터에서 재해가 발생했을 때 대비할 수 있다는 점이 있습니다. 게다가 퍼블릭 클라우드나 코로케이션 서비스를 활용하면 관리 비용까지 절감할 수 있습니다.

백업의 위치를 선정하는 데 있어서 가장 주목받아온 방법으로 3-2-1 법칙이라는 것이 있습니다. 3-2-1 법칙이란 3개의 데이터 사본을 2가지 유형의 스토리지에 저장하고 사본 중 최소 1개는 원격지에 저장하는 백업 방식을 말합니다. 많은 기업들은 3-2-1 법칙을 바탕으로 필요에 따라 원격지 백업을 2개 이상 두거나 하는 방향으로 도입하고 있습니다.

백업 대상이 로컬이 아니라 퍼블릭 클라우드와 같은 원격환경에 있을 수도 있습니다. SaaS와 같은 클라우드 서비스를 이용하는 경우, 보통 해당 SaaS 업체에서 백업 기능을 제공하기는 하지만 요구하는 SLA 등의 경우에 따라 비용이 비교적 많이 청구되고는 합니다. 이 때문에 타 클라우드 백업 서비스를 이용하는 Cloud-to-Cloud(C2C) 백업이 대안으로써 활용됩니다.

 

마치며

현대 IT 인프라에서 데이터 백업은 단순히 원본 데이터를 통째로 복사해 보관하는 것 이상으로 기업의 IT 환경에 알맞게 고도화된 정책을 구사하고 있습니다. 게다가 스냅샷, 이레이저 코딩, 압축 및 중복제거 등의 기술과 연계해 백업의 효율을 극대화하고 있습니다.

다음 포스트에서는 백업을 보완하는 기술과 활용 방안에 대해 다루어 보겠습니다.

 

참고

  • https://searchdatabackup.techtarget.com/definition/backup
  • https://www.veritas.com/ko/kr/information-center/data-backup-and-recovery

주석

  1. https://www.capita.com/sites/g/files/nginej291/files/2020-08/Ponemon-Global-Cost-of-Data-Breach-Study-2020.pdf ↩

  2. https://www.veeam.com/wp-2021-data-protection-trends.html?wpty ↩

  3. https://www.zerto.com/wp-content/uploads/2021/04/ESG-eBook-The-Evolution-of-Data-Protection-Cloud-Strategies-Zerto.pdf ↩