월요일 아침, 공유 폴더의 엑셀 파일이 전부 낯선 확장자로 바뀌어 열리지 않습니다. 외장하드에 백업해 두었다고 안심했는데, 그 외장하드도 컴퓨터에 꽂혀 있어서 같이 잠겼습니다. 작은 사무실의 백업이 실패하는 이유는 백업을 안 해서가 아니라, 복구할 수 없는 방식으로 해 두었기 때문인 경우가 많습니다.
이 글에서 확인할 것
- 원본·동기화 사본·백업본이 어떻게 다른지
- 백업을 해 두고도 복구에 실패하는 흔한 구성
- 자료 종류별 백업 위치와 주기, 복원 테스트 방법
원본, 동기화 사본, 백업본은 서로 다른 물건이다
사무실 파일은 세 가지 상태로 존재합니다. 지금 작업하는 원본, 여러 기기에 똑같이 맞춰지는 동기화 사본, 특정 시점의 모습을 따로 떼어 보관한 백업본입니다. 많은 회사가 클라우드 드라이브에 폴더를 동기화해 두고 백업이 끝났다고 생각하는데, 동기화는 원본이 바뀌면 사본도 곧바로 따라 바뀝니다. 원본이 암호화되거나 지워지면 동기화 사본도 같은 상태가 됩니다.
백업본의 조건은 두 가지입니다. 원본과 떨어져 있어야 하고, 과거 시점으로 되돌릴 수 있어야 합니다. 그래서 흔히 3-2-1 원칙을 기준으로 삼습니다. 사본을 세 벌 두고, 저장 매체는 두 종류 이상 쓰고, 그중 한 벌은 사무실 밖에 두는 방식입니다.
이 원칙을 작은 사무실에 옮기면 이렇게 됩니다. 원본은 공유 폴더나 NAS에, 첫 번째 백업은 사무실 안의 별도 장치에, 두 번째 백업은 버전 기록이 남는 클라우드 백업 서비스에 둡니다.
백업해 두고도 복구가 안 되는 이유
첫 번째는 항상 연결된 백업 장치입니다. 외장하드나 NAS가 PC에 네트워크 드라이브로 늘 연결되어 있으면, 랜섬웨어는 그 드라이브까지 찾아가 함께 암호화합니다. 백업이 끝나면 연결을 끊거나, PC에서 파일을 직접 고칠 수 없는 방식으로 백업을 받는 장치여야 합니다.
두 번째는 한 번도 복원해 보지 않은 백업입니다. 백업 프로그램이 매일 성공이라고 표시해도, 실제로는 특정 폴더가 빠져 있거나 회계 프로그램 데이터가 사용 중이라 복사되지 않은 경우가 있습니다. 사고 당일에 처음 복원을 시도하면 그때서야 이 사실을 알게 됩니다.
세 번째는 회사 밖에 있는 자료입니다. 홈페이지와 쇼핑몰 데이터는 호스팅 업체에, 메일은 메일 서비스에, 업무 앱 데이터는 개발사 서버에 있습니다. 이 자료들은 사무실 백업 대상에서 통째로 빠지기 쉽고, 누가 백업할 책임이 있는지 계약서에 적혀 있지 않은 경우가 대부분입니다.
자료 종류별 백업 위치와 주기 표
아래 표는 작은 회사에서 잃었을 때 타격이 큰 여섯 가지 자료를 놓고, 어디에 얼마나 자주 백업할지와 자주 빠지는 지점을 정리한 것입니다. 주기는 하루 동안 쌓이는 작업량을 기준으로 잡았으니 업무 흐름에 맞게 조정해 씁니다.
| 자료 | 백업 위치와 주기 | 자주 빠지는 지점 |
|---|---|---|
| 회계·세무 프로그램 데이터 | 프로그램 자체 백업 기능, 매일 퇴근 전 | 프로그램 실행 중이라 파일 복사 실패 |
| 공유 폴더 문서 | NAS 스냅샷 매일, 외부 클라우드 백업 주 1회 | 개인 PC 바탕화면에만 있는 파일 |
| 거래처·고객 명단 | 원본 시스템에서 내보내기, 주 1회 | 내보낸 파일에 암호를 걸지 않음 |
| 업무 메일 | 메일 서비스 보관 기능 또는 내보내기, 월 1회 | 퇴사자 계정을 지우면서 메일도 함께 사라짐 |
| 홈페이지·쇼핑몰 | 호스팅 백업과 별도로 파일·DB 내려받기, 월 1회 | 호스팅 백업이 같은 서버 안에만 있음 |
| 업무용 앱·ERP 데이터 | 개발사 서버 백업과 월 1회 데이터 인도 | 계약서에 백업 책임 조항이 없음 |
표의 뒤쪽 세 줄은 사무실 밖에 있는 자료라 담당자가 따로 챙기지 않으면 아무도 백업하지 않습니다. 앞쪽 세 줄은 장치로 자동화하고, 뒤쪽 세 줄은 달력에 날짜를 적어 사람이 확인하는 식으로 나누면 관리가 단순해집니다.
백업 체계를 만드는 순서
먼저 자료 목록을 만듭니다. 담당자별로 “이 파일이 사라지면 오늘 일을 못 한다”는 자료를 적게 하고, 그 자료가 실제로 어느 PC, 어느 서비스에 있는지 옆에 씁니다. 이 단계에서 개인 PC에만 있는 중요한 파일이 꼭 한두 개 나옵니다.
그다음 저장 위치를 모읍니다. 개인 PC에 흩어진 업무 파일을 공유 폴더로 옮겨, 공유 폴더 하나만 백업하면 되는 구조를 만듭니다. 백업 대상이 적을수록 빠지는 것도 줄어듭니다.
세 번째는 회사 밖 자료의 책임자를 정하는 일입니다. 홈페이지를 외부에 맡겼다면 백업 주기와 보관 위치, 사고 때 복구에 걸리는 시간을 문서로 받아 둡니다. 새로 만들 계획이라면 홈페이지 제작 업체와 계약할 때 서버 백업과 원본 파일 인도를 견적 항목에 넣어 달라고 요청합니다.
마지막으로 복원 테스트를 합니다. 한 달에 한 번 임의로 고른 파일 하나를 백업본에서 다른 폴더로 복원해 열어 보고 날짜와 결과를 기록합니다. 분기에 한 번은 회계 데이터 전체를 다른 PC에 복원해 프로그램에서 실제로 열리는지까지 확인합니다.
백업 장치와 외주 계약에서 챙길 것
NAS를 쓴다면 스냅샷 기능을 켜고, 스냅샷을 지울 수 있는 권한은 평소 쓰는 계정이 아닌 별도 관리자 계정에만 줍니다. 평소 계정이 탈취되어도 과거 시점은 지울 수 없게 하는 설정입니다. 관리자 계정과 클라우드 백업 계정에는 2단계 인증을 걸어 둡니다.
클라우드 백업 서비스를 고를 때는 용량보다 버전 보관 기간을 먼저 봅니다. 감염 사실을 며칠 뒤에야 알아차리는 경우가 많아서, 보관 기간이 짧으면 이미 암호화된 파일만 남아 있을 수 있습니다.
업무 앱을 외주로 만들 때도 같은 기준이 필요합니다. 앱 개발 외주 계약서에 데이터베이스 백업 주기, 소스코드와 데이터의 소유권, 계약이 끝났을 때 넘겨받는 방식을 적어 둡니다. 이미 운영 중인 앱이라면 앱유지보수 계약을 갱신할 때 월 1회 데이터 인도와 연 1회 복구 시연을 조건으로 넣는 것이 현실적입니다.
점검 목록과 정리
- 사라지면 업무가 멈추는 자료 목록이 문서로 있는가
- 업무 파일이 개인 PC가 아니라 공유 폴더에 모여 있는가
- 백업 장치가 평소에 PC와 직접 연결되어 있지 않은가
- 사본 중 한 벌이 사무실 밖에 있는가
- 과거 시점으로 되돌릴 수 있는 버전 기록이 충분히 남는가
- 홈페이지·메일·업무 앱 데이터의 백업 책임자가 정해져 있는가
- 최근 한 달 안에 실제로 파일을 복원해 본 기록이 있는가
백업은 사본의 개수보다 복원할 수 있느냐로 평가됩니다. 원본과 떨어진 곳에, 과거 시점으로, 회사 밖 자료까지 포함해 보관하고, 한 달에 한 번 실제로 꺼내 보는 것까지가 백업입니다. 오늘은 자료 목록 한 장과 파일 한 개 복원부터 시작하면 됩니다.
복원해 보지 않은 백업은 아직 백업이 아니다.
