대상: "어떤 식으로든 백업은 하고 있지만 이게 정말 충분한가?" 궁금한 1인·소규모 팀 작업자. 여기에 공격 절차는 없다 — 오직 확실하게 복원할 수 있는 백업을 만드는 법이다.
본 사이트의 견해: '클라우드 동기화'는 백업이 아니다
"OneDrive/Google Drive에 동기화하니까 백업된 거야"라는 흔한 가정. 그렇지 않다. 동기화는 현재 상태를 복제하므로, 실수로 지운 파일이나 랜섬웨어가 암호화한 파일이 그 상태 그대로 반대편에 복사된다.
백업에는 이전 상태로 되돌리는 능력이 필요하다: 이전 사본을 복원하는 버전 관리, 나중에 덮어쓸 수 없는 불변 사본. 동기화는 편리하지만 그 자체로는 한쪽이 망가지면 둘 다 망가진다. 백업과는 완전히 다른 역할로 다루라.
왜 "백업이 있다"로는 부족한가
백업이 필요한 이유는 데이터 손실의 원인이 많고 — 한꺼번에 닥치기 때문이다. 하드웨어 고장, 실수 삭제, 도난과 재해, 그리고 랜섬웨어. 한 방향의 방어선은 다른 방향에서 오는 사고를 놓친다.
특히 랜섬웨어는 백업 자체를 찾아내 암호화한다. 데이터와 같은 곳에 둔 백업은 같은 사고로 함께 손상된다. 이것이 취약점 대응에서 말하는 "복원 가능한 상태를 유지하라"의 가장 기본적인 형태다(→ 취약점 대응의 실천).
기본 형태: 3-2-1 (+ 오프라인/불변)
3 — 사본 3개
원본 + 2개. 하나가 망가져도 나머지 둘로 복원한다.
2 — 매체 2종
예: 내장 드라이브 + 외장 SSD, 또는 NAS + 클라우드. 한 상자에 몰아넣지 마라.
1 — 한 부는 외부
다른 장소(클라우드 / 별도 거점). 화재·도난·침수가 모두를 지우지 못한다.
+ 오프라인/불변 하나
늘 연결되어 있지 않거나, 덮어쓸 수 없음. 랜섬웨어가 암호화할 수 없는 사본을 항상 하나 유지하라.
만드는 법 (순서대로 채워라)
먼저 '잃으면 아픈 것'을 목록화
3-2-1로 배치
최소 하나는 오프라인/불변으로
자동화하라(수동은 오래 못 간다)
주기적으로 복원 테스트
랜섬웨어는 백업도 노린다
현대 랜섬웨어는 주 데이터뿐 아니라 찾을 수 있는 모든 연결된 백업 대상(NAS, 외장 드라이브, 마운트된 클라우드)까지 암호화한다. 그래서 늘 연결된 백업만 있으면 다른 모든 것과 함께 암호화된다.
가장 효과적인 방어는 최소 하나의 사본을 오프라인(물리적으로 분리)이나 불변(일정 기간 덮어쓰기/삭제 금지)으로 유지하는 것이다. 그 사본이 있느냐가 몸값을 내느냐 마느냐를 가른다.
클라우드 동기화만
- 삭제와 암호화가 그대로 동기화된다
- 이전 버전으로 되돌릴 수 없다
- 늘 연결됨 = 랜섬웨어에 함께 암호화됨
- 복원되는지 한 번도 확인하지 않았다
3-2-1 + 불변 + 복원 테스트
- 버전 관리로 깨끗한 이전 사본을 복원
- 랜섬웨어로부터 격리된 오프라인/불변 사본
- 장소·매체에 걸친 중복으로 전부 잃지 않음
- 주기적 테스트로 실제 복원됨을 확인
환경별: 기본 제공 기능과 더해야 할 것
흔한 환경마다 기본 제공 기능, 이전 버전으로 되돌릴 수 있는지, 랜섬웨어 대비로 더해야 할 것을 정리했다.
| 환경 | 기본 제공 기능 | 이전 버전으로 되돌릴 수 있나? | 더해야 할 것 |
|---|---|---|---|
| Windows | 파일 히스토리(외장 드라이브나 네트워크 위치에 저장) | 가능(파일 탐색기의 "이전 버전 복원") | 백업이 끝나면 대상 드라이브를 분리한다. 두 번째 사본을 다른 곳에 둔다 |
| Windows(Windows 백업 앱) | 바탕 화면, 문서 등의 폴더를 OneDrive에 동기화 | OneDrive 기능에 따라 다름 | 바탕은 동기화이므로 파일 히스토리나 외부 사본도 함께 유지한다 |
| Mac | Time Machine | 가능(지난 24시간은 시간별, 지난 한 달은 일별, 그 이전은 주별) | 두 번째 백업 디스크를 다른 장소에 두고 가끔 교체한다 |
| iPhone | iCloud 백업(전원 연결, Wi-Fi 연결, 잠금 상태일 때 자동) | 기기 전체를 복원하는 구조 | 중요한 사진과 문서는 컴퓨터나 외장 드라이브에도 보관한다 |
| OneDrive | 동기화 | Microsoft 365 구독자는 "Restore your OneDrive"(OneDrive 복원)로 최근 30일 이내의 시점으로 되돌릴 수 있음 | 동기화와 별개인 오프라인 사본 하나 |
| Google Drive | 동기화 | Google 형식이 아닌 파일은 "Manage versions"(버전 관리)로 되돌릴 수 있음. 이전 버전은 30일이 지나거나 새 버전이 100개가 되면 삭제될 수 있음 | 필요한 버전에 "Keep forever"(영구 보관) 설정, 그리고 오프라인 사본 하나 |
| 서버 / VPS | 백업 도구(restic 등)와 별도 저장 대상 | 가능(도구의 스냅샷에서) | 운영 서버에서 저장 대상을 삭제할 수 없게 한다(S3 Object Lock 등) |
| 공유 웹 호스팅 | 업체의 자동 백업 | 업체의 보관 기간 안에서만 | 데이터를 업체 밖으로도 정기적으로 복사한다(내 컴퓨터나 클라우드로) |
"더해야 할 것" 열은 3-2-1의 나머지를 채우는 작업이다. 기본 제공 기능만으로 3-2-1과 오프라인 사본까지 갖춰지는 환경은 거의 없다.
내 설정을 점검하는 법
"백업되고 있을 것"이라는 짐작을 없애려면 다음을 순서대로 확인하라. 각 단계는 내 기기와 계정의 설정만 본다.
마지막 백업이 성공한 시점을 본다
- Windows: 제어판에서 "파일 히스토리"를 열어, 켜져 있는지, 어느 드라이브를 쓰는지, 마지막으로 파일이 복사된 시점을 확인한다.
- Mac: 시스템 설정 → 일반 → Time Machine에서 최신 백업 시각을 확인한다. 터미널에서는
tmutil latestbackup이 최신 백업을,tmutil destinationinfo가 저장 대상을 보여 준다(환경에 따라 터미널에 전체 디스크 접근 권한이 필요하다). - iPhone: 설정 → 사용자 이름 → iCloud → iCloud 백업에 마지막 백업 날짜와 시각이 표시된다.
- 서버: restic이라면
restic snapshots가 스냅샷을 날짜와 함께 나열한다.
날짜가 며칠 전에 멈춰 있다면, 그것부터 고쳐야 한다.
저장 대상이 늘 연결되어 있지 않은지 확인
외장 드라이브나 NAS가 항상 꽂혀 있어 드라이브로 보이는 상태인지 확인하라. 서버라면 운영 서버에 저장된 인증 정보로 백업까지 삭제할 수는 없는지 권한 설정에서 확인하라. S3라면 저장 대상 버킷에 Object Lock이 켜져 있는지도 확인하라.
클라우드가 되돌릴 수 있는지 확인
OneDrive는 설정 → 옵션에 "Restore your OneDrive"(OneDrive 복원)가 나타나는지 보라(Microsoft 365 구독자 대상). Google Drive는 파일을 마우스 오른쪽 버튼으로 눌러 "Manage versions"(버전 관리)에 이전 버전이 나오는지 보라. 둘 다 보관 기간에 한계가 있으므로, 더 오래전으로 돌아갈 다른 수단이 필요하다.
실제로 하나를 복원해 본다(복원 테스트)
중요한 파일 하나를 골라 다른 위치에 복원한 뒤 열어 보라. Windows에서는 폴더를 마우스 오른쪽 버튼으로 눌러 "이전 버전 복원"을, Mac에서는 Time Machine에서 복원한다. 서버라면 다른 디렉터리에 복원해 내용을 확인한다. restic이라면 restic check --read-data-subset=5% 같은 명령으로 저장된 데이터의 일부를 다시 읽어 검증한다. 데이터베이스는 별도 데이터베이스에 복원해 시작되는지 확인한다.
결과와 걸린 시간을 기록
날짜, 복원한 것, 걸린 시간을 적어 두라. 전체 복원에 대략 몇 시간이 걸릴지 알 수 있고, 다음 테스트 때 변화도 알아챌 수 있다.
흔한 실수와 고치는 법
- 외장 드라이브를 꽂아 둔 채로 둔다: 랜섬웨어에게 연결된 드라이브는 암호화할 또 하나의 장소일 뿐이다. 백업할 때마다 분리하거나, 드라이브 두 개를 번갈아 써서 하나는 항상 분리해 둔다.
- 동기화를 백업으로 여긴다: Windows 백업 앱의 폴더 백업은 바탕이 OneDrive 동기화다. 이전 버전을 보관하는 별도의 백업을 유지한다.
- 백업 관리 화면에 운영 환경과 같은 비밀번호를 쓴다: 운영 환경이 탈취되면 백업도 삭제된다. 다른 비밀번호를 쓰고 다요소 인증을 켠다.
- 실패 알림을 보지 않는다: 멈춘 백업은 눈치채지 못한다. 실패 알림을 켜고, 한 달에 한 번 마지막 백업 시각을 확인한다.
- 복원에 필요한 것을 백업 안에만 둔다: 암호화 비밀번호와 복구 키는 백업과 다른 곳에 보관한다(→ 비밀번호 관리자 고르기).
- 오프라인 사본을 한 번 만들고 끝낸다: 그 사본을 만든 시점으로만 복원할 수 있다. 매월 등 정해진 주기로 새로 만든다.
공개 사례: 살아남은 것은 분리해 둔 오래된 사본이었다
2021년 10월 랜섬웨어 공격을 받은 쓰루기초 한다 병원(영문)에 대한 전문가 회의 보고서(2022년 6월 공개)는 백업에 대해 다음과 같이 밝히고 있다.
- 백업 서버는 암호화가 확인된 서버 목록에 들어 있었다
- 2018년까지 오프라인으로 보관하던 백업 데이터는 피해를 입지 않아 복구에 쓸 수 있었다
- 일반 외래 진료는 공격 약 두 달 뒤인 2022년 1월 4일에 재개되었다
연결된 백업은 운영 환경과 함께 당했고, 분리된 사본은 살아남았다. 하지만 그 사본은 몇 년 전 것이었다. 오프라인 사본은 정기적으로 새로 만들어 복원할 수 있는 시점을 최근으로 유지해야 제대로 도움이 된다.
본 사이트는 어떻게 하는가
본 사이트는 데이터와 문서를 자동으로, 별도 장소에, 여러 세대에 걸쳐 받고, 거기에 "가능한 한 설계로 재구축 가능하게"라는 접근을 곁들인다. 기계적으로 재생성할 수 있는 데이터(수집 피드, 인덱스 등)는, 예컨대 백업에 의존하기보다 재구축할 수 있다는 전제로 보관한다 — "애초에 백업 부담을 줄이는" 방식이다. 그 위에 대체 불가능한 것(기사 본문, 설정)은 중복으로 유지하며, 항상 복원 가능한 상태를 유지하는 것을 운영의 전제로 삼는다.
지원 종료된 하드웨어를 교체할 때(→ Windows 10 지원 종료 글), 안심하고 이전할 수 있는 이유는 복원 가능한 백업이 존재하기 때문이다. 백업을 다른 모든 대책이 실패했을 때를 위한 것만이 아니라, 사고 대응의 전제 조건 으로 생각하라.
다음으로 읽기
- NAS 사례: 오래된 DSM을 쓰는 Synology NAS에 대한 랜섬웨어 공격과 업데이트 방법
- 기본: 보안 기준선 체크리스트(Tier 3 = 탐지, 복구)
- 실천: 취약점 대응의 실천(복원 가능한 상태 유지)
- 관련: Windows 10 지원 종료 위험과 이전
- 저장: 비밀번호와 시크릿을 안전하게 저장하기
- 사례: KADOKAWA·Niconico 랜섬웨어 사고(2024)(수개월 정지 — 사업 연속성(BCP)의 교훈)
- 업체가 침해되었을 때: 웹 호스팅 업체가 침해되었을 때 할 일(영문)(유일한 백업을 그 업체 안에만 두면 안 되는 이유)
- 오사카 공립대학교 랜섬웨어 공격(협력업체 클라우드 스토리지에서 개인정보 유출 확인)
출처
- CISA 외, "#StopRansomware Guide"(오프라인·암호화된 백업을 유지하고 정기적으로 복원을 시험할 것): cisa.gov
- 쓰루기초 한다 병원, 컴퓨터 바이러스 감염 사안 전문가 회의 조사 보고서(2022년 6월, 일본어): handa-hospital.jp
- Microsoft 지원, "Backup and restore with File History": support.microsoft.com
- Microsoft 지원, "Back up your folders with OneDrive": support.microsoft.com
- Microsoft 지원, "Restore your OneDrive": support.microsoft.com
- Google Drive 고객센터, "Check activity & file versions": support.google.com
- Apple 지원, "Back up your Mac with Time Machine": support.apple.com
- Apple 지원, "How to back up your iPhone with iCloud": support.apple.com
- AWS 문서, "Locking objects with Object Lock": docs.aws.amazon.com
- restic 문서, "Working with repositories"(snapshots / check): restic.readthedocs.io