RAID 어레이 오류, 손상된 NAS 스토리지 풀 및 재구축 안전¶

가정 또는 소규모 기업의 NAS(Network Attached Storage) 기기(예: Synology DiskStation, QNAP Turbo NAS, TrueNAS 또는 Unraid 서버)에서 황색 LED로 신호음이 울리기 시작하고 "저장소 풀 저하" 또는 **"볼륨 충돌"**을 보고하면 일반적으로 소유자가 바로 다음 클릭을 하면 대체할 수 없는 20테라바이트의 가족 사진 및 비즈니스 기록이 저장되거나 영구적으로 파기되는지 여부가 결정됩니다. 수십 년 동안 사용자들은 RAID 5 또는 RAID 1 어레이의 드라이브가 빨간색으로 변하면 죽은 드라이브를 빼내고 새 빈 드라이브를 밀어넣은 다음 **"복구/재구축"**을 클릭하면 된다고 배웠습니다.

동일한 제조 배치에서 구입한 8TB-24TB 드라이브로 구축된 최신 고용량 스토리지 풀에서 무작위로 전체 RAID 재구축을 시작하는 것은 복구 불가능한 전체 다중 드라이브 어레이 중단의 첫 번째 원인입니다. 4드라이브 16TB RAID 5 어레이를 재구축하면 남은 모든 노후화된 드라이브가 최대 열 및 기계적 부하에서 24-72시간 동안 논스톱으로 해당 섹터를 100% 읽게 됩니다. 남아 있는 형제 드라이브 중 하나에 수정 불가능한 읽기 오류(URE)가 발생하거나 재구축 도중에 헤드 성능 저하가 발생하면 RAID 컨트롤러는 해당 두 번째 드라이브를 풀에서 내보내고 전체 어레이를 충돌시킵니다. RAID, ZFS 또는 Btrfs 긴급 상황에서 살아남으려면 모든 쓰기를 즉시 일시 중지하고 S.M.A.R.T.를 감사해야 합니다. 남아 있는 모든 드라이브에 대한 원격 측정, 어레이 토폴로지를 건드리기 전에 중요 폴더 백업, GNU를 사용하여 성능이 저하된 구성원 디스크 이미징 ddrescue 패리티 재구축이나 읽기 전용 메타데이터 어셈블리를 시도하기 전에

지금 하세요¶

