회사 NAS·파일서버 랜섬웨어 대비, 백업이 실제로 작동하는지 확인하는 방법

🔐 기업 보안

회사 NAS·파일서버 랜섬웨어 대비,
백업이 실제로 작동하는지 확인하는 방법

2026년 2월 읽는 시간 약 8분 NAS · 랜섬웨어 · 백업 검증

🚨 랜섬웨어에 감염된 중소기업 중 상당수가 "백업을 해두었는데도 복구에 실패"했다고 답합니다.

이유는 단순합니다. 백업을 설정해뒀지만, 백업이 실제로 작동하는지는 한 번도 확인하지 않았기 때문입니다.

백업은 '있다'는 것과 '쓸 수 있다'는 것이 전혀 다른 이야기입니다. 지금 이 글에서 백업이 진짜 살아 있는지 확인하는 방법 3가지를 정리합니다.

1 백업을 해도 복구에 실패하는 진짜 이유

많은 담당자들이 "백업 스케줄러를 켜놨으니 문제없다"고 생각합니다. 하지만 랜섬웨어 감염 후 현장에서 복구가 막히는 이유는 예상보다 다양하고, 대부분 사전에 충분히 막을 수 있는 것들입니다.

01

백업 대상이 네트워크에 연결된 상태

NAS 백업 볼륨이 동일 네트워크에 마운트돼 있으면 랜섬웨어가 백업 파일까지 함께 암호화합니다.

02

백업 작업이 실제로는 오류 중이었음

스케줄러는 돌아가는데 용량 부족·권한 오류로 수주째 백업이 실패 상태였던 경우가 빈번합니다.

03

백업 파일은 있는데 복구가 안 됨

백업 파일이 손상됐거나, 복구 절차를 한 번도 테스트하지 않아 막상 상황에서 진행이 막힙니다.

04

버전이 너무 오래됨

마지막으로 성공한 백업이 수개월 전이라 복구해도 최신 데이터와 격차가 커 사실상 무용지물.

🔴 핵심 문제: 랜섬웨어는 네트워크에 연결된 모든 드라이브를 암호화 대상으로 탐색합니다. 백업 드라이브가 항상 연결·마운트된 상태라면 백업도 함께 암호화됩니다. 이것이 '백업이 있었는데 복구 못 했다'는 사태의 가장 흔한 원인입니다.

2 확인 방법 3가지

01

백업 저장소가 네트워크에서 격리되어 있는가 — 에어갭·오프라인 백업 점검

백업의 가장 기본 조건은 랜섬웨어가 접근할 수 없는 위치에 존재하는 것입니다. 아래 기준으로 현재 백업 구성을 점검하세요.

백업 구성 방식	랜섬웨어 감염 시 백업 생존 가능성
동일 NAS 내 별도 폴더에 백업	매우 낮음 — 동일 장치이므로 함께 암호화
항상 마운트된 별도 NAS 또는 드라이브	낮음 — 네트워크 접근 가능하면 탐색 대상
백업 완료 후 마운트 해제하는 외장드라이브	중간 — 연결 해제 타이밍이 중요
오프사이트 물리 매체 (테이프, 외장하드 격리 보관)	높음 — 물리적으로 분리되어 안전
불변(Immutable) 클라우드 백업	높음 — 쓰기 잠금으로 덮어쓰기 불가
에어갭(Air-gap) 오프라인 백업	매우 높음 — 네트워크 완전 차단 상태 보관

지금 당장 확인할 것

• 백업 드라이브·볼륨이 24시간 네트워크에 마운트돼 있지 않은지 확인
• 백업 완료 후 자동으로 마운트 해제되는 스크립트가 작동 중인지 확인
• 클라우드 백업이라면 '불변 저장소(Object Lock)' 기능이 활성화돼 있는지 확인
• 백업 폴더가 동일 서버의 공유 폴더 하위에 있다면 즉시 구조 변경 필요
• 백업 계정과 운영 계정이 동일 자격증명을 사용하고 있다면 즉시 분리 필요

💡 3-2-1-1 원칙: 기존 3-2-1(3개 복사본·2가지 매체·1개 오프사이트)에 '+1 오프라인'을 추가하는 것이 2026년 랜섬웨어 대비 표준입니다. 오프라인 또는 불변 백업 1개가 반드시 있어야 합니다.

02

백업 작업이 실제로 성공하고 있는가 — 로그·알림 점검

백업 소프트웨어가 돌아가는 것과, 백업이 실제로 완료·저장되는 것은 다릅니다. 많은 현장에서 스케줄러 자체는 살아 있지만 오류가 누적되어 수개월째 백업이 이뤄지지 않은 경우가 발견됩니다.

확인해야 할 로그 항목

