RAW로 잡혀버린 드라이브 데이터 살릴 수 있을까?
파일 시스템 손상, RAW 인식 chkdsk로 해결
RAW처럼 표시된 경우에 대한 작업 기록입니다.
chkdsk /f는 모든 RAW 드라이브를 복구하는 명령이 아니며,
원본 디스크의 파일 시스템을 직접 수정하는 작업입니다.
중요한 데이터가 들어 있는 디스크라면 먼저 포맷하거나 chkdsk를 실행하지 말고,
추가 쓰기를 중단한 뒤 디스크 이미지 백업 또는 전문 데이터 복구 절차를 우선 고려해야 합니다.
특히 SSD는 포맷, 삭제, 파티션 재생성 이후 TRIM과 내부 가비지 컬렉션이 개입할 수 있어
복구 가능성이 빠르게 낮아질 수 있습니다.
Linux ext4, macOS APFS/HFS+, NAS 전용 파일 시스템, 암호화 볼륨,
파티션 테이블 손상, 물리 고장 디스크에는 해당 방식을 적용하지 마세요.
모든 작업은 개인의 책임 하에 진행해야 하며,
이에 따른 데이터 손실, 파일 손상, 장치 손상, 추가 고장 등
어떠한 불이익에 대해서도 작성자는 책임지지 않습니다.

어느 날 갑자기 디스크가 열리지 않는 경우가 있다.
분명 디스크 자체는 Windows에서 잡힌다.
장치 관리자나 디스크 관리에서도 디스크가 아예 사라진 것은 아니다.
그런데 탐색기에서 드라이브를 열려고 하면 접근이 되지 않는다.
오류 검사를 실행하려고 해도 실패하고, 조각 모음이나 드라이브 최적화도 정상적인 디스크를 참조하지 않는다는 식으로 에러가 발생한다.
이번 경우도 그랬다.
디스크는 잡히는데, 드라이브 접근이 되지 않았다.
Windows 기본 오류 검사도 되지 않았고, 조각 모음도 실행되지 않았다.
결론부터 말하면 이번 사례는 관리자 권한 CMD에서 chkdsk를 실행해 복구할 수 있었다.
다만 이 글은 chkdsk를 무조건 먼저 실행하라는 글이 아니다.
특히 SSD라면 포맷은 절대 먼저 하면 안 되고, chkdsk도 원본 디스크에 변경을 가하는 명령이기 때문에
상황에 따라 신중히 판단해야 한다.
1. 증상
이번에 확인한 증상은 다음과 같았다.
| 항목 | 확인 결과 |
|---|---|
| 디스크 인식 | Windows에서 드라이브 자체는 인식됨 |
| 탐색기 접근 | 접근 불가 |
| 오류 검사 | 실행 불가 |
| 조각 모음 / 최적화 | 정상 디스크가 아니라는 식의 오류 발생 |
| 파일 시스템 상태 | RAW 또는 파일 시스템 손상 상태로 보임 |
| 최종 조치 | chkdsk 실행 후 접근 가능 상태로 복구 |
RAW 상태라는 것은 Windows가 해당 파티션의 파일 시스템을
정상적으로 해석하지 못하는 상태에 가깝다.
일반적으로 드라이브는 NTFS, FAT32, exFAT 같은 파일 시스템으로
인식되어야 한다.
그런데 파일 시스템 메타데이터가 손상되었거나,
파티션 정보가 꼬였거나,
디스크의 일부 영역을 정상적으로 읽지 못하면
Windows가 해당 볼륨을 RAW로 표시할 수 있다.
2. 먼저 하면 안 되는 것
RAW로 잡힌 디스크를 열려고 하면 Windows에서 보통 이런 메시지를 띄운다.


