프로덕션 디스크 손상 복구: 하드웨어 고장 사례 연구
프로덕션 서버가 고장 나면 압박감이 엄청납니다—특히 그 서버가 실험실 장비에 필수적인 데이터베이스를 호스팅하고 있어 다운타임이 영구적인 데이터 손실을 의미할 때는 더욱 그렇습니다. 많은 엔지니어에게 실제 하드웨어 손상을 처음 접하는 순간은 OSI 모델의 물리 계층이 얼마나 취약한지 깨닫게 하는 경고가 됩니다.
이 글에서는 Windows 기반 MS SQL 서버에서 발생한 손상된 하드 드라이브 사례를 살펴보고, 근본 원인을 파악하기 위해 진행한 진단 과정과 데이터를 복구하기 위해 사용한 비전통적인 방법들을 소개합니다.
증상: 백업 실패와 데이터 손실
문제는 처음에 시스템 백업 프로세스가 실패하면서 나타났습니다. 초기에는 팀이 MS SQL 내부 백업 시스템을 사용해 데이터베이스를 덤프하는 빠른 해결책을 시도했습니다. 이는 일시적으로 작동했지만, 곧 사용자들은 특정 분석 결과에 접근할 수 없다고 보고했습니다.
Windows 이벤트 뷰어를 확인한 결과, 팀은 저수준 디스크 오류를 발견했습니다. 프로덕션 환경에서는 이러한 오류가 중요한 경고 신호입니다; 커뮤니티 전문가들이 언급했듯이 시스템 이벤트 로그에 기록된 디스크 오류는 일반적으로 I/O 계층이나 저수준 클래스 드라이버(예: msahci.sys)에서 발생하며, 파일 시스템 및 애플리케이션 계층 아래에 문제가 존재함을 나타냅니다.
진단 여정
하드웨어 고장의 근본 원인을 식별하려면 종종 배제 과정을 거칩니다. 이번 사례에서는 조사 과정이 네 가지 주요 단서로 진행되었습니다:
1. EDR 가설
일주일 전에 새로운 엔드포인트 탐지 및 대응(EDR) 시스템이 배포되었기 때문에 초기에는 보안 에이전트가 백업 프로세스에 간섭하고 있다고 의심했습니다. 그러나 EDR 에이전트를 비활성화하고 완전히 제거해도 결과가 나타나지 않았습니다.
2. 볼륨 섀도우 복사 서비스 (VSS)
추가 로그 분석 결과, 볼륨 섀도우 복사 서비스(VSS)가 스냅샷을 읽지 못하고 있음을 확인했습니다. VSS는 백업을 위해 디스크 볼륨 스냅샷을 관리하는 Windows 프레임워크입니다. 스냅샷을 읽을 수 없는 현상은 백업 소프트웨어 자체보다는 기본 스토리지에 문제가 있음을 강하게 시사했습니다.
3. 시스템 파일 손상
Windows 시스템 파일이 손상되었을 가능성을 의심한 팀은 dism /Online /Cleanup-Image /RestoreHealth와 sfc /scannow를 실행했습니다. 도구들이 문제를 감지했지만 복구하지 못했으며, 이는 손상이 OS 수준보다 더 깊은 곳에 있음을 시사했습니다.
4. "SQL 패치" 트리거
타임라인 분석 결과, 기술자가 최근 새로운 클라이언트 애플리케이션 버전을 위해 데이터베이스에 패치를 적용하는 SQL 스크립트를 실행한 것으로 나타났습니다. T-SQL이 직접 디스크에 불량 섹터를 기록할 수는 없지만, 해당 패치는 오랫동안 접근되지 않았던 감사 페이지에 무거운 I/O를 유발했을 가능성이 높습니다. 이 작업으로 인해 자기 신호가 약해진 섹터가 드러났으며, 디스크 고장을 무시할 수 없게 만들었습니다.
해결: 하드웨어 "수리" 메커니즘
디스크가 보증 기간 내에 있었기 때문에 공급업체(Dell)는 교체용 드라이브를 제공했지만 데이터 복구에 대한 지원은 하지 않았습니다. 팀은 이후 여러 소프트웨어 솔루션을 시도했으며, 결국 HDD Regenerator라는 도구를 사용해 성공을 거두었습니다.
소프트웨어가 하드 드라이브를 "수리"하는 방법
소프트웨어가 물리적인 디스크를 복구할 수 있다는 것은 직관에 반하는 것처럼 보일 수 있습니다. 그러나 이 과정은 두 가지 주요 메커니즘에 의존합니다:
- 신호 복원: 많은 "불량" 섹터는 물리적으로 긁힌 것이 아니라 "자기화가 약한" 상태입니다. 특정 자기 패턴으로 섹터를 반복적으로 읽고 다시 쓰면 소프트웨어가 신호를 복원하여 드라이브의 오류 정정 기능이 데이터를 신뢰성 있게 복구할 수 있는 수준으로 만들 수 있습니다.
- 펌웨어 재매핑: 섹터가 실제로 물리적으로 손상된 경우, 드라이브 내부 펌웨어가 해당 섹터를 불량으로 표시하고 예비 풀에 있는 여분 섹터로 논리 주소를 재매핑합니다.
손상이 물리적인 플래터 수준이 아니라 자기 신호 수준에서 발생했기 때문에 팀은 섹터를 복원하고 데이터베이스를 새 디스크로 성공적으로 마이그레이션할 수 있었습니다.
기술 사후 분석 및 교훈
RAID는 만병통치약이 아니다
일반적인 오해는 RAID(중복 배열 독립 디스크)가 모든 데이터 손실을 방지한다는 것입니다. RAID 1(미러링)은 전체 드라이브 고장으로부터 보호하지만, "무음" 손상이나 읽기 오류로 보고되는 불량 블록을 항상 방지하지는 못합니다. 한 커뮤니티 기여자는 실제 하드웨어 RAID 컨트롤러가 메타데이터에 불량 블록을 표시할 수 있지만, 미러링된 결함 위험은 여전히 존재한다고 언급했습니다.
SMART 모니터링의 중요성
이번 사례에서 가장 큰 실수 중 하나는 사전 하드웨어 모니터링이 없었다는 점입니다. S.M.A.R.T.(Self-Monitoring, Analysis, and Reporting Technology) 진단은 종종 고장 전 경고를 제공할 수 있습니다. "Current Pending Sectors"(C5)와 "Reallocated Sectors Count"(05)와 같은 속성을 모니터링하면 프로덕션 데이터베이스가 접근 불가능해지기 전에 드라이브 고장을 팀에 알릴 수 있었을 것입니다.
시스템 관리자에게 주는 핵심 교훈
- 복구 검증, 백업만이 아니라: 백업 작업이 성공했다고 해서 복구가 성공한다는 보장은 없습니다. 복원된 데이터의 무결성을 정기적으로 테스트하세요.
- 패치를 주요 변경으로 간주: 공급업체가 프로덕션 데이터베이스에서 실행하는 모든 스크립트는 고위험 이벤트로 간주해야 합니다: 실행 전 백업, 실행 중 모니터링, 실행 후 검증.
- 하드웨어 수명 주기 관리: 최신 프로덕션 환경에서는 SSD/NVMe로 전환하는 것이 성능뿐 아니라 움직이는 부품과 자기 감쇠와 관련된 고장률이 크게 낮아 권장됩니다.
- 호기심 유지: 표준 도구가 실패할 때, 심지어 구식으로 보이는 전문 복구 도구를 탐색하는 것이 중요한 데이터를 복구하는 열쇠가 될 수 있습니다.