Miklix

Ubuntu에서 mdadm 어레이의 실패한 드라이브 교체

게시됨: 2025년 2월 15일 오후 10시 2분 25초 UTC
마지막으로 업데이트되었습니다: 2026년 1월 12일 오전 8시 49분 57초 UTC

mdadm RAID 어레이에서 드라이브 오류가 발생하는 최악의 상황에 처했다면, 이 글에서 우분투 시스템에서 드라이브를 올바르게 교체하는 방법을 설명합니다.


이 페이지는 가능한 한 많은 사람이 이용할 수 있도록 영어에서 기계 번역되었습니다. 안타깝게도 기계 번역은 아직 완성된 기술이 아니므로 오류가 발생할 수 있습니다. 원하시는 경우 여기에서 영어 원문을 보실 수 있습니다:

Replacing a Failed Drive in an mdadm Array on Ubuntu

이 글의 정보는 우분투 18.04 및 해당 저장소에 포함된 mdadm 버전(작성 시점 기준 v4.1-rc1)을 기준으로 작성되었습니다. 다른 버전에서는 유효하지 않을 수 있습니다.

최근 제 홈 파일 서버에서 갑작스러운 드라이브 고장이 발생했습니다. 이 서버는 mdadm RAID-6 어레이로 구성된 9개의 드라이브로 이루어져 있습니다. 드라이브 고장은 언제나 불안한 일이지만, 다행히 교체용 드라이브를 신속하게 구할 수 있었고 다음 날 바로 배송받아 복구 작업을 시작할 수 있었습니다.

처음에 파일 서버를 구축할 때 좀 인색했던 게 사실입니다. NAS용 드라이브는 두 개(Seagate IronWolf)뿐이고 나머지는 데스크톱용 드라이브(Seagate Barracuda)입니다. 예상대로 데스크톱 드라이브 중 하나가 고장 났습니다(거의 3년 만에 말이죠). 완전히 먹통이 되어 데스크톱 USB 외장 케이스로 옮겨봤지만, 딸깍거리는 소리만 날 뿐 Ubuntu 20.04도 Windows 10도 인식하지 못했습니다.

자, 이제 교체 부분으로 넘어가죠 (그리고 네, 새로 산 드라이브는 아이언울프였어요. 이번 일을 통해 교훈을 얻었죠). 작동 중인 어레이에서 드라이브가 고장 나는 것도 무섭지만, 교체 방법을 제대로 모르면 더 무섭습니다. mdadm 어레이에서 드라이브 고장으로 교체해야 했던 건 이번이 처음은 아니지만, 다행히 그런 경우는 드물어서 보통은 관련 명령어를 찾아보면 되더라고요. 이번에는 나중에 참고하려고 간단한 가이드를 만들어 봤습니다.

우선, mdadm에서 오류 이벤트 이메일을 받으면 어떤 드라이브에 오류가 발생했는지 확인해야 합니다. 물론 장치 이름(제 경우에는 /dev/sdf)은 알려주지만, 시스템 부팅 시 장치 이름이 바뀔 수 있기 때문에 실제로 어떤 물리적 드라이브인지 파악하기는 쉽지 않습니다.

어떤 장치에 오류가 발생했는지조차 확실하지 않은 경우 다음 명령어를 사용하여 확인할 수 있습니다(/dev/md0을 사용 중인 RAID 장치 이름으로 바꾸십시오).

mdadm -–query -–detail /dev/md0

앞서 언급했듯이 제 경우에는 /dev/sdf였으므로, 이를 기준으로 계속 진행하겠습니다.

그런 다음 다음 명령어를 실행하여 고장난 드라이브의 일련번호를 찾아볼 수 있습니다.

smartctl -–all /dev/sdf | grep -i 'Serial'

(smartctl을 찾을 수 없는 경우 Ubuntu에 smartmontools 패키지를 설치해야 합니다.)

그런 다음 일련 번호를 드라이브의 물리적 라벨에 있는 일련 번호와 비교하여 어떤 드라이브에 문제가 발생했는지 확인할 수 있습니다.

