기업 데이터 백업 3-2-1 전략, 중소기업에서의 실제 적용

지난달 순이구에서 자동차 부품을 생산하는 무역 기업이 저희를 찾아왔습니다. IT 책임자인 라오저우는 사무실에 들어서자마자 한숨을 내쉬었습니다. “서버가 잠겼습니다. 공급업체는 견적서를 재촉하고, 고객사 주문도 막혀 있는데 랜섬웨어가 비트코인 3개를 요구합니다. 줄까요, 말까요?” 이런 상황을 지난 2년간 저희는 열 건 넘게 처리했습니다. 라오저우는 결국 돈을 주지 않고 백업 복구를 선택했습니다. 하지만 그 대가는 다운타임 72시간이었고, 업무 손실에 긴급 야근 수당까지 더하면 40만 위안을 넘었습니다. 백업 전략이 조금만 더 탄탄했다면 충분히 아낄 수 있었던 돈입니다. 오늘 이 이야기를 꺼낸 것은 누군가를 겁주려는 게 아니라, 저희가 직접 겪은 실제 사례로 중소기업이 백업 체계를 어떻게 구축해야 하는지 분명히 말씀드리기 위해서입니다.

3-2-1 전략: 교리가 아니라 최소 기준

3-2-1 백업 원칙은 간단합니다. 데이터 사본 세 개를 서로 다른 두 종류의 매체에 저장하고, 그중 하나는 다른 지역에 두는 것입니다. 많은 분이 대기업이나 할 수 있는 일이라고 생각하지만 그렇지 않습니다. 라오저우의 기업을 예로 들면, 기존 방식은 매일 퇴근 전에 외장 하드를 서버에 꽂고 수동으로 데이터를 복사해 가져가는 것이었습니다. 듣기에는 ‘다른 지역’도 있는 것 같지만 실제로는 하드를 자주 꽂는 걸 잊고, 복사가 자주 중단되고, 심지어 복사 도중에 뽑아서 가버리기도 했습니다. 이런 ‘수동 백업’은 석 달 연속 아무도 로그를 확인하지 않은 끝에 결국 여섯 달째에 터지고 말았습니다.

사본 세 개의 본질은 ‘재해 대비 이중화’입니다. 첫 번째는 운영 환경의 원본 데이터이고, 두 번째는 NAS나 백업 서버 같은 로컬 사본으로 빠른 복구가 목적이며 실수로 삭제하거나 파일이 손상되는 빈번한 사고에 대응합니다. 세 번째는 반드시 다른 지역에 두어야 하며, 클라우드 스토리지나 다른 사무실을 활용할 수 있습니다. 핵심은 ‘매체 격리’입니다. 로컬 백업과 원본 데이터가 같은 물리 장비에 있으면 그 장비가 랜섬웨어에 암호화되는 순간 두 사본이 동시에 무용지물이 됩니다.

오프라인 백업은 최근 많이 언급되는데, 랜섬웨어가 점점 영리해져 LAN 안의 매핑 드라이브와 백업 장비를 스스로 스캔하기 때문입니다. 관리자 권한을 얻으면 NAS 안의 데이터까지 암호화됩니다. 그래서 콜드 백업(오프라인 테이프나 완전히 전원을 끈 하드디스크)은 고도화된 위협에 맞서는 마지막 방어선입니다. 중소기업이라면 매주 금요일 퇴근 전에 백업 하드 하나를 뽑아 집에 가져가는 것만으로 충분합니다. 5분도 걸리지 않지만 목숨을 구할 수 있습니다.

RTO와 RPO: 두 가지 질문에 먼저 답하세요

백업 아키텍처를 설계하기 전에 IT 책임자는 경영진과 두 가지 숫자를 맞춰야 합니다. RTO(복구 시간 목표)와 RPO(복구 시점 목표)입니다. RTO는 ‘재해 발생부터 업무 재개까지 최대 얼마나 허용할 수 있는가’, RPO는 ‘최대 얼마만큼의 데이터 손실을 허용할 수 있는가’를 뜻합니다. 이 두 지표가 어떤 백업 방식을 택할지 직접 결정합니다.

저희는 보통 고객에게 세 가지를 묻습니다. 핵심 업무 시스템이 한 시간 멈추면 손실이 대략 얼마입니까? 어제 하루치 데이터 손실을 감수할 수 있습니까, 아니면 최근 한 시간치만 감수할 수 있습니까? 데이터 보호에 투입할 예산은 얼마입니까? 답에 따라 설계는 크게 달라집니다.

1. RTO가 4시간 이내, RPO가 1시간 이내를 요구한다면 실시간 복제 또는 이에 준하는 연속 데이터 보호(CDP)가 필요합니다. 비용은 높지만 업무 중단을 거의 체감할 수 없습니다.
2. RTO가 1일 이내, RPO가 24시간이라면 하루 한 번 전체 백업에 몇 시간마다 증분 백업을 더하는 것으로 충분하며 비용도 낮게 유지할 수 있습니다.
3. 며칠간의 다운타임을 감수할 수 있는 업무라면 백업 전략은 더 단순해도 됩니다. 다만 이 경우 오프라인 사본의 보안을 반드시 확보해야 합니다. 다운타임이 길다는 것은 공격자에게 그만큼 많은 기회가 주어진다는 뜻이기 때문입니다.

