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

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

외장 디스크에 복사해 뒀고 클라우드 동기화도 켜 뒀으니 백업은 끝났다고 생각하시죠. 근데 말이죠, 막상 파일을 잃고 나면 '사본은 있는데 되돌릴 수가 없다'는 상황이 의외로 자주 생겨요. 이 글에서는 사본·분리·복구 시험이라는 세 축으로, 백업이 실제로 작동하려면 무엇이 갖춰져야 하는지 정리해 드릴게요.

현장에서 백업과 관련된 사고를 들여다보면 '백업이 없어서' 생긴 일보다 '백업이 있다고 믿었는데 쓸 수 없어서' 생긴 일이 훨씬 흔해요. 사본 파일이 있었지만 중간에 깨져 있었고, 백업 작업이 몇 달 전부터 조용히 실패하고 있었고, 복구 절차를 아는 사람이 이미 퇴사한 뒤였다는 식이에요.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

정리하면 이렇게 하시면 돼요. 오늘은 내 사본이 원본과 다른 곳에 있는지 한 번 보고, 이번 주 안에 그 사본에서 파일 하나만 실제로 열어 보시면 돼요. 이 두 가지만 해도 '있다고 믿는 백업'이 '되돌려 본 백업'으로 바뀌어요. 한 번 되돌려 본 경험이 생기면 사고 소식을 접해도 마음이 훨씬 덜 불안해지고요. 백업은 완벽하게 설계하는 일이라기보다, 작게 확인해 두는 습관에 가까워요. 오늘 한 가지만 확인해 두셔도 지켜지는 범위가 그만큼 넓어지니까, 부담 없이 한 걸음씩 늘려 가시면 돼요.