백업은 왜 '해 두었다'로 끝나지 않나: 복구까지의 원리

'백업해 두었다'는 말이 감추는 것

백업은 보안 입문자가 가장 먼저 배우는 단어이면서, 가장 쉽게 끝났다고 느끼는 항목입니다. 외장 디스크에 복사해 두었고 클라우드 동기화도 켜 두었으니 됐다는 식입니다. 그런데 현장에서 백업과 관련된 사고를 들여다보면 '백업이 없어서' 생긴 일보다 '백업이 있다고 믿었는데 쓸 수 없어서' 생긴 일이 훨씬 흔합니다. 사본 파일이 있었지만 중간에 깨져 있었고, 백업 작업이 몇 달 전부터 조용히 실패하고 있었고, 복구 절차를 아는 사람이 이미 퇴사한 뒤였다는 식입니다.

이런 일이 반복되는 이유는 백업의 목적을 잘못 놓기 때문입니다. 백업의 목적은 사본을 만드는 것이 아니라, 원본을 잃은 뒤에 업무가 필요로 하는 상태로 되돌리는 것입니다. 사본은 그 목적을 위한 재료일 뿐입니다. 그래서 이 글은 '어떤 도구로 백업하는가'가 아니라 '무엇이 갖춰져야 백업이 백업으로 작동하는가'를 다룹니다. 특정 소프트웨어나 서비스의 사용법은 다루지 않습니다.

백업은 가용성 대책이고, 사고의 종류는 한 가지가 아니다

기밀성·무결성·가용성이라는 보안의 세 목적 가운데 백업은 가용성을 지키는 가장 오래된 수단입니다. 필요한 순간에 정보를 실제로 쓸 수 있게 하는 것이 가용성이고, 백업은 원본이 사라졌을 때 그 순간을 지켜 줍니다. 그런데 원본이 사라지는 경로는 한 가지가 아닙니다. 장비 고장, 실수로 삭제, 잘못된 수정이 덮어쓰기, 소프트웨어 오류, 도난과 분실, 그리고 파일을 암호화해 인질로 잡는 방식의 악성코드까지 모두 '원본을 못 쓰게 되는 사고'입니다.

사고의 종류가 다르면 필요한 백업의 성격도 달라집니다. 장비 고장에 대비하려면 다른 장비에 사본이 있으면 되지만, 실수로 지운 파일을 되찾으려면 지우기 전 시점의 사본이 남아 있어야 합니다. 잘못된 수정이 여러 날 뒤에야 발견된다면 어제 것 하나로는 부족하고 여러 시점의 사본이 필요합니다. 파일을 암호화하는 악성코드에 대비하려면 사본이 원본과 같은 경로로 닿지 않는 곳에 있어야 합니다. 백업을 설계한다는 것은 결국 어떤 사고까지 감당할지 정하는 일입니다.

사본의 수보다 사본의 위치와 독립성

백업을 이야기할 때 자주 인용되는 경험칙이 있습니다. 사본을 여러 개 두되, 서로 다른 종류의 저장 매체에 나누고, 그중 하나는 원본과 물리적으로 떨어진 장소에 둔다는 것입니다. 숫자 자체보다 중요한 것은 그 안에 담긴 원리입니다. 같은 원인으로 함께 망가지지 않게 사본을 흩어 놓는다는 것입니다. 같은 방 같은 책상 위의 외장 디스크는 화재와 도난을 원본과 함께 겪고, 같은 계정으로 접근하는 클라우드 폴더는 그 계정이 털리면 원본과 함께 지워집니다.

여기서 입문자가 가장 자주 놓치는 구분이 동기화와 백업의 차이입니다. 동기화는 여러 기기의 상태를 같게 맞추는 기능이라, 한쪽에서 파일을 지우거나 망가뜨리면 그 변화가 다른 쪽에도 그대로 전파됩니다. 사본이 있는 것처럼 보이지만 '실수 이전의 상태'는 남아 있지 않을 수 있습니다. 많은 서비스가 휴지통이나 버전 기록을 함께 제공하지만, 그 보관 기간과 범위는 서비스마다 다르고 바뀌기도 하므로 내가 쓰는 서비스의 현재 안내에서 직접 확인해야 합니다. 동기화는 편의 기능이고, 백업은 '되돌릴 수 있는 과거'를 따로 보관하는 일입니다.