데이터 복구가 목적이라면
"여기서
포맷을 누르면
안 된다."
데이터가 필요 없는 디스크라면 포맷 후 다시 사용하면 된다.
하지만 내부 자료를 살려야 하는 상황이라면 포맷은 최후의 선택이다.
그 이유를 설명하자면,
| 상황 | 이유 |
|---|---|
| 내부 파일을 살려야 함 | 파일 시스템 구조가 새로 작성될 수 있음 |
| 백업이 없음 | 원본 손상 시 복구 난이도 상승 |
| RAW 원인이 불명확함 | 논리 손상인지 물리 고장인지 아직 모름 |
| SSD임 | TRIM, 가비지 컬렉션 때문에 복구 가능성이 더 빠르게 떨어질 수 있음 |
| 외장하드 또는 USB 저장장치임 | 케이블, 전원, USB-SATA 브리지 문제일 수도 있음 |
즉, RAW 상태에서 가장 먼저 할 일은 멈추는 것이다.
1. 포맷하지 않기
2. 추가 쓰기 중단
3. 디스크 상태 확인
4. 가능하면 이미지 백업
5. 복제본 기준으로 복구 시도3. SSD라면 작업을 더 조심해야 하는 이유
HDD도 복구 전 포맷은 피해야 하지만,
SSD는 더 조심해야 한다.
그 이유는 HDD와 SSD의 데이터 기록 방식이 다르기 때문이다.
아래 영상은 하드디스크, SSD 데이터 쓰기/읽기 원리에 대해 간략히
설명해주는 영상이다.
참조하면 좋다.
SSD 원리
출처: 코딩하는거니
HDD 원리
영상 두 개를 정리하자면,
HDD는 자기 디스크 표면에 헤드를 이용해
자성 방향을 바꿔 데이터를 기록한다.
파일을 삭제하거나 빠른 포맷을 한다고 해서
실제 데이터 영역이 즉시 전부 지워지는 것은 아니다.
HDD는 회전하는 플래터 위의 물리 섹터를
헤드가 찾아가 기록하는 방식이기 때문에,
삭제할 때마다 기존 파일이 차지하던 모든 섹터를 검색하고,
즉시 데이터를 덮어쓰는 방식은 시간이 많이 걸리고 비효율적이다.
그래서 일반적인 삭제나 빠른 포맷에서는
파일 시스템의 메타데이터가 먼저 변경되고,

기존 데이터가 있던 물리 섹터는 새 데이터가
기록되어 덮어쓰기 전까지 자성 흔적이 남아 있을 수 있다.
반면 SSD는 NAND 셀에 전기적으로 데이터를 기록한다.
데이터를 지울 때도 셀 하나하나를 즉시 지우는 방식이 아니라,
블록 단위 erase와 컨트롤러 내부 처리가 개입한다.
삭제나 포맷 이후 TRIM이 전달되면 SSD 컨트롤러는 해당 영역을
더 이상 유효한 데이터로 보지 않을 수 있다.

이후 가비지 컬렉션이나 블록 단위 정리 과정이 진행되면,
기존 데이터가 저장되어 있던 NAND 셀의 전하 상태가 초기화될 수 있어
지워진 데이터에 접근하기 어려워질 수 있다.
특히 요즘 사용하는 내장 SATA SSD나 NVMe SSD는
대부분 TRIM을 지원한다.
따라서 파일 삭제나 빠른 포맷 이후
TRIM 또는 UNMAP 힌트가 매우 빠르게 전달될 수 있다.
이 과정은 사용자가 체감하기 전에 이미 진행될 수 있기 때문에,
삭제 직후 “바로 전원을 끄면 살릴 수 있지 않을까?”라고 기대하기는 어렵다.
TRIM이 전달되고 SSD 컨트롤러가 해당 영역을 무효 데이터로 처리한 상태라면,
일반적인 복구 프로그램으로 지운 파일을 되살리기는 매우 어렵다고 봐야 한다.
다만 SSD라고 해서 삭제나 포맷 직후 항상 즉시 완전히 사라지는 것은 아니다.
TRIM 지원 여부, 연결 방식, USB-SATA 브리지, 운영체제,
파일 시스템, SSD 컨트롤러, 전원 유지 시간에 따라 결과는 달라질 수 있다.
4. HDD와 SSD의 차이
앞의 내용을 정리하면 다음과 같다.