1. NAS 또는 서버의 전원이 켜져 있는 동안 여러 드라이브를 "재장착"하기 위해 꺼내지 말고, 정확한 슬롯 번호에 라벨을 붙이지 않고 드라이브를 교체하지 마십시오. 단일 드라이브 트레이를 만지기 전에 샤피나 라벨 메이커를 사용하여 모든 드라이브의 물리적 상단에 정확한 베이 번호(Bay 1 / sda, Bay 2 / sdb, Bay 3 / sdc). 최신 리눅스임에도 불구하고 mdadm, LVM 및 ZFS 어레이는 각 디스크에 UUID 슈퍼블록을 저장하고, 하드웨어 RAID 컨트롤러(Dell PERC, HP Smart Array, Broadcom/LSI MegaRAID)는 종종 구성 메타데이터를 물리적 SAS/SATA 백플레인 슬롯 번호에 바인딩합니다.
2. 최신 외부 백업이 없는 경우 성능이 저하된 RAID 5/SHR-1 배열에서 즉시 "복구" 또는 "재구축"을 클릭하지 마십시오. 단일 패리티 배열(RAID 5, Synology SHR-1 또는 ZFS RAIDZ1)이 성능 저하 모드(드라이브 1개가 작동하지 않고 나머지 드라이브는 온라인)에 있는 동안 지금은 모든 파일을 여전히 100% 읽을 수 있습니다. 외부 USB 3.0 하드 드라이브를 NAS에 직접 연결하고 가장 중요하고 교체할 수 없는 폴더를 저하된 풀에서 복사하세요. 그 전에 살아남은 드라이브에 패리티 재구축이라는 잔인한 48시간 스트레스 테스트를 실시하세요.
3. "디스크 초기화", "새 풀 생성", "구성 지우기"를 클릭하거나 실행하지 마십시오. fsck -y / btrfs check --repair 충돌한 어레이에서. 두 개의 드라이브가 RAID 5 어레이에서 동시에 중단되는 경우(종종 실제 물리적인 사망이 아닌 짧은 전원 공급 중단 또는 SATA 시간 초과로 인해) NAS GUI는 스토리지 풀을 **"충돌됨"**으로 표시하고 볼륨을 초기화하거나 다시 생성하도록 제안합니다. 초기화하면 패리티 스트라이프 전체에 새로운 슈퍼블록과 0이 기록되어 복구 가능한 데이터가 삭제됩니다. 마찬가지로, 실행 btrfs check --repair 손상된 Btrfs 볼륨에서 복구할 수 없을 정도로 익스텐트 트리를 파괴하는 것은 Linux 커널 커뮤니티에서 악명이 높습니다.
4. 모든 Docker 컨테이너, 가상 머신, Plex 미디어 서버, 감시 카메라 녹화 및 예약된 RAID 스크럽을 즉시 중지하십시오. 성능이 저하된 어레이에 대한 모든 쓰기 작업은 패리티 쓰기 구멍이 발생하거나 한계 두 번째 드라이브가 가장자리를 넘어갈 위험이 증가합니다. NAS 웹 인터페이스 또는 SSH 터미널에 로그인하고 모든 백그라운드 서비스 및 높은 I/O 작업을 중지합니다.
5. NAS의 드라이브에서 리드미컬한 딸깍 소리, 두드리는 소리, 갈리는 소리 또는 삐걱거리는 소리가 나면 지금 당장 NAS를 완전히 종료하십시오. 딸깍 소리나 갈리는 드라이브에 물리적 읽기/쓰기 헤드 충돌이 발생한 것입니다(참조: 하드 드라이브 오류 및 데이터 복구). NAS 인클로저 내부에서 회전시키면 몇 분 안에 자석 플래터가 먼지로 쌓입니다.
6. "NAS 오류"가 실제로 죽은 NAS 마더보드나 외부 전원 장치인지 확인하십시오. Synology, QNAP 또는 Asustor NAS의 전원이 갑자기 전혀 켜지지 않거나 파란색 전원 LED가 계속 깜박이는 경우(예: 유명한 Intel Atom C2000 시계 신호 버그) 하드 드라이브와 데이터는 거의 100% 정상입니다. 해당 드라이브를 교체용 NAS로 마이그레이션하거나 표준 SATA 포트를 사용하여 Ubuntu Linux 데스크탑 PC에 읽기 전용으로 마운트할 수 있습니다.

flowchart TD
    A["NAS 경고음 / RAID 어레이가 성능 저하 또는 충돌 상태를 보고함"] --> B{"기계적 딸깍 소리, 갈림 소리, 긁는 소리를 내는 드라이브가 있습니까?"}
    B -->|"예: 물리적인 머리 충돌"| C["즉시 NAS의 전원을 끄고 각 드라이브에 베이 번호 레이블을 붙인 다음 딸깍거리는 드라이브를 제거합니다."]
    B -->|"아니오: 자동 작동"| D{"스토리지 풀 상태는 어떻습니까?"}
    D -->|"성능 저하(드라이브 1개 실패, 볼륨을 계속 읽을 수 있음)"| E["모든 Docker/VM/감시 쓰기를 중지하고 아직 다시 빌드를 클릭하지 마세요."]
    E --> F["S.M.A.R.T를 확인하세요. 모든 SURVIVING 드라이브의 속성(ID 5, 187, 197, 198)"]
    F --> G["외부 USB 드라이브를 연결하고 저하된 풀에서 중요한 파일을 먼저 복사하세요."]
    G --> H{"남아 있는 드라이브에 불량 섹터(ID 5/197 > 0)가 표시됩니까?"}
    H -->|"예: 두 번째 드라이브에 오류가 발생했습니다."| I["재구축을 시도하기 전에 GNU ddrescue로 모든 드라이브의 전원을 끄고 복제하십시오."]
    H -->|"아니요: 살아남은 드라이브는 100% 정상입니다."| J["교체용 CMR 드라이브(SMR 아님) 삽입 및 패리티 재구축 실행"]
    D -->|"CRASHED / OFFLINE(여러 드라이브가 중단됨)"| K["fsck/btrfs --repair를 초기화하거나 실행하지 마십시오. 전원을 끄고 모든 드라이브 베이에 라벨을 붙입니다."]
    C --> L["GNU ddrescue + mapfiles를 사용하여 성능이 저하된 모든 구성원 드라이브를 정상 드라이브로 복제합니다."]
    K --> L
    L --> M["Linux mdadm/LVM, zpool import -o readonly=on 또는 UFS Explorer RAID를 통해 읽기 전용 모드에서 복제된 드라이브를 재조립합니다."]