하지만 이번에는 운이 좋지 않았습니다. 드라이브가 완전히 고장 나서 SMART 정보는 물론 시리얼 번호를 포함한 다른 데이터조차 제공하지 못했습니다.

서버에 직접 접근할 수 있었고 (물리적 하드 드라이브를 직접 교체하려면 당연히 필요하죠 ;-)) 디스크 고장 당시 서버는 실제로 작동 중이었으며 (RAID-6 이중화 덕분에 이후에도 정상적으로 작동했습니다), 그래서 아주 단순하지만 실제로 매우 효과적이고 당연한 방법을 사용했습니다. 대용량 파일을 서버에 복사하고 어떤 하드 드라이브의 표시등이 깜빡이지 않는지 확인하는 것이었죠. 몇 초 만에 범인을 찾아낼 수 있었습니다.

이제 물리적 드라이브를 제거하기 전에 다음 명령어를 실행하여 mdadm에 이러한 의도를 공식적으로 알리는 것이 좋습니다(장치 이름은 필요에 따라 사용자 환경에 맞게 변경하십시오).

mdadm -–manage /dev/md0 -–remove /dev/sdf1

성공적으로 완료되면 mdadm은 드라이브를 "핫 제거"했다는 메시지를 표시합니다. 이는 가상 RAID 장치가 실제로 실행 중인 상태이기 때문인 것으로 보입니다.

장치 또는 리소스가 사용 중입니다"와 유사한 오류 메시지가 표시되면 mdadm이 드라이브의 완전한 고장을 제대로 인식하지 못한 것일 수 있습니다. 이를 수정하려면 다음 명령을 실행하십시오(장치 이름은 필요에 따라 적절하게 변경해야 합니다).

mdadm --manage /dev/md0 --fail /dev/sdf

그 후에는 이전 명령어를 사용하여 어레이에서 해당 장치를 제거할 수 있습니다.

이제 실제로 드라이브를 교체할 차례입니다. 만약 사용하는 컴퓨터와 컨트롤러가 핫 스와핑을 확실히 지원한다면, 시스템을 종료하지 않고도 교체할 수 있습니다. 이는 핫 스와핑을 지원하는 것이 확실한 제대로 된 서버 하드웨어에서 실행되는 중요한 운영 시스템에서 권장되는 방법입니다. 하지만 제 개인 파일 서버는 일반 소비자용 데스크톱 마더보드에 PCIe 슬롯에 이름 없는 SATA 컨트롤러 두 개를 추가하여 SATA 포트를 늘린 형태입니다.

SATA는 일반적으로 핫 스와핑을 지원하지만, 이 구성에서는 위험을 감수하고 싶지 않았기 때문에 드라이브를 교체하는 동안 컴퓨터를 종료하기로 했습니다.

그 전에, /etc/fstab 파일에서 RAID 장치 부분을 주석 처리하는 것이 좋습니다. 이렇게 하면 우분투가 다음 부팅 시 RAID 어레이를 자동으로 마운트하려고 시도하지 않도록 할 수 있습니다. RAID 어레이 성능 저하로 인해 시스템이 멈추고 복구 모드로 진입해야 할 수도 있기 때문입니다. 데스크톱 시스템이라면 큰 문제가 아닐 수 있지만, 저는 모니터와 키보드를 연결하지 않고 서버를 헤드리스 모드로 실행하고 있으므로 이 문제는 꽤 번거로울 수 있습니다.

새 드라이브를 설치하고 컴퓨터를 부팅한 후, lsblk 또는 다른 명령어를 사용하여 드라이브를 확인하십시오. 다른 설정을 변경하지 않았다면, 새 드라이브는 교체한 기존 드라이브와 동일한 이름을 가질 가능성이 높습니다(반드시 그런 것은 아닙니다). 제 경우에는 새 드라이브도 /dev/sdf로 명명되었습니다.

제 어레이는 물리적 드라이브가 아닌 파티션을 기반으로 하기 때문에, 작동 중인 드라이브의 파티션 테이블을 새 드라이브로 복사하여 완전히 동일하게 만들어야 했습니다. 만약 어레이를 물리적 드라이브에서 실행한다면 이 단계를 건너뛸 수 있습니다.