HDD는 삭제나 빠른 포맷 이후에도 실제 데이터가 있던 물리 영역이 새 데이터로 덮이기 전까지 흔적이 남을 수 있다.
반면 SSD는 삭제나 포맷 이후 TRIM과 내부 정리 작업이 개입하면 복구 가능성이 더 빠르게 낮아질 수 있다.
따라서 RAW로 잡힌 디스크에 중요한 데이터가 있다면,
HDD든 SSD든 포맷을 먼저 누르면 안 된다.
특히 SSD는 단순히 “파일 목록만 지우는 문제”로 끝나지 않을 수 있기 때문에,
원본에 직접 작업하기 전에 이미지 백업을 우선 고려하는 편이 안전하다.
5. 이번 경우의 판단
디스크가 아예 죽은 상태는 아니었다.
용량도 잡혔고, Windows에서 장치 자체는 확인되었다.
따라서 컨트롤러 사망이나 완전한 물리 고장보다는
파일 시스템 메타데이터 손상 쪽 가능성이 높다고 판단했다.
그래서 관리자 권한 CMD에서 chkdsk를 실행했다.
단, 이 판단은 이번 사례 기준이다.
중요한 원본 데이터가 들어 있는 SSD라면 원칙적으로 이미지 백업이 먼저다.
6. 실행한 명령어
먼저 관리자 권한으로 명령 프롬프트를 실행한다.

문제가 발생한 드라이브 문자를 확인한다.
예를 들어 문제가 된 드라이브가 D:라면 다음 명령을 입력한다.
chkdsk D: /f7. 옵션설명
처음부터 /r을 사용하는 경우도 있지만, 이번에는 /f를 먼저 사용했다.
| 옵션 | 의미 | 특징 |
|---|---|---|
/f | 파일 시스템 오류 수정 | 비교적 기본적인 논리 오류 수정 |
/r | 불량 섹터 검색 및 읽을 수 있는 정보 복구 시도 | 시간이 오래 걸리고 디스크 부하가 큼 |
/x | 필요한 경우 볼륨을 먼저 분리 | 사용 중인 볼륨 검사 시 필요할 수 있음 |
| 옵션 없음 | 상태 확인 | 오류를 수정하지 않음 |
이번 경우는 물리 배드섹터 문제보다는
파일 시스템 손상으로 판단했기 때문에 /f를 먼저 실행했다.
특히 HDD에서 /r은 전체 표면 검사에
가까운 작업이 포함되어 시간이 오래 걸린다.
상태가 좋지 않은 디스크라면 긴 검사 과정 자체가 부담이 될 수 있다.
SSD에서도 무리한 전체 검사는 좋은 선택이 아닐 수 있다.
중요한 데이터가 있다면
원본에 직접 여러 복구 명령을 반복하는 것보다
이미지 백업 후 복제본에서 작업하는 편이 더 안전하다.
8. 실행 결과