또 하나는 사본이 원본과 얼마나 독립적인가입니다. 평소에는 연결되어 있지 않다가 백업할 때만 연결되는 매체, 한 번 기록되면 일정 기간 수정·삭제가 되지 않는 저장 방식, 원본 쪽 계정과 분리된 권한으로만 접근되는 보관소가 그런 예입니다. 원본을 망가뜨린 손이 같은 손으로 사본까지 닿을 수 있다면, 그 사본은 독립적이지 않습니다.

얼마나 자주, 얼마나 빨리 — 두 개의 질문

백업 설계에서 도구보다 먼저 정해야 하는 질문이 둘 있습니다. 하나는 '최대 얼마만큼의 최근 작업을 잃어도 감당할 수 있는가'입니다. 하루치면 괜찮은 자료가 있고, 한 시간치도 곤란한 자료가 있습니다. 이 답이 백업 주기를 정합니다. 다른 하나는 '원본을 잃은 뒤 얼마 안에 다시 쓸 수 있어야 하는가'입니다. 며칠 걸려도 되는 자료가 있고, 몇 시간 안에 돌아와야 하는 시스템이 있습니다. 이 답이 복구 방식과 준비 수준을 정합니다.

두 질문의 답은 자료마다 다르고, 그래서 모든 자료에 같은 백업을 거는 것은 대개 낭비이거나 부족입니다. 가족 사진은 몇 주치 늦은 사본이어도 되돌릴 수만 있다면 충분하지만, 매일 갱신되는 장부는 그렇지 않습니다. 조직에서는 이 두 질문을 자산별로 적어 두는 것 자체가 백업 정책의 뼈대가 됩니다. 앞선 글에서 다룬 위험 평가가 '무엇을 먼저 지킬지'를 정하는 절차였다면, 백업 설계는 그 우선순위를 '얼마나 자주, 얼마나 빨리'라는 두 숫자로 옮겨 적는 일입니다.

복구해 본 적 없는 백업은 백업이 아니다

백업이 백업으로 작동하는지 확인하는 방법은 하나뿐입니다. 실제로 되돌려 보는 것입니다. 사본 파일이 있다는 것과 그 파일에서 업무가 다시 시작될 수 있다는 것은 다른 문제입니다. 사본이 일부 깨져 있을 수 있고, 복구에 필요한 암호 열쇠가 원본 장비에만 있었을 수 있고, 절차를 아는 사람이 자리에 없을 수 있습니다. 이런 문제는 모두 복구를 시험해 보기 전까지는 드러나지 않습니다. 그래서 보안에서는 한 번도 복구를 시험하지 않은 백업 절차를 '대비책'이 아니라 '취약점'으로 분류합니다.

복구 시험이라고 해서 거창할 필요는 없습니다. 개인이라면 가끔 사본에서 파일 몇 개를 열어 보고 최근 것이 맞는지 확인하는 정도로 시작할 수 있습니다. 조직이라면 정해진 주기로 시험 환경에 실제 복구를 해 보고, 걸린 시간과 막힌 지점을 기록으로 남기는 것이 핵심입니다. 그 기록이 쌓이면 '우리는 이 자료를 이만큼의 시간 안에 되돌릴 수 있다'는 문장을 근거를 갖고 말할 수 있게 되고, 그 문장이야말로 백업이라는 일의 최종 결과물입니다.

마지막으로 백업 사본은 원본 못지않게 보호해야 할 대상이라는 점을 짚어 둡니다. 사본에는 원본과 같은 정보가 들어 있으므로, 사본이 유출되면 원본이 유출된 것과 다르지 않습니다. 가용성을 위해 만든 사본이 기밀성의 구멍이 되지 않도록, 사본에도 접근 권한과 보관 위치, 폐기 절차가 따라붙어야 합니다. 백업은 가용성 하나만의 이야기가 아니라 세 목적이 다시 만나는 자리입니다.