# RAID 구성만 믿고 있다면, NAS 데이터 백업을 다시 설계해야 하는 이유

> 원문: https://test1234.teon.kr/nas-backup-redesign-raid-reliance · 발행 2026-07-31 · 테온

## RAID 구성은 데이터를 지키는 장치가 아닙니다
새 NAS에 RAID 5 구성을 끝낸 날, 화면에 디스크 네 개가 정상으로 표시됩니다. 사진 폴더를 옮겨놓고 '이제 하나가 고장 나도 괜찮겠지'라고 생각하기 쉽습니다. 그런데 며칠 뒤 랜섬웨어가 NAS의 공유 폴더를 암호화하거나, 실수로 상위 폴더를 삭제하면 RAID 구성은 그 변화를 그대로 여러 디스크에 반영합니다.

RAID는 여러 디스크를 하나의 논리적 저장 공간처럼 묶어 일부 디스크 장애에도 서비스가 계속 작동하도록 만드는 기술입니다. 디스크 하나가 고장 났을 때 교체하고 데이터를 재구성하는 데 강합니다. 반면 백업은 현재 데이터와 분리된 복사본을 보관해 삭제, 손상, 암호화 이전의 상태로 돌아가게 하는 체계예요.

두 개념을 섞으면 비용이 커집니다. NAS의 디스크를 더 큰 용량으로 교체해도 과거 버전이 생기지 않고, RAID 레벨을 바꿔도 랜섬웨어 이전의 파일이 자동으로 돌아오지 않습니다. 계속 작동하는 것과 되살릴 수 있는 것은 서로 다른 목표입니다.

## 고장보다 무서운 것은 정상적으로 반영되는 삭제입니다
디스크 장애는 대체로 증상이 보입니다. 경고등이 켜지고, 저장 공간 상태가 나빠지며, 교체할 디스크를 정할 수 있죠. 사용자 실수와 악성코드는 더 조용합니다. 잘못된 삭제 명령은 정상적인 작업처럼 처리되고, 암호화된 파일도 새로운 파일 상태로 기록됩니다.

스냅샷과 데이터 백업도 구분해야 합니다. 스냅샷은 같은 저장 시스템 안에서 특정 시점의 상태를 빠르게 가리키는 복구 지점입니다. 백업은 별도의 저장 위치에 복사본을 두는 절차입니다. 스냅샷은 최근 삭제나 변경을 되돌리는 데 편리하지만, NAS 자체의 장애나 관리자 계정 탈취까지 해결하는 단독 방어선으로 설계하면 빈틈이 생깁니다.

특히 백업 대상이 NAS와 같은 네트워크에 계속 연결되어 있으면 공격자가 그 위치까지 접근할 가능성을 고려해야 합니다. 3-2-1 원칙은 데이터 복사본 3개를 서로 다른 매체 2종에 두고, 그중 1개를 다른 장소에 보관하는 방식입니다. 랜섬웨어까지 고려한다면 한 복사본은 변경·삭제가 어렵거나 네트워크에서 분리된 형태로 설계하는 편이 안전합니다.

## 가정용 NAS라면 3-2-1을 작게 시작하십시오
설명을 위한 가상의 예시입니다. 사진과 문서가 4TB인 가정용 NAS라면 첫 번째 복사본은 NAS에 두고, 두 번째는 백업용 외장하드에, 세 번째는 다른 장소의 원격 NAS나 클라우드에 보관하는 구조로 시작할 수 있습니다. 이 구성은 모든 데이터를 같은 장치에 두는 상태에서 벗어나는 출발선이지, 모든 환경에 그대로 적용되는 정답은 아닙니다.

① 예산을 아끼고 인터넷 연결이 불안정하다면 → 외장하드 백업을 우선합니다. 백업이 끝난 뒤 외장하드를 분리해 두면 네트워크를 통한 동시 감염 위험을 줄일 수 있어요. ② 외부에서도 자동 운영하고 장소 분리를 중시한다면 → 원격 NAS나 클라우드 백업을 검토하십시오. 대신 계정 보호, 보존 버전, 복구에 걸리는 시간과 비용을 함께 확인해야 합니다.

③ 사진처럼 다시 만들기 어려운 자료라면 → 한 가지 방식만 선택하지 말고 로컬 복사본과 외부 복사본을 결합합니다. 반대로 임시 다운로드 파일처럼 잃어도 업무가 멈추지 않는 자료까지 같은 수준으로 보관하면 저장 비용과 관리 부담이 불필요하게 커집니다. 보호 수준은 데이터의 교체 가능성과 복구 시급성에 맞춰 정해야 합니다.