다싱에 교육 훈련 기관이 하나 있었습니다. 사장은 자기 업무가 ‘그렇게 중요하지 않다’고 생각해 RTO를 72시간으로 정했습니다. 그런데 작년 말 서버가 감염된 뒤에야 백업이 매주 일요일 한 번이라는 사실을 알게 됐고, 수요일에 암호화된 데이터를 지난 일요일 상태로 되돌려야 했습니다. 사흘치 등록 기록과 과정 변경 기록이 전부 사라졌습니다. 학부모 단체방은 난리가 났고, 환불 금액에 재수강 편성 비용까지 더하니 손실은 전문 백업 소프트웨어 한 세트 가격을 훨씬 넘었습니다.

백업 소프트웨어 선택: 맞는 것이 옳은 것

시중의 백업 소프트웨어는 무료부터 수십만 위안까지 다양합니다. 중소기업이 가장 자주 빠지는 함정은 두 가지입니다. 하나는 기능이 복잡한 ‘엔터프라이즈급’ 제품을 사놓고 IT 담당자가 제대로 쓰지 못해 여덟 할의 기능이 놀고 있는 경우, 다른 하나는 저렴하다는 이유로 마이너 오픈소스 도구를 골랐다가 문제가 생겼을 때 기술 지원을 받을 곳이 없고 문서가 5년 전에 멈춰 있는 경우입니다.

저희가 중소기업에 권하는 선정 기준은 이렇습니다. 먼저 운영체제 호환성입니다. 서버가 Windows인지 Linux인지, 데이터베이스가 MySQL인지 SQL Server인지가 소프트웨어가 돌아가느냐를 결정합니다. 다음으로 복구 시나리오의 범위입니다. 파일 단위 복구, 전체 시스템 복구, 데이터베이스 시점 복구 중 최소 두 가지는 지원해야 합니다. 마지막으로 관리 복잡도입니다. 그래픽 인터페이스로 조작할 수 있는 것을 고르고, 여러 대를 중앙에서 관리할 수 있는 것을 고르세요. 한 대씩 설정하러 다닐 필요가 없습니다.

귀사에 이미 네트워크 장비 패키지 서비스 계약이 있다면 백업 시스템도 함께 설계할 수 있습니다. 정책을 일괄 배포하고 모니터링과 알림을 통합하면 이후 운영이 훨씬 수월해집니다.

익명 처리 사례: 순이구 그 공장의 72시간

서두에 언급한 라오저우의 기업으로 돌아가 보겠습니다. 그들의 IT 환경은 이랬습니다. 물리 서버 한 대가 ERP와 파일 공유를 돌리고, 백업은 서버 내장 RAID 1에 매일 수동으로 복사하는 외장 하드 하나가 전부였습니다. 침입 경로는 피싱 메일이었고, 행정 담당 직원이 ‘택배 수령 확인서’를 클릭했습니다. 악성코드는 이틀간 잠복하다가 금요일 저녁 업무 피크 시간에 측면 확산을 시작해 서버에서 접근 가능한 모든 공유 파일을 암호화했습니다.

다음 날 아침 IT 담당자가 점검하다 발견한 것은, RAID 어레이의 두 디스크 중 하나가 언제인지 모르게 이미 이탈해 있어 데이터는 단일 디스크 사본만 남았고, 외장 하드는 서버 USB 포트에 꽂힌 채 함께 암호화됐다는 사실이었습니다. 어떻게 해야 할까요? 석 달 전 클라우드 백업부터 복구를 시작하는 수밖에 없었습니다. 전체 백업이다 보니 복구 속도가 느렸고, 서버 신규 구매와 시스템 재배포, 데이터 이관까지 겹쳤으며, 중간에 손상된 백업 파일의 폴더 몇 개는 수동으로 다시 입력해야 했습니다. 꼬박 사흘 동안 업무는 사실상 멈췄습니다.

사후 분석 후 그들은 세 가지를 바꿨습니다. 첫째, 불변(immutable) 기능이 있는 클라우드 백업을 도입해 관리자 권한으로도 30일 이내 백업 사본을 삭제할 수 없게 했습니다. 둘째, 백업 NAS를 별도 VLAN으로 분리해 운영 네트워크와 격리했고 랜섬웨어가 직접 스캔할 수 없게 했습니다. 셋째, 월 1회 백업 복구 훈련을 제도화해 백업의 가용성을 검증했습니다. 투자 금액은 대략 3만 위안 남짓이었지만, 그 대가로 얻은 것은 다시 감염되더라도 최대 1시간의 데이터 손실, 8시간 이내 핵심 업무 복구입니다.

데이터 백업은 언제나 ‘사고가 나야 중요성을 알게 되는’ 일입니다. 하지만 현명한 방법은 사고가 난 뒤에 셈을 하는 것이 아니라 작은 투자로 큰 보장을 사는 것입니다. 자사 백업 방식을 검토 중이고 판단이 어려운 부분이 있다면 문의해 주세요. 현재 상태를 함께 점검하고 어디에 구멍이 있는지 확인해 드리겠습니다.