RAID 재구축이 실패하는 이유 이해: "Sibling Drive Batch" 및 "SMR Drive" 트랩¶

NAS 긴급 상황에서 안전한 결정을 내리려면 복구 중에 RAID 어레이를 죽이는 두 가지 물리적 함정을 이해해야 합니다.

트랩 1: 상관된 배치 실패 및 수정 불가능한 읽기 오류(URE)¶

대부분의 NAS 소유자는 같은 소매점에서 같은 날 4-6개의 하드 드라이브를 모두 구입합니다. 이러한 드라이브는 동일한 공장 조립 라인에서 생산되고, 동일한 펌웨어 개정판을 공유하며, 동일한 섀시 진동 환경에서 회전하며, 동일한 전원 켜짐 시간을 누적합니다. * 드라이브 1이 38,000시간 작동 후 수명이 다하면 드라이브 2, 3, 4도 38,000시간 동안 마모됩니다. * 새 교체 드라이브를 베이 1에 넣고 RAID 5 어레이에서 재구축을 클릭하면 NAS 컨트롤러는 드라이브 2, 3, 4의 모든 단일 섹터를 읽어서 베이 1에 대해 누락된 패리티 블록을 XOR 계산해야 합니다. * 드라이브 3이 2년 동안 열지 않은 이전 폴더에 읽을 수 없는 14개의 불량 섹터(현재 보류 중인 섹터, S.M.A.R.T. ID 197)를 조용히 숨기고 있는 경우 재구축 프로세스는 19시간에 해당 불량 섹터를 먼저 처리합니다. 많은 하드웨어 RAID 카드와 SCT 오류 복구 제어(TLER)가 없는 이전 NAS 커널에서 단 몇 초의 읽기 지연으로 인해 컨트롤러는 드라이브 3을 다음으로 표시합니다. "실패/오류" 단일 패리티 RAID 5 어레이에서 두 번째 드라이브를 삭제하고 전체 볼륨을 충돌시킵니다.

함정 2: SMR(Shingled Magnetic Recording) 드라이브를 RAID 또는 ZFS 어레이에 삽입하지 마십시오.¶

NAS를 재구축하기 위해 지역 전자제품 매장에서 긴급 교체용 하드 드라이브를 구입할 때 교체 드라이브가 CMR(기존 자기 녹음)을 사용하는지 확인하고 SMR(Singled Magnetic Recording)은 사용하지 마세요. * 저가 데스크탑 하드 드라이브(예: 표준 Western Digital Red 비플러스) EFAX 2TB에서 6TB까지의 모델, Seagate Barracuda Compute 데스크탑 드라이브 및 사용자가 플라스틱 케이스에서 "꺼내는" 많은 저렴한 외부 USB 드라이브)는 자기 트랙이 지붕 널처럼 겹치는 드라이브 관리형 SMR을 사용합니다. * 지속적인 멀티테라바이트 RAID 또는 ZFS 리실버 쓰기 중에 SMR 드라이브의 내부 미디어 캐시는 30분 이내에 완전히 채워집니다. 캐시가 가득 차면 SMR 드라이브는 전체 슁글드 밴드를 내부적으로 읽고 다시 쓰는 동안 10-30초 이상 동안 정지하거나 ATA를 반환합니다. IDNF (Sector ID Not Found) 시간 초과. * 리눅스 mdadm, Synology DSM, 특히 ZFS(zed) 20초 동안 SMR이 정지되는 것을 죽은 하드 드라이브로 해석하여 재구축 중에 새 교체 드라이브를 어레이에서 바로 쫓아냅니다. 항상 CMR NAS/Enterprise 드라이브(예: WD Red Plus / WD Red Pro, Seagate IronWolf / IronWolf Pro / Exos 또는 Toshiba N300 / MG Enterprise)를 구입하세요.