저는 이 작업을 위해 sgdisk를 사용하여 /dev/sdc의 파티션 테이블을 /dev/sdf로 복사했습니다. 장치 이름은 사용자의 환경에 맞게 적절히 변경해야 합니다.

순서에 유의하세요. "대상" 드라이브를 먼저 나열해야 합니다! 제게는 조금 직관적이지 않지만, 어레이에서 드라이브 오류가 또 발생하지 않도록 제대로 입력해야 합니다 ;-)

sgdisk -R /dev/sdf /dev/sdc

UUID 충돌을 방지하려면 새 드라이브에 대한 새 UUID를 생성하십시오.

sgdisk -G /dev/sdf

드디어 새 드라이브를 어레이에 추가하고 재구축 작업을 시작할 시간이 왔습니다! (사실 파티는 아니고, 꽤 느리고 불안한 과정입니다. 이 시점에 또 다른 드라이브가 고장 나면 정말 곤란하거든요. 맥주 한 잔이면 좀 나아질지도 모르겠네요.)

어쨌든, 새 드라이브를 어레이에 추가하려면 다음 명령을 실행하십시오(다시 한번 말씀드리지만, 장치 이름은 필요에 따라 적절하게 바꿔야 합니다).

mdadm -–manage /dev/md0 -–add /dev/sdf1

모든 것이 순조롭게 진행된다면, 드라이브는 문제없이 어레이에 추가될 것입니다. 기본적으로 "핫 스페어"로 추가되는 것으로 알고 있지만, 이 어레이에는 디스크 하나(고장난 디스크)가 없기 때문에 즉시 사용되기 시작하고 재구축 프로세스가 시작됩니다.

다음과 같은 방법으로 상황을 주시할 수 있습니다.

watch cat /proc/mdstat

이 작업은 시간이 꽤 걸릴 겁니다. 제 서버(대부분 일반 소비자용 하드웨어와 데스크톱 드라이브로 구성된)에서도 100MB/초가 조금 안 되는 속도가 나왔습니다. RAID-6 구성이라 재구축 과정에서 패리티 계산이 많이 필요하다는 점을 고려해 주세요. RAID-10이었다면 훨씬 빨랐을 겁니다. 참고로 제 서버에는 AMD A10 9700E 쿼드 코어 CPU가 탑재되어 있습니다("E"는 클럭 속도를 낮춘 에너지 효율 모델이라는 뜻으로, 아주 빠르지는 않습니다). 제 시스템에는 8TB 드라이브 9개가 사용되었는데, 전체 재구축에 24시간이 조금 넘게 걸렸습니다.

재구축 작업 중에도 원한다면 어레이의 파일 시스템을 마운트하여 평소처럼 사용할 수 있지만, 저는 재구축이 완료될 때까지 그대로 두는 것을 선호합니다. 드라이브 하나가 고장 나면 다른 드라이브도 곧 고장 날 수 있으므로, 재구축 작업이 최대한 빨리 완료되도록 해야 합니다. 재구축 중에 또 다른 드라이브가 고장 나는 것을 원치 않기 때문입니다. 따라서 필수적인 작업 외에는 다른 I/O 작업으로 재구축 작업에 부담을 주지 마십시오.

작업이 완료되면 /etc/fstab 파일에 해당 내용을 추가하고 재부팅한 후 파일을 사용하세요 :-)

블루스카이에서 공유하기페이스북에서 공유하기LinkedIn에서 공유하기Tumblr에 공유하기X에서 공유LinkedIn에서 공유하기Pinterest에 고정

미켈 크리스텐슨

저자 소개

미켈 크리스텐슨
남자 이름은 miklix.com의 창시자이자 소유자입니다. 전문 컴퓨터 프로그래머/소프트웨어 개발자로 20년 이상 경력을 쌓았으며 현재 유럽의 대형 IT 기업에서 정규직으로 근무하고 있습니다. 블로그를 운영하지 않을 때는 여가 시간을 다양한 관심사, 취미, 활동으로 보내며 이 웹사이트에서 다루는 다양한 주제에 어느 정도 반영되어 있습니다.