## 백업 방식은 저장 비용보다 복구 장면으로 고르세요
외장하드 백업은 초기 비용과 구조가 단순하다는 장점이 있습니다. 백업 대상이 가정용 사진과 문서이고 직접 연결·분리하는 관리가 가능하다면 적합합니다. 다만 하드디스크를 NAS 옆에 꽂아둔 채로만 운영하면 화재, 도난, 랜섬웨어 같은 사건에 함께 노출됩니다.

원격 NAS는 큰 용량과 자동화, 장기적인 확장성을 중시하는 소규모 사무실에 어울립니다. 두 장비의 관리 계정과 네트워크 권한을 분리해야 하며, 한쪽 NAS가 감염됐을 때 다른 쪽의 백업 버전까지 지워지지 않는지 확인하십시오. 클라우드는 장소 분리와 자동 운영이 편리하지만, 장기 보관료와 다운로드 비용, 전체 복구에 필요한 인터넷 속도를 계산해야 합니다.

선택 기준은 '얼마나 많이 저장되는가'에서 끝나지 않습니다. 삭제된 사진 한 폴더만 되돌릴지, NAS 전체를 복구할지, 인터넷이 끊긴 상황에서도 복구해야 할지를 먼저 정해보세요. 복구 장면을 그린 뒤 매체를 고르면 저장 비용이 판단을 대신하지 않습니다.

## 백업이 실패하는 이유는 설정 화면 밖에 있습니다
첫 번째 실수는 백업 작업이 성공했다는 알림만 믿는 것입니다. 작업 완료는 정해진 파일 복사가 끝났다는 뜻이지, 필요한 버전이 실제로 열리고 복원된다는 뜻은 아닙니다. 두 번째 실수는 NAS와 백업 대상의 관리자 계정을 동일하게 쓰는 일이에요. 한 계정이 노출되면 복사본까지 삭제 권한을 얻을 수 있습니다.

세 번째는 보존 버전을 지나치게 적게 두는 방식입니다. 월요일에 파일이 암호화됐는데 수요일에야 알아차리면, 최근 상태만 남긴 백업은 이미 감염된 파일을 보관하고 있을 수 있습니다. 네 번째는 백업 용량이 부족해진 뒤 무작정 오래된 버전을 지우는 일입니다. 먼저 어떤 기간의 복구 지점이 필요한지 정하고, 보존 정책과 저장 용량을 함께 조정해야 합니다.

다섯 번째는 복구 목적지를 정하지 않는 것입니다. 원래 폴더에 바로 덮어쓰면 정상 파일과 손상 파일을 구분하기 어렵습니다. 별도의 테스트 폴더에 일부 파일을 복원해 열어보고, 파일명·날짜·폴더 구조가 보존됐는지 확인하는 절차가 있어야 합니다. 설정값보다 이 확인 과정이 실제 복구 가능성을 좌우합니다.

## 복구 검증 리허설이 백업의 마지막 단계입니다
한 달에 한 번이라는 주기는 설명을 위한 가정 예시입니다. 가정용 NAS에서 중요한 사진 폴더 10개와 문서 파일 일부를 별도 테스트 폴더로 복원하고, 파일이 열리는지와 최근 버전이 맞는지 확인하는 방식으로 리허설을 시작해볼 수 있습니다. 사무실 데이터처럼 복구 지연이 곧 업무 중단으로 이어지는 환경이라면 더 짧은 간격을 정하십시오.

리허설에서는 세 가지를 기록해두면 좋습니다. 첫째, 어느 날짜의 버전을 선택했는가. 둘째, 복원을 시작한 시각부터 파일을 확인한 시각까지 얼마나 걸렸는가. 셋째, 인증 오류·용량 부족·경로 오류가 발생했는가. 백업 프로그램은 무결성 검사 기능을 제공하더라도, 실제 업무 파일이 원하는 위치에서 열리는지까지 대신 판단해주지 않습니다.

복구가 끝난 뒤에는 원본 폴더를 덮어쓰지 말고 테스트 파일을 정리한 다음, 리허설 결과와 계정 정보를 별도로 기록하십시오. 복구 순서를 문서로 남겨두면 담당자가 바뀌거나 급한 장애가 발생했을 때 판단 시간이 줄어듭니다. NAS를 잘 운영한다는 말은 디스크 상태를 확인하는 데서 끝나지 않고, 되돌아갈 경로를 직접 확인했다는 뜻에 가깝습니다.

오늘은 RAID 상태 확인보다 먼저, NAS 밖에 있는 복사본 하나를 만들고 그중 한 파일을 직접 복원해보는 것은 어떨까요?