진단 매트릭스: RAID 수준, 내결함성 및 생존 규칙¶

"성능이 저하된" NAS 풀에 대한 단계별 분류(드라이브 1개 실패, 데이터는 계속 액세스 가능)¶

RAID 1, RAID 5, SHR-1, RAID 6 또는 RAIDZ 풀의 1 드라이브에 오류가 발생하여 NAS에서 신호음이 울리는 경우 디스크를 교체하기 전에 다음 순서를 정확히 따르십시오.

1단계: S.M.A.R.T. 감사 모든 SURVIVING 드라이브의 속성을 먼저¶

저장소 관리자 -> HDD/SSD -> 상태 정보 -> S.M.A.R.T.를 엽니다. 속성(Synology/QNAP에서) 또는 실행 smartctl -a /dev/sdX 풀에 아직 남아 있는 모든 정상/온라인 드라이브에서 SSH를 통해. 를 보세요RAW_VALUE 다음 네 가지 중요한 속성에 대한 열: * ID 5(Reallocated_Sector_Ct): 이상적으로는 0. 살아남은 드라이브에 수십 또는 수백 개의 재할당된 섹터가 있는 경우 플래터 표면이나 헤드가 활발히 저하되고 있습니다. * ID 187(Reported_Uncorrect): 다음과 같아야 합니다. 0. * ID 197(Current_Pending_Sector): 위험. 다음보다 큰 숫자 0 이는 RAID 재구축이 해당 드라이브를 읽으려고 시도하는 순간 현재 드라이브에 충돌을 일으키기 위해 대기 중인 읽을 수 없는 섹터가 있음을 의미합니다. * ID 198(Offline_Uncorrectable): 다음과 같아야 합니다. 0.

결정 규칙: * 살아남은 모든 드라이브에 가 표시되는 경우0 ID 5, 187, 197 및 198에서는 중요한 폴더를 외부 USB 드라이브에 안전하게 백업한 다음 정상적인 CMR 교체 드라이브를 사용하여 일반 NAS GUI 복구/재구축을 진행할 수 있습니다. * 단일 패리티 RAID 5/SHR-1/RAIDZ1 풀에서 모든 살아남은 드라이브에 가 표시되는 경우Current_Pending_Sector > 0 또는 에스컬레이션 Reallocated_Sector_Ct, 재구축을 실행하지 마세요. 볼륨이 마운트되어 있는 동안 성능이 저하된 NAS의 모든 데이터를 즉시 외부 USB 드라이브에 복사합니다. 볼륨이 이미 문제가 있는 경우 NAS 전원을 끄고 GNU를 사용하여 Linux PC에서 실패한 구성원 드라이브를 복제합니다. ddrescue 먼저.

RAID/NAS 볼륨 "충돌" 시 단계별 복구(여러 드라이브가 중단됨)¶

화요일 밤에 드라이브 2에 오류가 발생하고 수요일 아침에 드라이브 4가 중단되었기 때문에 일어났는데 4베이 RAID 5 NAS에 **"스토리지 풀 1: 충돌이 발생했습니다"**라고 표시되면 어떻게 됩니까?

대부분의 "2-드라이브 오류"가 실제로 복구 가능한 이유: 집이 번개에 맞거나 NAS가 계단 아래로 떨어지지 않는 한, 두 개의 기계식 하드 드라이브는 정확히 같은 순간에 치명적인 헤드 충돌을 거의 겪지 않습니다. 대신 실제로 일어난 일은 순차적입니다. 1. 드라이브 2에서는 몇 개의 불량 섹터가 발생하여 며칠 또는 몇 시간 전에 어레이에서 쫓겨났습니다(어레이는 드라이브 1, 3, 4에서 성능 저하 모드로 실행 상태로 유지). 2. 나중에 NAS가 백그라운드 스크럽을 실행하는 동안 드라이브 4에서 읽을 수 없는 단일 섹터 하나*(또는 짧은 SATA 시간 초과)가 발생했습니다. 어레이에는 더 이상 드라이브 4의 단일 불량 섹터를 수정할 수 있는 중복성이 없기 때문에 RAID 드라이버는 드라이브 4도 제거하고 전체 풀을 Crashed로 표시했습니다.

