SATA SSD는 컨트롤러 또는 링크가 완전한 전원 차단으로만 해소되는 비정상 상태에 남아 있을 때 웜 리부트 후 사라질 수 있습니다.
일반적인 재부팅은 소프트웨어를 초기화하지만 SSD, 컨트롤러, 백플레인 또는 메인보드 포트의 대기 전원을 차단하지 않을 수 있습니다. 링크가 준비 상태로 전환되지 못하면 파티션, 파일 시스템, 풀 또는 애플리케이션이 관여하기 전에 드라이브가 사라질 수 있습니다. 완전 종료는 컨트롤러와 링크를 더 깊이 초기화하므로 진단 결과가 달라집니다. 스토리지를 즉시 다시 구축하거나 파일 시스템을 교체하기보다, 먼저 장치를 인식하지 못하는 가장 낮은 계층을 확인하세요.
BIOS, SATA 컨트롤러 또는 운영 체제 중 어느 단계에서 SSD를 인식하지 못하는지 확인
웜 리부트 전후에 SSD가 BIOS 또는 UEFI, 운영 체제의 컨트롤러 화면, 블록 장치 목록, 파티션 테이블 및 마운트된 파일 시스템에 표시되는지 기록하세요.
Linux libATA 가이드는 드라이버가 SATA 링크가 준비될 때까지 기다리는 방식과 준비에 실패할 때 장치를 없는 것으로 처리할 수 있는 상황을 설명합니다. 이 SATA 링크 복구 모델은 파일 시스템 계층에 도달하기 전에 디스크가 사라질 수 있는 이유를 설명합니다.
BIOS에서도 SSD를 잃는다면 펌웨어, 포트 전원, 링크 초기화, 케이블 및 드라이브 컨트롤러에 집중하세요. BIOS에서는 SSD가 보이지만 운영 체제에서는 보이지 않는다면 운영 체제 로그를 보존하고 드라이버 열거 및 컨트롤러 모드를 점검하세요.
웜 리부트, 완전 종료 및 전원 차단 결과 비교
일반 재부팅, 운영 체제 종료 후 즉시 전원 켜기, 그리고 대기 전원이 떨어질 만큼 충분히 전원을 차단한 후 종료 및 재부팅을 테스트하세요. 각 상태를 최소 두 번씩 반복하세요.
PCI 장치 화면은 컨트롤러 존재 여부와 스토리지 검색을 구분하는 명확한 기준을 제공합니다. lspci 유틸리티를 사용하면 SSD 블록 장치가 없어도 재부팅 전후에 AHCI 또는 SATA 컨트롤러 자체가 변경되었는지 확인할 수 있습니다.
완전한 전원 차단을 해야만 드라이브가 복구된다면 유지된 컨트롤러 상태, 불완전한 SATA PHY 재설정, SSD 펌웨어 상태 또는 전원 관리 상호작용이 가장 유력합니다. 이 패턴은 일반적인 마운트 또는 파티션 문제와는 일치하지 않는 경우가 많습니다.
최초 SATA 링크 및 재설정 오류 확인
콜드 부트를 수행하기 전에 웜 리부트 실패 시점의 커널 또는 시스템 이벤트 로그를 저장하세요. 링크 다운 메시지, COMRESET 실패, 장치 준비 시간 초과, IDENTIFY 명령 실패 또는 반복되는 포트 재설정을 확인하세요.
SATA 액티브 링크 전원 관리는 링크를 저전력 상태로 전환할 수 있으며, 일부 컨트롤러와 SSD 조합에서는 이를 제대로 처리하지 못할 수 있습니다. ArchWiki는 호환되지 않는 장치에서 공격적인 링크 전원 관리가 심각한 문제를 일으킬 수 있다고 경고합니다.
파일 시스템이나 풀이 사용할 수 없다고 표시되는 이후 메시지보다 최초 오류가 더 중요합니다. 이후의 모든 케이블, 슬롯 및 펌웨어 테스트를 동일한 경로와 연결할 수 있도록 포트 번호와 드라이브 모델을 보존하세요.
SATA 케이블, 전원 커넥터 및 인터페이스 오류 카운터 점검
서버 전원을 완전히 끈 상태에서 SATA 데이터 케이블과 전원 커넥터를 다시 연결하세요. 느슨한 잠금 탭, 심하게 꺾인 부분, 분배기, 백플레인 커넥터 및 어댑터를 점검하세요.
Unraid의 스토리지 문제 해결 가이드는 UDMA CRC 오류가 증가하면 즉시 파일 시스템을 복구하기보다 데이터 케이블, 전원 케이블, 컨트롤러 연결 및 포트를 점검해야 한다고 설명합니다.
과거의 CRC 카운트만으로 현재 케이블에 문제가 있다고 단정할 수는 없습니다. 원시 값을 기록하고 제어된 재부팅 주기를 한 번 수행한 뒤 카운터가 증가하는지 확인하세요.
SSD SMART, 오류 로그 및 펌웨어 상태 검토
드라이브가 표시될 때 SSD 모델, 일련 번호, 펌웨어 버전, 전원 사이클 횟수, 비정상 종료 횟수, 인터페이스 오류 및 사용 가능한 장치 오류 로그를 수집하세요.
smartctl 참조 문서는 SMART 속성과 오류 로그를 통해 플래시 상태 문제와 전송 또는 컨트롤러 오류를 구분하는 방법을 설명합니다.
SSD 펌웨어 업데이트는 백업, 모델 호환성 및 공급업체의 복구 지침을 확인한 후에만 적용하세요. 성공적인 해결 방법을 식별할 수 있도록 한 번에 하나의 펌웨어 계층만 변경하세요.
재검색은 진단 목적으로만 사용
컨트롤러는 계속 표시되지만 디스크가 사라진 경우, 모든 활성 I/O를 중지한 후 지원되는 스토리지 재검색을 한 번 수행하세요. 전원 사이클 없이 SSD가 다시 나타나는지 기록하세요.
Microsoft는 DiskPart rescan 명령이 새로 감지된 디스크를 찾는다고 설명합니다. 따라서 운영 체제의 검색 지연인지 컨트롤러 수준에서 드라이브가 없는 것인지 구분하는 데 유용합니다.
재검색에 성공했다고 해서 영구적인 해결책은 아닙니다. 이는 다른 검색 시도 후 컨트롤러와 SSD가 통신할 수 있음을 보여줄 뿐이므로, 남은 문제는 펌웨어, 드라이버, 컨트롤러 모드 또는 링크 초기화에서 찾아야 합니다.
교체 전에 드라이브, 포트 및 컨트롤러 분리 테스트
데이터를 백업한 후 SSD를 정상 작동이 확인된 SATA 포트로 옮기고 정상 케이블을 사용하거나, 정상 작동이 확인된 드라이브를 기존 경로에서 테스트하세요. 각 주기마다 한 번에 하나의 구성 요소만 변경하세요.
ZimaSpace의 SATA 케이블과 드라이브 문제를 구분하는 가이드는 간헐적으로 장애가 발생하는 스토리지 경로에 적용할 수 있는 분리 테스트 절차를 제공합니다.
SSD가 반복적인 웜 리부트, 콜드 부트, 유휴 상태 및 지속적인 읽기 작업 중에도 계속 표시되고 새로운 링크 오류가 발생하지 않으면 문제가 해결된 것입니다. 정상 작동이 확인된 포트와 케이블에서도 계속 사라지거나 장치 오류가 악화된다면 해당 드라이브를 주요 데이터 저장용으로 사용하지 마세요.
지원 및 팁
더 읽어보기

Plex가 다른 Docker 컨테이너와 GPU를 공유할 수 있나요?
Plex와 다른 컨테이너가 동일한 GPU에 함께 액세스할 수 있는 경우가 많지만, 드라이버 지원, 디바이스 매핑, 비디오 엔진 부하, 메모리, 복구 동작을 테스트해야 합니다.

Plex 오류가 클라이언트에서 발생한 것인지 서버에서 발생한 것인지 확인하는 방법
다른 클라이언트에서 동일한 항목을 재현하고, 세션 경로를 비교한 다음, 범위 분석을 통해 장애가 실제로 발생한 위치를 확인한 후에만 서버 증거를 수집하세요.

Plex 캐시 및 트랜스코딩 임시 저장소 구성 방법
영구 Plex 상태는 보호하면서 트랜스코딩 임시 파일은 적합한 로컬 저장소에 배치한 다음, 정리 상태와 여유 공간 및 재시작 동작을 확인하세요.

