백업 보유율이 올라가도 복구는 실패한다
백업·복구 솔루션을 모두 갖춘 대형 전산센터에서도 사고가 터진 뒤 실제 복구에 실패하는 사례가 반복되면서, 논의의 초점이 '백업을 하고 있는가'에서 '복구가 되는가'로 옮겨가고 있습니다.
국내 랜섬웨어 피해 기업을 대상으로 한 조사에서 백업 보유율은 2023년 상반기 47%에서 2025년 하반기 78.6%까지 올라갔습니다. 그런데 같은 조사에서 백업을 보유한 기업 중에서도 백업 데이터까지 함께 감염된 비율이 23.2%로 나타났습니다. 백업을 갖추는 일과, 그 백업이 사고 순간까지 살아남는 일은 서로 다른 문제라는 뜻입니다.
"백업 잘 돌고 있습니다"라는 보고는 백업 작업의 성공 여부만 말해 줍니다. 그 백업본이 실제로 열리는지, 열린 데이터로 애플리케이션이 뜨는지, 몇 시간 안에 뜨는지는 아무것도 보장하지 않습니다.
RTO·RPO를 숫자로 합의하기
복구 설계의 출발점은 두 개의 숫자입니다. RTO(목표 복구 시간) 는 이 시스템이 몇 시간까지 멈춰 있어도 되는가이고, RPO(목표 복구 시점) 는 몇 시간 분량의 데이터까지 잃어도 되는가입니다.
이 숫자를 전 시스템에 똑같이 적용하면 두 가지 중 하나가 일어납니다. 전부를 최상위 등급으로 잡으면 스토리지와 이중화 비용이 감당되지 않고, 반대로 전부를 느슨하게 잡으면 정작 매출이 멈추는 시스템도 보호되지 않습니다.
실무에서는 업무 영향 분석을 가볍게 한 바퀴 돌려 3단계로 나누는 방식이 현실적입니다.
등급별로 비용을 다르게 쓰기 위한 구분이지, 등급이 낮다고 백업을 빼도 된다는 뜻은 아닙니다.
백업이 같이 죽지 않게 만드는 조건
랜섬웨어는 이미 오래전부터 백업 서버를 우선 표적으로 삼습니다. 운영망에 그대로 붙어 있고 도메인 계정으로 관리되는 백업 서버는 운영계와 함께 암호화됩니다.
KISA를 비롯한 기관의 데이터 백업 보안 수칙이 공통으로 강조하는 항목은 세 가지입니다.
여기에 백업 관리자 계정과 콘솔을 운영 계정 체계에서 분리하는 조치가 따라야 합니다. 운영 관리자 계정 하나가 탈취됐을 때 백업까지 지워진다면 불변 설정도 의미가 없습니다.
3-2-1 원칙(사본 3벌, 서로 다른 매체 2종, 오프사이트 1벌)은 클라우드에서도 유효하지만 해석이 달라집니다. 같은 계정, 같은 리전에 만든 스냅샷 3개는 사본 3벌이 아니라 같은 사고에 함께 사라지는 사본 1벌에 가깝습니다. 계정 경계와 리전 경계를 넘긴 사본이 있어야 합니다.
복구 훈련을 해보면 드러나는 것들
복구 절차서는 대개 데이터 복원까지만 적혀 있습니다. 정작 훈련을 돌리면 절차서에 없던 것들에서 시간이 흘러갑니다.
"데이터는 살아났는데 애플리케이션이 뜨지 않는" 상황이 여기서 나옵니다. 그래서 복구 절차서에는 의존 순서를 담은 복구 순서도가 필요합니다. 인증·계정 → 데이터베이스 → 메시지 큐·캐시 → 애플리케이션 → 배치 순으로, 어느 단계가 끝나야 다음이 의미 있는지를 적어 둡니다.
훈련의 결과물은 '성공/실패'가 아니라 실측 RTO여야 합니다. 목표 4시간인 시스템이 실제로 9시간 걸렸다면, 그 5시간이 어느 단계에서 나왔는지가 다음 분기의 개선 과제가 됩니다. 이 기록이 쌓여야 목표 숫자가 희망이 아닌 근거를 갖습니다.
클라우드·SaaS라서 괜찮다는 오해
클라우드 사업자가 제시하는 가용성 수치는 인프라가 떠 있는 비율이지 내 데이터가 복구된다는 약속이 아닙니다. 공동 책임 모델에서 사업자는 인프라를, 고객은 그 위에 올린 데이터와 설정과 권한을 책임집니다. 실수로 지운 테이블, 잘못 배포된 마이그레이션, 탈취된 관리자 계정은 전부 고객 몫입니다.
SaaS도 마찬가지입니다. 대부분의 SaaS는 휴지통과 보존 정책을 제공하지만 보관 기간이 대체로 수십 일 단위로 설계되어 있어, 몇 달 뒤에 발견되는 조용한 삭제나 변조에는 대응하지 못합니다. 법정 보존 기간이 걸린 데이터라면 SaaS 외부로 빼내는 별도 백업이 필요합니다.
대비 설계는 두 가지 사고를 구분해야 합니다. 리전 장애는 다른 리전의 사본으로 풀리지만, 계정 사고는 같은 계정 안의 사본을 전부 무력화합니다. 전자는 지리적 분리로, 후자는 계정·권한 분리와 불변 저장소로 막습니다.
비용을 넘기지 않으면서 지금 할 일
전사 재해복구 체계를 한 번에 세우려 하면 대개 착수도 못 하고 끝납니다. 출발점은 작게 잡는 편이 낫습니다.
이 한 바퀴만 돌려도 절차서의 빈칸과 목표 대비 격차가 드러납니다. 나머지 시스템은 그 결과를 근거로 확장하면 됩니다.
POLYGLOTSOFT는 SM(유지보수)과 클라우드 운영 과정에서 복구 절차서 작성, 불변 백업 구성, 정기 복구 훈련과 실측 RTO 기록을 일회성 컨설팅이 아닌 상시 운영 업무로 포함해 관리하고 있습니다. 백업은 돌고 있는데 복구는 확인해 본 적이 없다면, 상위 3개 시스템부터 함께 점검해 보시기 바랍니다. 현재 구성에서 무엇이 먼저 필요한지 정리해 드리겠습니다.