이 시나리오에서 드라이브 4에는 가장 최신의 최신 레이드 이벤트 카운터(Events 개수)이며 99.9999% 정상인 반면, 드라이브 2는 약간 오래되었습니다("오래됨").

충돌한 Synology, QNAP 또는 Linux를 복구하는 방법 mdadm Linux PC에서 안전하게 배열¶

1단계: NAS 전원을 끄고 모든 드라이브 베이에 라벨을 붙인 다음 Ubuntu Linux Live USB를 실행하는 데스크탑 PC에 드라이브를 연결합니다.¶

1. NAS를 종료합니다. 각 드라이브에 레이블을 지정합니다(Bay 1, Bay 2, Bay 3, Bay 4).
2. Ubuntu Linux Live USB로 부팅된 데스크탑 PC의 마더보드 SATA 포트(또는 IT 모드에서 LSI 9211-8i/9300-8i와 같은 HBA 카드. 로드 시 연결이 끊어지는 값싼 USB 허브는 피함)에 드라이브를 연결합니다.
3. 터미널을 열고 파티션 레이아웃을 검사하고 mdadm 슈퍼블록 엄격히 읽기 전용 진단 모드:

# List all connected drives and partitions without mounting anything
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE

# Inspect the Linux Software RAID (mdadm) superblock metadata on the data partitions
# Note: On Synology DSM, Partition 1 is Root OS, Partition 2 is Swap, and Partition 3 (or 5) is your User Data array (e.g., /dev/sda3, /dev/sdb3, /dev/sdc3, /dev/sdd3)
sudo mdadm --examine /dev/sd[a-d]3

2단계: 읽기 Events 카운터와 Array State 출력 mdadm --examine¶

출력을 자세히 살펴보십시오. sudo mdadm --examine /dev/sd[a-d]3 각 드라이브에 대해: * 다음과 같은 줄이 표시됩니다. * /dev/sda3: Events : 48210, Array State : A.AA (A = 활성, . = 누락) * /dev/sdb3 (드라이브 2, 먼저 중단됨): Events : 47950, Array State : AAAA * /dev/sdc3: Events : 48210, Array State : A.AA * /dev/sdd3 (드라이브 4, 마지막으로 삭제됨): Events : 48209, Array State : A.AA * 무엇인지 주목하세요 Events 카운터는 다음을 알려줍니다. 드라이브 1, 3, 4(sda3, sdc3, sdd3)는 서로 1개의 이벤트 내에 있습니다(48210 대 48209), 드라이브 2(sdb3) 이벤트에서 훨씬 일찍 떨어졌습니다 47950. * 중요 규칙: 4드라이브 RAID 5 어레이에서는 데이터를 100% 재구성하는 데 3개 드라이브만 필요합니다. 3개의 최신 드라이브를 사용하여 어레이를 조립해야 합니다(sda3, sdc3, 그리고 sdd3) 및 오래된 드라이브를 그대로 둡니다(sdb3). 오래된 드라이브를 사용하여 실수로 강제 조립한 경우(sdb3), 이틀 전의 파일 시스템 메타데이터가 다른 드라이브의 현재 데이터 스트라이프와 일치하지 않아 폴더가 손상됩니다.

3단계: GNU를 사용하여 불량 섹터가 있는 드라이브 복제 ddrescue 먼저¶

조립하기 전에 최근에 떨어뜨린 드라이브(/dev/sdd)(이상적으로는 모든 구성원 드라이브)을 다음을 사용하여 정상적인 교체 드라이브로 교체합니다. ddrescue (참조 하드 드라이브 오류 및 데이터 복구 완전한 ddrescue 구문):

# Clone the dropped drive (/dev/sdd) to a healthy new spare drive (/dev/sde) with a mapfile
sudo ddrescue -f -n /dev/sdd /dev/sde /root/drive4_clone.map
sudo ddrescue -d -f -r3 /dev/sdd /dev/sde /root/drive4_clone.map