chkdsk /f 실행 후, RAW처럼 보이던 드라이브가
다시 접근 가능한 상태가 되었다.
탐색기에서 드라이브가 열렸고, 기존 파일 목록도 확인할 수 있었다.
9. 항상 성공하는 방법은 아니다
중요한 부분은 여기다.
chkdsk /f로 이번에는 복구가 되었지만,
모든 RAW 드라이브가 이 방법으로 복구되는 것은 아니다.
RAW 상태에서 chkdsk를 실행하면 아래와 같은 메시지가 나올 수도 있다.
CHKDSK is not available for RAW drives.이 경우 Windows가 해당 볼륨을 chkdsk로 검사 가능한
정상 파일 시스템으로 해석하지 못하는 상태다.
즉, 디스크 관리에서는 RAW로 보이더라도
내부적으로 NTFS 구조 일부가 남아 있어서 chkdsk가 동작하는 경우가 있고,
반대로 파일 시스템 구조가 더 심하게 손상되어chkdsk 자체가 거부되는 경우도 있다.
이번 사례는 전자에 가까웠다.
RAW로 보임→ 하지만 NTFS 구조 일부가 남아 있음→ chkdsk가 파일 시스템 복구 가능→ /f 옵션으로 오류 수정→ 드라이브 접근 가능반대로 아래처럼 진행되는 경우도 있다.
RAW로 보임→ 파일 시스템 구조를 거의 해석하지 못함→ chkdsk 실행 불가→ 복구 프로그램 또는 전문 복구 영역따라서 chkdsk /f는 RAW 드라이브 만능 해결책이 아니다.
10. 왜 이런 일이 생겼을까?
정확한 원인은 디스크 상태를 더 깊게 분석해야 알 수 있다.
| 가능 원인 | 설명 |
|---|---|
| 비정상 종료 | 파일 시스템 기록 중 전원 차단 |
| USB 저장장치 강제 제거 | 쓰기 캐시가 반영되기 전 분리 |
| 파일 시스템 메타데이터 손상 | MFT, 인덱스, 비트맵 등 NTFS 구조 오류 |
| 케이블 / 포트 불량 | 연결 불안정으로 인한 읽기·쓰기 오류 |
| 외장 케이스 문제 | USB-SATA 브리지 또는 전원 공급 문제 |
| 디스크 노후화 | 읽기 오류, 배드 섹터, NAND 오류 누적 |
| 컨트롤러 문제 | 저장장치 내부 컨트롤러 이상 |
특히 외장 SSD나 외장 HDD라면 디스크 자체만 볼 것이 아니라
케이블, USB 포트, 전원 공급, 외장 케이스 상태도 함께 확인해야 한다.
디스크 자체에는 문제가 없더라도 USB-SATA 브리지나,
케이블 접촉 불량 때문에 쓰기 작업이 비정상적으로 끊기고,
그 결과 파일 시스템이 손상될 수 있다.
따라서 외장 저장장치는 사용 후 바로 뽑기보다,
Windows의 하드웨어 안전하게 제거 기능을 사용해 연결을 해제한 뒤
물리적으로 분리하는 것이 좋다.
이 과정은 쓰기 캐시가 남아 있는 상태에서 저장장치가 분리되는 상황을
줄이는 데 도움이 된다.