• 백업 소프트웨어의 최근 작업 로그 → 마지막 성공 일시 확인
• 오류 코드 유무 — 용량 부족(ENOSPC), 권한 오류(Access Denied) 등
• 백업 파일의 실제 생성 날짜·크기가 예상과 일치하는지 탐색기로 직접 확인
• 백업 완료 시 이메일·메신저 알림이 설정되어 있고 실제로 수신되고 있는지
• 로그 파일이 비어 있거나 오래전 날짜에 멈춰 있다면 즉시 점검 필요
• 백업 용량이 매번 동일하다면 증분 백업이 아닌 오류 상태일 수 있음

권장 모니터링 설정

• 백업 성공·실패 여부를 담당자 이메일 또는 슬랙으로 자동 발송 설정
• 백업 드라이브 잔여 용량 경고 임계값 설정 (예: 20% 미만 시 알림)
• 주 1회 이상 백업 로그를 담당자가 직접 확인하는 루틴 수립
• NAS 관리 콘솔의 스냅샷·버전 이력에서 최신 시점 확인

📋 실무 팁: 백업 로그를 백업 서버 자체에만 저장하면 서버 감염 시 로그도 같이 암호화됩니다. 로그는 별도 외부 저장소(이메일, 별도 서버)에 보내도록 설정하세요.

03

백업에서 실제로 복구가 되는가 — 복구 테스트 실시

가장 중요하지만 가장 많은 조직이 하지 않는 것이 바로 복구 테스트(Restore Test)입니다. 백업 파일이 존재한다는 사실과, 그 파일에서 데이터를 실제로 꺼낼 수 있다는 사실은 다릅니다.

🔴 업계에서는 "테스트하지 않은 백업은 백업이 아니다"는 말이 통용됩니다. 복구 테스트를 한 번도 해보지 않았다면 지금 당장 실시해야 합니다.

복구 테스트 실시 방법

• 격리된 테스트 환경(별도 PC 또는 VM)에서 복구 진행 — 운영 환경에 직접 복구 테스트 금지
• 임의로 선택한 파일 3~5개를 백업본에서 복원해 원본과 내용 일치 여부 확인
• 전체 복구 시 소요 시간 측정 — RTO(복구 목표 시간) 내 완료 가능한지 검증
• 복구 절차를 문서화해 담당자 외 다른 사람도 진행할 수 있는지 확인
• 복구 소프트웨어 라이선스·버전이 현재 백업 포맷과 호환되는지 반드시 확인
• 백업 파일 체크섬(해시값)이 저장되어 있지 않으면 파일 무결성 보장 불가

복구 테스트 권장 주기

조직 규모·데이터 중요도	권장 복구 테스트 주기
소규모 (직원 10명 미만)	분기 1회 이상
중규모 (직원 10~100명)	월 1회 이상
고중요 데이터 보유 (고객 DB·재무)	월 1회 + 대규모 변경 시마다
백업 구성 변경 직후	변경 즉시 테스트 필수

✅ 복구 절차 문서화 필수: 담당자가 자리를 비운 상황에서 랜섬웨어 감염이 발생하는 경우가 많습니다. 복구 절차는 반드시 문서화해 공유하고, 최소 2인 이상이 복구 과정을 숙지하고 있어야 합니다.

3 백업 외에 함께 챙겨야 할 랜섬웨어 대비

백업 검증과 함께 조직 차원에서 병행해야 할 기본 대비 항목입니다. 백업만 완벽해도 감염 자체를 막지 못하면 복구 비용과 다운타임이 발생합니다.

항목	내용	우선순위
네트워크 분리	업무망·백업망·인터넷망을 VLAN 등으로 분리	최우선
최소 권한 원칙	백업 계정은 백업 작업만, 운영 계정은 필요 폴더만 접근	최우선
OS·소프트웨어 패치	NAS 펌웨어, 서버 OS 보안 패치 정기 적용	높음
EDR/백신 설치	엔드포인트 보안 솔루션으로 랜섬웨어 행위 탐지	높음
임직원 보안 교육	피싱 메일, 악성 첨부파일 식별 훈련	높음
감염 대응 매뉴얼	감염 인지 → 격리 → 복구 단계별 담당자·절차 사전 정의	중간

🔵 감염 인지 즉시 해야 할 일: 감염된 장치를 네트워크에서 즉시 물리적으로 분리(랜선 제거·Wi-Fi 차단)하는 것이 피해 확산을 막는 첫 번째 행동입니다. 전원을 끄는 것보다 네트워크 분리가 우선입니다.

✅ 핵심 정리

• 백업 드라이브가 항상 네트워크에 연결돼 있으면 랜섬웨어가 백업까지 암호화한다
• 3-2-1에서 나아가 '오프라인 또는 불변 백업 1개'를 반드시 포함할 것 (3-2-1-1)
• 백업 로그와 마지막 성공 일시를 주 1회 이상 직접 확인해야 한다
• 테스트하지 않은 백업은 백업이 아니다 — 최소 분기 1회 복구 테스트 실시
• 복구 절차는 문서화하고 최소 2인 이상이 숙지해야 한다
• 감염 인지 즉시 해야 할 첫 번째 행동은 네트워크 물리적 분리다