이제 원래 실패의 플러그를 뽑으세요. /dev/sdd 건강한 클론과 함께 작업할 수 있도록 선반에 안전하게 보관하세요(/dev/sde).

4단계: 엄격한 읽기 전용 모드에서 RAID 어레이, LVM 볼륨 그룹 및 파일 시스템을 재조립합니다.¶

Synology(SHR/RAID) 및 QNAP 시스템에서 저장소 스택에는 최대 3개의 레이어가 있습니다: mdadm (레이드) -> LVM2 (논리 볼륨 관리자) -> ext4 또는 Btrfs (파일 시스템). Ubuntu에서 읽기 전용 모드로 안전하게 마운트하는 정확한 명령 순서는 다음과 같습니다.

# Install mdadm, lvm2, and btrfs-progs inside the Ubuntu Live environment
sudo apt update && sudo apt install -y mdadm lvm2 btrfs-progs

# Stop any partial auto-assembled md arrays first
sudo mdadm --stop --scan

# Assemble the 3 freshest RAID 5 partitions in READ-ONLY mode (using --force ONLY if the 3rd drive's event count is off by 1-2 events, on the cloned drive)
sudo mdadm --assemble --readonly --run /dev/md127 /dev/sda3 /dev/sdc3 /dev/sde3

# Check that /dev/md127 is now active (even in degraded [UU_U] read-only state)
cat /proc/mdstat

# Activate the LVM Volume Group in read-only mode
sudo vgchange -ay --readonly

# List the discovered Logical Volumes (look for /dev/vg1000/lv or /dev/vg1/volume_1)
sudo lvs

# Create a mount point and mount the Logical Volume strictly READ-ONLY (-o ro,noload for ext4 or -o ro,norecovery for Btrfs)
sudo mkdir -p /mnt/nas_rescue

# For ext4 volumes:
sudo mount -o ro,noload /dev/vg1000/lv /mnt/nas_rescue

# OR for Btrfs volumes (such as Synology Btrfs pools):
sudo mount -o ro,norecovery /dev/vg1000/lv /mnt/nas_rescue

한 번 /mnt/nas_rescue 마운트하면 모든 NAS 공유 폴더(photo, homes, video, documents) 내부에 나타납니다 /mnt/nas_rescue/ 외부 USB 백업 드라이브에 바로 복사할 수 있습니다.

• Synology NAS에 드라이브 크기가 혼합된 "Synology Hybrid RAID(SHR)"가 있으면 어떻게 됩니까? Synology SHR은 단순히 더 큰 드라이브를 여러 파티션으로 분할합니다(sda5, sda6) 별도의 파일을 생성합니다. mdadm 각 파티션 계층에 걸쳐 배열한 다음 이를 조인합니다. md 단일 LVM 볼륨 그룹(vg1000). 달리기 sudo mdadm --assemble --scan --readonly 그리고 sudo vgchange -ay Ubuntu에서 다중 계층 SHR 볼륨을 자동으로 다시 연결합니다.
• 상용 GUI 대안(Windows/macOS/Linux): Linux 터미널 명령이 불편하거나 복잡한 QNAP 씬 프로비저닝된 LVM 풀이 있는 경우, UFS Explorer RAID Recovery 또는 ReclaiMe Free RAID Recovery는 100% 읽기 전용 소프트웨어 모드에서 Windows 또는 Linux PC에 연결된 모든 NAS 드라이브를 검사하고 스트라이프 크기, 패리티 회전 및 LVM 오프셋을 자동으로 감지하고 NAS의 단일 섹터를 수정하지 않고 폴더를 복사할 수 있습니다. 드라이브.

ZFS(zpool) 및 Btrfs 긴급 구조 명령¶

최신 NAS 플랫폼(TrueNAS SCALE/CORE, Proxmox, Ubuntu Server, Unraid 및 Synology Btrfs 볼륨)에서는 레거시 대신 CoW(기록 중 복사) 파일 시스템을 점점 더 많이 사용하고 있습니다. ext4. ZFS인 경우 zpool 또는 Btrfs 풀은 마운트를 거부하거나 정전 또는 드라이브 오류 후 부팅 시 커널 패닉을 유발합니다. OS가 손상된 쓰기 트랜잭션을 재생하려고 시도하기 때문에 정상적인 마운트가 실패합니다. 읽기 전용 트랜잭션 롤백 매개변수를 사용해야 합니다.