11. 중요한 데이터라면 chkdsk /f도 바로 실행하지 않는 편이 안전하다
chkdsk /f는 읽기 전용 명령이 아니다.
/f 옵션은 파일 시스템 오류를 수정한다.
즉, 원본 디스크에 변경 작업을 수행한다.
이번 사례에서는 chkdsk /f가 좋은 결과를 냈지만,
다음과 같은 상황이라면 바로 실행하지 않는 편이 낫다.
| 상황 | 권장 판단 |
|---|---|
| 중요한 원본 자료가 하나뿐임 | 이미지 백업 우선 |
| SSD에 중요한 데이터가 있음 | 포맷 금지, 원본 쓰기 최소화 |
| 디스크에서 이상 소음 발생 | 즉시 중단, 전문 복구 검토 |
| 연결과 해제가 반복됨 | 케이블/전원/케이스 점검 우선 |
| 용량이 이상하게 표시됨 | 컨트롤러 또는 파티션 문제 가능성 |
chkdsk가 RAW라며 거부함 | 복구 프로그램 또는 전문 복구 검토 |
| 복구 실패 시 손실이 큼 | 원본 작업 금지 |
데이터 복구의 기본은 원본 보존이다.
원본 디스크에 직접 수정= 성공하면 빠름= 실패하면 손상 확대 가능반대로 이미지 백업 후 복제본에서 작업하면 다음 장점이 있다.
원본 보존→ 복제본에서 복구 시도→ 실패해도 다시 다른 방법 시도 가능업무 자료, 사진, 문서, 회계 자료, 프로젝트 파일처럼
중요한 데이터라면 chkdsk /f를 원본에 바로 실행하기 전에
이미지 백업부터 고려하는 편이 맞다.
12. SSD RAW 드라이브에서 권장 순서
SSD가 RAW로 잡혔고,
내부 데이터가 필요하다면 순서는 다음이 안전하다.
| 순서 | 작업 | 이유 |
|---|---|---|
| 1 | 포맷 취소 | 새 파일 시스템 생성 및 TRIM 가능성 방지 |
| 2 | 추가 쓰기 중단 | 기존 데이터 영역 훼손 방지 |
| 3 | 케이블/포트/외장 케이스 확인 | 단순 연결 문제 배제 |
| 4 | SMART 상태 확인 | 물리적 이상 여부 확인 |
| 5 | 가능하면 디스크 이미지 백업 | 원본 보존 |
| 6 | 복제본 기준 복구 시도 | 실패해도 원본 유지 |
| 7 | 논리 손상으로 판단될 때 chkdsk /f 검토 | 파일 시스템 복구 시도 |
| 8 | 복구 후 즉시 다른 디스크로 백업 | 재발 또는 추가 손상 대비 |
여기서 가장 중요한 것은 첫 번째다.
포맷하지 않기SSD에서는 포맷이 단순 초기화처럼 보이더라도 복구 관점에서는 손실 가능성을 키우는 행동이 될 수 있다.
13. 복구 후 확인해야 할 것
드라이브가 다시 열린다고 해서
바로 정상이라고 단정하면 안 된다.
복구 후에는 먼저 필요한 자료를 다른 저장장치로 복사해야 한다.
그다음 상태 확인을 진행하는 편이 좋다.
13-1. 파일 접근 확인
아래 항목을 확인한다.
| 확인 항목 | 이유 |
|---|---|
| 주요 폴더 열림 여부 | 디렉터리 구조 복구 확인 |
| 주요 파일 열람 가능 여부 | 실제 데이터 접근 확인 |
| 대용량 파일 복사 가능 여부 | 읽기 오류 여부 확인 |
| 파일명 깨짐 여부 | 인덱스 손상 여부 확인 |
| 일부 파일 누락 여부 | 복구 과정에서 손실 발생 여부 확인 |
드라이브가 열린다고 해서 모든 파일이 정상이라는 뜻은 아니다.
파일 목록은 보이지만 일부 파일이 열리지 않거나,
복사 중 오류가 발생할 수 있다.
13-2. chkdsk 상태 확인
복구 후 상태 확인용으로는 옵션 없이 실행할 수 있다.
예를 들어 D: 드라이브라면 다음과 같이 입력한다.
chkdsk D:13-3. SMART 상태 확인
HDD나 SSD 모두 SMART 상태를 확인하는 것이 좋다.
확인할 항목은 다음과 같다.
| 항목 | 의미 |
|---|---|
| 재할당 섹터 수 | HDD에서 물리 섹터 문제 가능성 |
| 보류 중인 섹터 수 | 읽기 불안정 섹터 가능성 |
| CRC 오류 | 케이블/연결 문제 가능성 |
| 사용 시간 | 노후화 판단 참고 |
| SSD 수명 관련 항목 | NAND 마모도 참고 |
| 미디어 오류 | SSD 내부 읽기/쓰기 오류 가능성 |
SMART가 나쁘다면 해당 디스크는 계속 쓰지 않는 편이 안전하다.
Tags
RAW드라이브 #RAW파티션 #RAW복구 #데이터복구 #디스크복구 #하드디스크복구 #SSD복구 #chkdsk #chkdsk_f #드라이브접근불가 #디스크접근불가 #파일시스템손상 #포맷주의 #SSD포맷주의 #TRIM #외장하드복구 #외장SSD복구 #윈도우디스크복구 #파티션복구 #저장장치복구