1. ZFS(zpool) 응급 복구(TrueNAS/Proxmox/Linux ZFS)¶

ZFS 풀에 다음과 같은 내용이 있는 경우 FAULTED, UNAVAIL, 또는 비정상적인 전원 손실 후 서버를 가져오려고 하는 순간 서버가 충돌(커널 패닉)합니다.

# 1. Inspect all visible ZFS pools on the connected disks without importing them
sudo zpool import

# 2. ALWAYS attempt a Read-Only Import first (prevents ZFS from writing to disks or replaying the ZIL/SLOG)
sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue <pool_name>

# 3. What if a normal import causes a kernel panic or says 'damaged pool metadata'?
# Use -F (Rollback/Recovery Mode) with -n (Dry Run ONLY) to see if ZFS can rewind the last few seconds of corrupted Transaction Groups (TXGs):
sudo zpool import -F -n <pool_name>

# 4. Combine Read-Only + Safe Transaction Group Rewind (-F -o readonly=on) so no disk sectors are altered while you copy your data off:
sudo zpool import -f -F -o readonly=on -R /mnt/zfs_rescue <pool_name>

# 5. For heavily damaged pools where Space Map allocation tables are corrupt, disable space map loading prior to read-only import:
echo 1 | sudo tee /sys/module/zfs/parameters/zfs_recover
sudo zpool import -f -F -o readonly=on -R /mnt/zfs_rescue <pool_name>

일단 아래에 장착 /mnt/zfs_rescue, 다음을 사용하여 데이터세트를 복사하세요. rsync 또는 zfs send 풀 읽기-쓰기 가져오기를 시도하기 전에.

2. Btrfs 응급 복구(Synology Btrfs / Unraid 캐시 풀 / Linux Btrfs)¶

대신, 최소 침습적 스캔부터 가장 깊은 스캔까지 엄격한 점진적 순서로 Btrfs 볼륨을 마운트하거나 추출해 보십시오.

# Stage 1: Mount Read-Only without replaying the corrupted Journal Log Tree (fixes 80% of power-loss Btrfs mount failures)
sudo mount -t btrfs -o ro,norecovery /dev/sdX1 /mnt/btrfs_rescue
# (Note: on newer Linux kernels 5.11+, use: -o ro,rescue=nologreplay)

# Stage 2: Mount Read-Only using the backup Root Tree + ignoring bad checksums (for multi-drive or bit-rot corruption)
sudo mount -t btrfs -o ro,rescue=all /dev/sdX1 /mnt/btrfs_rescue
# (On older kernels: sudo mount -t btrfs -o ro,usebackuproot,nologreplay,degraded /dev/sdX1 /mnt/btrfs_rescue)

# Stage 3: If the volume still refuses to mount in the kernel, extract files directly in userspace without mounting using 'btrfs restore'
# First, list available backup tree roots:
sudo btrfs-find-root /dev/sdX1

# Then run 'btrfs restore' (strictly read-only userspace extractor) to dump all files to an external healthy drive:
sudo btrfs restore -v -i -m -S /dev/sdX1 /mnt/external_usb_backup/

하드웨어 RAID 컨트롤러 긴급 상황: "외부 구성" 및 죽은 RAID 카드¶

엔터프라이즈 서버(PERC 카드가 포함된 Dell PowerEdge, Smart Array가 포함된 HPE ProLiant, Lenovo ThinkSystem 또는 Broadcom/LSI MegaRAID 컨트롤러가 포함된 워크스테이션)는 온보드 NVRAM 및 배터리/슈퍼커패시터 캐시(BBU / CacheVault).

1. 외부 구성 가져오기와 구성 지우기(CRITICAL)¶

드라이브의 연결이 일시적으로 끊어지거나 드라이브를 교체 서버 섀시로 옮기면 Dell PERC 또는 LSI MegaRAID BIOS 부팅 화면이 일시 중지되고 다음 메시지가 표시됩니다. "어댑터에서 외부 구성이 발견되었습니다." * 항상 선택하세요 Import Foreign Configuration (또는 Preview Foreign Configuration -> Import). "외부" 태그는 단순히 RAID 컨트롤러가 카드의 현재 NVRAM 상태와 다른 하드 드라이브 자체(드라이브 끝에 있는 디스크 데이터 형식/DDF 또는 LSI 구성 섹터)에 기록된 유효한 기존 RAID 메타데이터를 본다는 것을 의미합니다. 가져오기는 드라이브에서 바로 어레이 레이아웃을 읽고 단일 바이트 손실 없이 가상 디스크를 다시 온라인으로 가져옵니다. * 선택하지 마세요 Clear Foreign Configuration 또는 Initialize Virtual Disk. 지우거나 초기화하면 어레이 메타데이터가 지워지거나 드라이브가 0이 됩니다. * 예외 경고: 3주 전에 단일 드라이브가 중단되어 3주 동안 성능이 저하된 어레이에 새 데이터를 계속 쓴 다음 3주 동안 오래된 단일 드라이브를 다시 연결한 경우 오래된 단일 드라이브에서 외부 구성을 건강한 활성 드라이브 위로 가져오지 마십시오. 대신 오래된 드라이브를 교체하거나 복제하십시오.

2. 하드웨어 RAID 카드 자체가 죽으면 어떻게 되나요?¶

서버 마더보드 또는 PCIe 하드웨어 RAID 컨트롤러 카드에 전자 오류가 발생하여 부팅되지 않는 경우: * 정확히 동일한 버전의 마더보드를 구입할 필요는 없으며 데이터는 드라이브에 그대로 남아 있습니다. * 동일한 컨트롤러 칩셋 제품군에서 교체용 RAID 컨트롤러를 구입합니다. 예를 들어 모든 LSI/Broadcom MegaRAID SAS 2108/2208/3108 또는 Dell PERC H710/H730/H740 카드는 이전 PERC 카드에서 DDF 메타데이터를 읽을 수 있습니다. * 작동하는 PC에 교체용 RAID 카드를 설치하고, 레이블이 붙은 드라이브를 원래 베이 순서대로 연결하고, 컨트롤러 BIOS로 부팅합니다(Ctrl+R 또는 Ctrl+H 또는 UEFI HII 메뉴) 외부 구성 가져오기를 선택합니다. 컨트롤러는 드라이브에서 RAID 레이아웃을 읽고 볼륨을 즉시 마운트합니다.

자주 묻는 질문¶

관련 가이드¶

• 하드 드라이브 오류 및 데이터 복구
• 실수로 파일 삭제, 포맷된 드라이브 및 사진 복구
• 컴퓨터 백업: 3-2-1 전략 및 재해 복구
• Linux 시스템 부팅 실패 및 GRUB 복구
• 랜섬웨어 및 악성코드 비상대응
• 글로벌 긴급 전화번호

확인된 소스¶

• Linux 커널 조직(국제): Linux RAID(mdadm) 위키(raid.wiki.kernel.org), 실패한 소프트웨어 RAID 복구 및 Btrfs 커널 문서(btrfs.readthedocs.io 에 btrfs rescue 그리고 btrfs restore).
• OpenZFS 문서화 프로젝트(국제): zpool import 읽기 전용 및 트랜잭션 그룹 롤백(-F -o readonly=on) 관리 참조.
• Synology Inc.(대만/국제): 공식 Synology 기술 자료 문서 KB-1079 (Ubuntu를 사용하여 Synology NAS가 오작동하는 경우 PC를 사용하여 데이터를 복구하려면 어떻게 해야 합니까? mdadm 그리고 lvm2).
• GNU 프로젝트 / 자유 소프트웨어 재단(국제): GNU ddrescue 성능이 저하된 RAID 구성원 드라이브의 비파괴 블록 수준 이미징 매뉴얼.
• NIST(National Institute of Standards and Technology)(미국): 특별 간행물 800-86 및 RAID 재구성 노출 창 및 수정 불가능한 읽기 오류(URE) 확률에 대한 스토리지 신뢰성 지침.