RAID 5, RAID 6, utawa ZFS Multiple Drive Drop: Mbalekake Synology Crashed, QNAP, utawa TrueNAS Array Tanpa Ngrusak Paritas¶

Krungu Synology DiskStation, QNAP TS-series, server TrueNAS, utawa Linux mdadm bip server panyimpenan terus-terusan nalika nglaporake ** Volume Crashed **, ** Pool Degraded / Faulted **, utawa ** Multiple Drives Disconnected ** minangka darurat panyimpenan dhuwur. Nalika drive siji irungnya metu saka a RAID 5, Synology Hybrid RAID (SHR-1), utawa ZFS RAIDZ1 pool, array mlaku kanthi nol redundansi (degraded negara), mbangun maneh blok sing ilang kanthi cepet kanthi maca saben disk sing isih ana ing podo karo. Yen drive kaping pindho mudhun offline sawetara jam mengko, utawa mbuwang Kesalahan Waca sing Ora Bisa Dipulihake (URE) separo liwat mbangun menyang disk panggantos, math paritas rusak lan blumbang panyimpenan dadi offline rampung. Administrator panik asring ngrusak terabyte data sing bisa dibalekake sajrone sewidak detik sabanjure kanthi ngeklik Initialize, nggawe maneh array nganggo mdadm --create, utawa meksa mbangun maneh online langsung menyang hardware sing gagal. Yen kertu hardware RAID controller dhewe mati tinimbang disk, ngalih menyang RAID kertu controller mati, ngimpor konfigurasi manca, lan apa sampeyan kudu tau initialize disk; yen hard drive individu ngeklik utawa nolak kanggo muter munggah, takon Gagal hard drive lan Recovery data utawa Array NAS RAID rusak, sawetara drive gagal, lan pemulihan ZFS/Btrfs. Yen gagal panyimpenan iki mateni pencitraan medis rumah sakit (PACS), kiriman darurat, utawa infrastruktur kaslametan urip, hubungi nomer darurat lokal sampeyan (911 ing Amerika Serikat lan Kanada, 112 liwat Uni Eropa, 999 ing Inggris) utawa priksa direktori kita nomer darurat.

Apa iki saiki¶

1. ** STOP lan AJA klik "Initialize," "Gawe Pool," "Repair," utawa mbukak mdadm --create ing drive dropped**: Ngeklik Initialize ing Synology DSM utawa QNAP QTS, utawa mlaku mdadm --create ing Linux, nyerat superblocks account-anyar lan wiwit zeroing loreng paritas tengen kabeh disk anggota. A drive dropped biasane isih terus 99.99% file sampeyan utuh, mung ditandhani ora sinkron dening counter acara.
2. **Mateni NAS utawa server kanthi resik (utawa narik daya yen aktif mbangun maneh liwat ngeklik drive) kanggo beku counter acara **: Saben detik array tetep online ing negara sing sebagian rusak, sistem operasi nambah superblok Update Time lan Events counter ing disk urip nalika disk dropped tetep beku ing nomer acara lawas. Yen NAS nyoba mbangun maneh kanthi otomatis ing drive kanthi sektor ala, terus maca drive kasebut bisa ngilangi lapisan platter magnetik (head crash).
3. ** Label saben slot drive bay nganggo marker fisik utawa tape (Bay 1, Bay 2, Bay 3, Bay 4) sadurunge ngusapake sembarang tray metu**: Nalika Linux mdadm, LVM2, lan ZFS trek supaya drive dening UUID nang saben superblock pemisahan, pengontrol hardware lawas lan manual dmsetup rekonstruksi meja mbutuhake urutan slot fisik sing tepat (0, 1, 2, 3...).
4. ** Aja nyoba Recovery, pasukan-ngrakit, utawa fsck langsung ing drive anggota asli; kloning saben drive bit-kanggo-dicokot nggunakake ddrescue dhisik**: Sadurunge mlaku mdadm --assemble --force utawa zpool import -F, masang saben disk anggota menyang workstation Linux liwat SATA / SAS langsung (ora tau jembatan USB murah sing ndhelikake SMART utawa SCT ERC wektu entek) lan kloning karo ddrescue menyang drive cadangan sehat utawa file gambar.
5. Maksa-ngumpulake susunan kloning kanthi ketat ing mode READ-ONLY (--readonly utawa -o readonly=on): Nalika ngrakit mdadm susunan sing counters acara drifted loro sak gulung multi-drive simultaneous, tansah pass --readonly (mdadm --assemble --force --readonly /dev/md0 ...). Ing mode maca-mung, ora mdadm, LVM2, ext4, Btrfs, utawa ZFS bisa nimpa garis paritas utawa muter maneh jurnal sing ngrusak.
6. Salin data sing paling kritis menyang drive serep eksternal sing independen sawise dipasang mung maca: Evakuasi dokumen, basis data, mesin virtual, lan foto menyang drive sing kapisah dhisik, banjur usap lan tes disk saka awal.

Wit kaputusan: multi-drive RAID lan ZFS pool darurat triage¶

Gunakake diagram alur iki kanggo nemtokake manawa larik sampeyan ngalami penurunan wektu entek logis (TLER / ERC mismatch), kegagalan multi-disk bad-sector sejati nalika mbangun maneh, utawa grup transaksi ZFS (TXG) kesalahan:

flowchart TD
    Start["RAID 5 / RAID 6 / SHR / ZFS Pool Crashed Sawise 2+ Drive Drop"] --> StopIO["STOP Kabeh Rebuilds & Power Down NAS Langsung"]
    StopIO --> Label["Label Saben Baki Drive miturut Nomer Bay (Bay 1 nganti Bay N)"]
    Label --> ConnectLinux["Sambungake Drive Anggota menyang Host Rescue Linux Ubuntu liwat Direct SATA / HBA"]

    ConnectLinux --> CheckSmart["Priksa SMART & Metadata Mung Waca: smartctl -a / mdadm --examine / zdb -l"]
    CheckSmart --> PhysicalHealth{"Apa Drive Ngeklik, Nolak Spin, utawa Muter Offline ing dmesg?"}

    PhysicalHealth -->|"Ya: Gagal Mekanik / Kepala ing 2+ Drive ing RAID 5"| Cleanroom["STOP Powering Disks -> Kirim menyang Cleanroom Data Recovery Lab"]
    PhysicalHealth -->|"Ora: Kabeh Drive Muter (Muga-muga Sektor Buruk sing Ditundha utawa Tetes Wektu)"| CloneAll["Kloning Saben Anggota Drive Nggunakake GNU ddrescue (Maju Pass -> Reverse Scrape)"]

    CloneAll --> DisconnectOrig["Pedhot Sambungan Drive Asli & Bisa Digunakake ing Disk Kloning / Gambar"]
    DisconnectOrig --> ArrayType{"Arsitektur Panyimpen sing Digunakake?"}

    ArrayType -->|"Synology DSM (SHR / Classic RAID)"| SynologyFlow["Priksa Acara liwat mdadm --examine -> Force-Assemble Read-Only -> Aktifake LVM2 / Btrfs Read-Only"]
    ArrayType -->|"QNAP QTS (HAL LVM Thin / Thick RAID)"| QnapFlow["Pasang mdadm Mung Waca -> Aktifake Lapisan DRBD yen Ana -> Pindai Superblok QNAP LVM2 Kustom"]
    ArrayType -->|"TrueNAS / ZFS (RAIDZ1 / RAIDZ2 / Mirror)"| ZfsFlow["Jalanake zpool import -d /dev/disk/by-id -> Import Read-Only karo Rollback: zpool import -f -o readonly=on -F"]
    ArrayType -->|"Standar Linux mdadm"| LinuxFlow["Bandingake Penghitung Acara -> Run mdadm --assemble --force --readonly -> Mount Filesystem with -o ro,noload"]

Fase 1: Napa meksa mbangun maneh ngrusak data (URE lan Same-Batch Cascade)¶

Kanggo ngerti sebabe ngeklik ** Repair / Rebuild ** utawa ngganti siji drive lan ngenteni 36 jam asring nyebabake kacilakan array total, sampeyan kudu ngerti carane rekonstruksi paritas nandheske media magnetik sing tuwa lan kenapa drive desktop konsumen metu saka enclosure NAS.

1. Kasunyatan matématika saka Kasalahan Waca sing Ora Bisa Dipulihake (UREs) sajrone RAID 5 utawa RAIDZ1 mbangun maneh¶

Ing 4-drive RAID 5 utawa ZFS RAIDZ1 blumbang, data lan pamblokiran paritas (P) digarisake ing kabeh papat disk nggunakake Eksklusif OR (XOR) pitungan (D1 XOR D2 XOR D3 = P). Yen Drive 2 mati rampung, larik ora duwe redundansi sing isih ana. Kanggo mbangun maneh Drive 2 menyang disk panggantos sing anyar, NAS kudu maca saben sektor saka byte 0 nganti pungkasan disk ing Drive 1, Drive 3, lan Drive 4 bebarengan (Reconstructed D2 = D1 XOR D3 XOR P).

Coba apa sing kedadeyan nalika drive kasebut ana papat hard drive 12 terabyte (12.000 gigabyte) sing dituku saka kumpulan manufaktur sing padha patang taun kepungkur: - Mbangun maneh 12 terabyte mbutuhake maca 36 terabytes (2.88 x 1014 bit individu) terus liwat 24 kanggo 48 jam ing maksimum mbukak termal lan mechanical. - Hard drive konsumen biasane nggawa Kesalahan Waca sing Ora Bisa Dipulihake (URE) spesifikasi 1 error in 1014 bits (12.5 terabytes), lan drive tuwa ngembangake kesalahan sektor laten bisu (Current_Pending_Sector) ing wilayah kadhemen saka disk sing wis ora diwaca ing taun. - Wayahe Drive 3 tekan siji sing ora bisa diwaca 4 kilobyte (0.004 megabyte) bad sector nalika Drive 2 isih ilang utawa setengah dibangun maneh, XOR persamaan nduweni loro sing ora dingerteni (D2 lan D3).

2. Apa drive desktop tanpa TLER / SCT ERC njaluk kicked metu tanggung liwat 1 bad sector¶

Mangkene jebakan sing nyebabake multi-drive catastrophic ing Synology, QNAP, lan Linux mdadm:

+-------------------------------------------------------------------------+
| WHY A SINGLE BAD SECTOR DROPS AN ENTIRE DRIVE DURING REBUILD            |
|                                                                         |
| 1. Drive 2 is dead/rebuilding. NAS reads Sector 849,102,400 on Drive 3. |
| 2. Drive 3 hits a weak magnetic spot (Current_Pending_Sector).          |
| 3. Consumer Drive Behavior (No TLER / SCT ERC):                         |
|    - Drive 3 enters deep internal error recovery for 30 to 120 seconds, |
|      stopping all SATA responses while retrying head positioning.       |
| 4. Linux Kernel / NAS Controller Timeout (Default 7 to 30 seconds):     |
|    - Kernel sees Drive 3 unresponsive for >30s -> Issues SATA bus reset |
|    - mdadm assumes Drive 3 is COMPLETELY DEAD and kicks it from array   |
| 5. RESULT: Both Drive 2 and Drive 3 are now marked FAULTY/REMOVED.      |
|    The entire RAID 5 array crashes offline immediately.                 |
+-------------------------------------------------------------------------+

Wigati apa sing kedadeyan: Drive 3 ora mati. Wis 99.999999% sektor sehat lan mung 1 utawa 2 sektor 4 kilobyte sing ora bisa diwaca (8 kilobytes metu saka 12 terabytes). Nanging amarga mdadm kicked Drive 3 metu saka Uploaded amarga wektu entek printah 30 detik, kabeh volume nuduhake minangka ** Crashed **. Yen sampeyan clone Drive 3 karo ddrescue (sing gracefully skip 8 kilobyte bad sector lan nyalin 12 terabyte liyane) lan meksa-ngumpul array mung diwaca, sampeyan mbalekake sakbenere 100 persen saka file.

3. Apa sampeyan kudu NATE mlayu mdadm --create utawa klik "Initialize"¶

Nalika array nabrak, rong mitos ngrusak nyebar online: - ** Mitos 1: "Nggawe maneh array kanthi urutan drive sing padha nggunakake mdadm --create."** Malah karo --assume-clean, versi modern saka mdadm standar kanggo beda Data Offset nilai gumantung ing kernel lan mdadm ngeculake (2048 sectors vs 262144 sectors). kapan mdadm --create nyerat versi anyar 1.2 superblock ing offset salah utawa karo ukuran cuwilan mismatched, nimpa ing LVM2 header volume fisik utawa ext4 superblock ing ngarep volume. - Mitos 2: "Copot drive kapindho sing lagi wae ilang, pasang maneh, banjur klik Repair." Yen Drive 1 mudhun telung dina kepungkur (dadi datane 3 dina basi) lan Drive 3 mudhun 10 menit kepungkur (dadi data saiki), narik lan nglebokake drive sing salah utawa meksa mbangun maneh karo Drive 1 ditandhani "aktif" lan Drive 3 ditandhani "spare" kanggo nulis ulang NAS nganti -dina anyar. garis paritas, ngrusak saben direktori lan file sing diowahi sajrone 72 jam pungkasan.

Phase 2: Inspecting superblocks lan Event counters aman ing host ngluwari Linux¶

Kanggo ngluwari larik Synology, QNAP, TrueNAS, utawa Linux sing kacilakan kanthi aman, copot kabeh drive anggota (sawise menehi label nomer teluk) banjur pasang menyang PC desktop utawa server sing mlaku Ubuntu 22.04 LTS / 24.04 LTS (malah boot saka USB stick Live).

Langkah 1: Instal toolkit penyelamat forensik ing Ubuntu¶

Bukak terminal ing mesin penyelamat Ubuntu lan instal utilitas sing dibutuhake:

sudo apt-get update
sudo apt-get install -y gddrescue smartmontools mdadm lvm2 btrfs-progs xfsprogs zfsutils-linux

Langkah 2: Peta saben huruf drive, nomer seri, lan tata letak partisi¶

Dhaptar kabeh piranti pamblokiran sing disambungake lan nomer seri hardware supaya sampeyan ora bakal bingung karo disk penyelamat karo disk NAS sumber:

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,TYPE,MOUNTPOINTS

Deleng tabel partisi saka drive Synology DSM, QNAP, utawa TrueNAS sing khas:

Langkah 3: Priksa mdadm --examine kanggo ndeleng kenapa larik kasebut nabrak (The Event Counter Matrix)¶

Ing Synology, QNAP, utawa Linux mdadm array, mriksa metadata RAID ing partisi data pangguna (contone, partisi 3 ing /dev/sdb3, /dev/sdc3, /dev/sdd3, /dev/sde3) tanpa masang utawa ngowahi apa-apa:

sudo mdadm --examine /dev/sd[b-e]3 | grep -E "Filename|Magic|Update Time|Events|Array State|Device Role"

Mbandhingake output ing kabeh papat drive:

/dev/sdb3:
    Update Time : Sat Oct 31 14:12:09 2026
         Events : 482190
   Device Role : Active device 0
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdc3:
    Update Time : Thu Oct 29 03:44:11 2026
         Events : 479012
   Device Role : Active device 1
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdd3:
    Update Time : Sat Oct 31 14:12:04 2026
         Events : 482188
   Device Role : Active device 2
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sde3:
    Update Time : Sat Oct 31 14:12:09 2026
         Events : 482190
   Device Role : Active device 3
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

Waca crita forensik iki kanthi teliti: 1. /dev/sdc3 (Device Role 1) duwe Events count saka 479012 wiwit rong dina kepungkur (Oct 29). Drive kasebut mandheg dhisik, rong dina kepungkur, lan wiwit offline. 2. /dev/sdb3 (Role 0) lan /dev/sde3 (Role 3) loro-lorone wis Events : 482190 ing 14:12:09. 3. /dev/sdd3 (Role 2) wis Events : 482188 ing 14:12:04, mung 5 detik lan 2 acara ing mburi sdb3 lan sde3. 4. Kesimpulan: Sampeyan kudu mbangun maneh array nggunakake sdb3 (Role 0), sdd3 (Role 2), lan sde3 (Role 3) (sing konter acarane mung 2 tik), dene ** budhal sdc3 (Role 1) metu rampung**.

Fase 3: Kloning saben drive bit-kanggo-bit karo GNU ddrescue¶

Sadurunge mlaku mdadm --assemble --force utawa zpool import -F, kloning saben drive sing dibutuhake (utamane drive sing ilang amarga sektor ala, kayata /dev/sdd ing conto ing ndhuwur) menyang drive kosong sehat kanthi kapasitas sing padha utawa luwih gedhe, utawa dadi mentah .img file ing volume panyimpenan gedhe.

Langkah 1: Kenapa ddrescue karo mapfile iku wajib¶

Standar dd aborts ing sektor ala pisanan, utawa karo conv=noerror,sync sampah jam mecah sirah diwaca liwat trek rusak nalika nul-Isi megabyte data apik jejer. GNU ddrescue dianggo ing pass multi-tataran cerdas: 1. Pass 1 (Fase Copying): Nyalin kabeh wilayah sing sehat, respon cepet saka disk kanthi kecepatan urutan lengkap (150 MB/s kanggo 250 MB/s), langsung mlumpat liwat sembarang blok alon utawa ora bisa diwaca supaya drive ora overheat utawa mati sadurunge entuk 99.99% data apik. 2. Pass 2 (Fase trimming): Waca nganti tekan pojok pas saben blok ala saka ngarep lan mburi (reverse direction) kanggo ngisolasi wilayah sing rusak mudhun menyang sektor hardware 4 kilobyte sing tepat. 3. ** Pass 3 (Scraping phase) **: Nyoba maneh sektor sing rusak alon-alon tanpa ngreset bis sing ora perlu.

Langkah 2: Jalanake 2-tataran ddrescue printah clone¶

Tansah nemtokake mapfile (sdd_rescue.map). Yen drive sumber mati pedhot lan mbutuhake siklus daya, ddrescue maca mapfile lan nerusake ing bait sing tepat sing ditinggalake tanpa maca maneh sektor sing wis disalin:

# Stage 1: Fast forward pass skipping bad/slow blocks immediately (-n = no-scrape)
sudo ddrescue -f -n -b 4096 /dev/sdd /dev/sdh /root/sdd_rescue.map

# Stage 2: Targeted trimming and 3-retry scrape of the skipped bad sectors
sudo ddrescue -f -d -r 3 -b 4096 /dev/sdd /dev/sdh /root/sdd_rescue.map

Fase 4: Rekonstruksi Synology DSM (SHR-1 / SHR-2 / RAID Klasik), QNAP, lan Linux mdadm¶

Sawise drive kloning (utawa piranti loop mung diwaca) wis siyap lan drive NAS asli dicopot kanthi aman, tindakake urutan perakitan sing ora ngrusak sing tepat kanggo platform sampeyan.

Skenario A: Linux standar mdadm utawa Synology Classic RAID (RAID 5 / RAID 6)¶

1. Mungkasi parsial wae md array sing Ubuntu bisa uga wis nyoba kanggo miwiti:

   cat /proc/mdstat
   sudo mdadm --stop /dev/md127
   

2. Ngumpulake partisi kloning (sdb3, sdd3, sde3, ngilangake sing wis suwe mati sdc3) ing mode mung diwaca:

   sudo mdadm --assemble --force --readonly --verbose /dev/md2 /dev/sdb3 /dev/sdd3 /dev/sde3
   

   Watch output: mdadm bakal laporan forcing event count in /dev/sdd3(2) from 482188 up to 482190 lan mdadm: /dev/md2 has been started with 3 drives (out of 4).
3. Verifikasi larik aktif lan ditandhani (auto-read-only) utawa (read-only):

   cat /proc/mdstat
   

Skenario B: Synology Hybrid RAID (SHR-1 lan SHR-2) karo LVM2 lan Btrfs / ext4¶

Synology SHR (Synology Hybrid RAID) iku 100 persen standar Linux mdadm + LVM2 (Logical Volume Manager): - Nalika kabeh drive ing blumbang SHR padha ukuran (contone, papat 8 terabyte drive), Synology nggawe siji. mdadm partisi RAID 5 (md2 ing pemisahan 3 saben drive) lan panggonan sing LVM2 kelompok volume (vg1000 utawa vg1) ing ndhuwur md2. - Nalika drive ing blumbang SHR duwe ukuran campuran (contone, loro 8 terabyte drive lan loro 16 terabyte drive), Synology nggawe loro kapisah. mdadm susunan: md2 liwat Partisi 5 (8 TB irisan ing kabeh 4 drive ing RAID 5) lan md3 liwat Partisi 6 (sisa 8 TB irisan ing loro 16 TB drive ing RAID 1), banjur gabung md2 + md3 dadi siji LVM2 Kelompok Volume (vg1000).

Kanggo masang volume Synology SHR mung diwaca ing Ubuntu sawise ngrakit pasukan /dev/md2 (lan /dev/md3 yen ukuran campuran SHR): 1. Pindai Synology LVM2 Volume Fisik lan Grup Volume:

sudo pvscan
sudo vgscan
sudo lvscan

sudo vgchange -ay /dev/vg1000

sudo mkdir -p /mnt/synology_rescue
sudo mount -t ext4 -o ro,noload /dev/vg1000/lv /mnt/synology_rescue

sudo mkdir -p /mnt/synology_rescue
sudo mount -t btrfs -o ro,norecovery /dev/vg1000/lv /mnt/synology_rescue

sudo mount -t btrfs -o ro,norecovery,usebackuproot /dev/vg1000/lv /mnt/synology_rescue

Skenario C: Synology DSM 7+ Volume Encryption or Shared Folder Encryption (eCryptfs)¶

• ** Enkripsi Folder Dibagi (@sharename@ folder sing ngemot ECRYPTFS_FNEK_ENCRYPTED... jeneng berkas)**: Nyalin kabeh @encrypted_share@ folder mati /mnt/synology_rescue pisanan, banjur pasang lan dekripsi ing Ubuntu nggunakake sandi enkripsi Synology utawa .key berkas:

  sudo apt-get install -y ecryptfs-utils
  sudo mkdir -p /mnt/decrypted_share
  sudo mount -t ecryptfs -o ro /mnt/synology_rescue/@encrypted_share@ /mnt/decrypted_share
  

• ** DSM 7.2+ Enkripsi Volume Lengkap (LUKS)**: Yen /dev/vg1000/lv nuduhake TYPE="crypto_LUKS" ing blkid, mbukak kunci mung diwaca nggunakake .rkey File Kunci Recovery diundhuh nalika volume digawe:

  sudo cryptsetup open --readonly --key-file /path/to/Volume1.rkey /dev/vg1000/lv synology_crypt
  sudo mount -o ro,norecovery /dev/mapper/synology_crypt /mnt/synology_rescue
  

Skenario D: QNAP QTS (LVM2 Thin Provisioning lan DRBD lapisan)¶

Unit QNAP NAS modern (QTS 4.3+ / 5.x) masang simpul tunggal internal DRBD piranti (/dev/drbd1) antarane /dev/md1 lan ing LVM2 Kelompok Volume (vg1). 1. Kawitan pasukan-ngrakit partisi data QNAP (/dev/sd[b-e]3) mung diwaca menyang /dev/md1:

sudo mdadm --assemble --force --readonly /dev/md1 /dev/sdb3 /dev/sdd3 /dev/sde3

Fase 5: Nylametake TrueNAS lan Linux ZFS kolam (RAIDZ1, RAIDZ2, RAIDZ3)¶

Yen server panyimpenan sampeyan nganggo TrueNAS CORE, TrueNAS SCALE, Proxmox VE, utawa Ubuntu ZFS, Recovery ora bisa digunakake. mdadm. Nanging, ZFS nggabungake manajer volume lan copy-on-write (CoW) filesystem dadi arsitektur transaksional tunggal sing dibangun ing sekitar Uberblocks lan Grup Transaksi berurutan (TXGs).

Langkah 1: Priksa 4 label ZFS vdev (L0, L1, L2, L3) ing saben disk kloning¶

Saben partisi anggota ZFS nyimpen patang salinan konfigurasi blumbang sing padha lan susunan saka 128 Uberblocks pungkasan (loro label ing ngarep partisi, L0 lan L1, lan rong label ing pungkasan, L2 lan L3). Mlayu zdb -l ing saben partisi kloning kanggo mriksa status pool lan Grup Transaksi sing paling dhuwur (txg):

sudo zdb -l /dev/sdb2 | grep -E "name:|state:|txg:|guid:" | head -n 20

Bandingake txg: nomer ing kabeh drive kloning. Kaya wae mdadm's Events counter, yen siji disk dropped metu 5 menit sadurunge mundhut daya utawa gulung disk kapindho, sawijining txg bakal rada luwih murah tinimbang disk sing isih ana.

Langkah 2: Impor blumbang ZFS ing mode Waca Mung (-o readonly=on)¶

Pisanan mriksa Kolam impor tanpa soyo tambah apa liwat sudo zpool import -d /dev/disk/by-id. Aja ngimpor blumbang ZFS sing rusak utawa multi-disk ing mode maca-tulis. Nalika diimpor karo -o readonly=on, ZFS ora nyoba miwiti resilver, ora nulis Uberblocks anyar, lan ora bisa panik kernel yen peta spasi rusak (spacemap) ditemoni sajrone alokasi nulis:

sudo mkdir -p /mnt/zfs_rescue
sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue tank

Langkah 3: Yen zpool import gagal karo I/O error utawa corrupted data, gunakake TXG Rollback (-F lan -T)¶

Yen rong drive ilang sajrone sawetara detik sajrone bledosan nulis abot, Grup Transaksi paling anyar (TXG N) bisa uga ora lengkap ing garis paritas sing isih ana, nalika TXG N-1 utawa TXG N-2 (ditulis 5 kanggo 15 detik sadurungé) punika 100 persen utuh nang buffer ring Uberblock.

1. Tes pratinjau rollback garing sing ora ngrusak (-F -n):

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -F -n tank
   

   Yen ZFS laporan Would be able to return pool to its state as of <timestamp>, mbukak impor rollback mung diwaca tanpa -n:

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -F tank
   

2. Yen -F isih ora bisa Gunung Uberblocks paling anyar, dhaftar nomer Uberblock TXG sajarah karo zdb lan ngimpor TXG lawas tartamtu (-T):

   sudo zdb -e -ul /dev/sdb2 | grep -E "Uberblock|txg =|timestamp ="
   

   Pilih a txg nomer saka 30 nganti 60 detik sadurunge kacilakan (contone, txg = 9481020) lan ngimpor blumbang beku ing wektu sing tepat ing mode mung maca:

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -T 9481020 tank
   

Fase 6: Verifikasi sawise pemulihan lan nyegah kaskade mbangun maneh ing mangsa ngarep¶

Sawise sampeyan wis nyalin 100 persen saka data mbalekake saka /mnt/synology_rescue utawa /mnt/zfs_rescue menyang target serep independen, tindakake dhaptar priksa hardware lan konfigurasi iki sadurunge nglebokake NAS sampeyan maneh:

• ** Aja tuku kabeh drive NAS saka pengecer sing padha ing dina sing padha **: Drive saka manufaktur sing padha nuduhake batch kepala lan perangkat kukuh sing padha, nyebabake gagal sajrone sawetara jam sajrone mbangun maneh. Campuran kumpulan utawa pabrikan (Seagate IronWolf / Exos, WD Red Plus / Ultrastar, Toshiba N300 / MG).
• ** Mung nggunakake NAS / Enterprise drive karo TLER / SCT ERC diaktifake (utawa mundhakaken Linux mdadm Wektu entek SCSI kanggo drive desktop)**: Kanggo drive konsumen ing Linux mdadm, gunakake a udev aturan kanggo mundhakaken /sys/block/sdX/device/timeout saka 30 detik kanggo 180 detik dadi mdadm ngenteni remapping sektor internal tinimbang nyelehake drive.
• ** Migrasi array kanthi drive luwih gedhe tinimbang 8 TB saka RAID 5 / SHR-1 / RAIDZ1 kanggo RAID 6 / SHR-2 / RAIDZ2**: karo 12 TB kanggo 24 TB drive, wektu mbangun maneh paritas tunggal ngluwihi 30 jam, nggawe paritas ganda (RAID 6 / SHR-2 / RAIDZ2) penting kanggo slamet saka bad sector sak resilvering.
• ** Jadwal saben wulan Data Scrubbing (mdadm check / zpool scrub) lan Extended SMART tes**: Nggosok saben wulan ndandani kesalahan sektor laten (Current_Pending_Sector) nalika kabeh drive online.
• ** Elinga yen RAID kasedhiyan dhuwur, tau serep **: Tindakake ing 3-2-1 strategi serep karo salinan offline.

Nomer darurat regional lan protokol agensi¶

Panyimpenan mati sing mengaruhi jaringan perawatan kesehatan, komunikasi darurat, utawa cathetan pribadi miturut ukum mbutuhake eskalasi langsung:

• Amerika Serikat lan Kanada: Nelpon 911 yen kacilakan panyimpenan mateni sistem klinis rumah sakit (EHR / PACS) utawa kiriman. Lapor NAS-target ransomware (DeadBolt, LockBit, Akira) kanggo CISA (1-844-Say-CISA / cisa.gov/report), FBI IC3 (ic3.gov), utawa Canadian Center for Cyber Security (1-833-CYBER-88).
• Inggris Raya: Nelpon 999 kanggo kahanan darurat sing mengaruhi safety urip utawa perawatan NHS akut. Ing UK GDPR, priksa manawa mundhut data pribadi sing ora didhukung permanen mbutuhake kabar ICO (0303 123 1113) ing 72 jam.
• Uni Eropa: Nelpon 112 ing EU. Entitas miturut NIS2 Directive kudu nglaporake gangguan operasional utama menyang CSIRT nasional sajrone 24 jam, lan kelangan kasedhiyan data pribadhi permanen bakal nyebabake GDPR Artikel 33 nglaporake sajrone 72 jam.
• Australia lan Selandia Baru: Nelpon 000 ing Australia utawa 111 ing Selandia Anyar; laporake prasarana utawa insiden NAS ransomware menyang ACSC (1300 CYBER1) utawa CERT NZ (0800 237 869).
• India lan Asia-Pasifik: Nelpon 112 ing India kanggo nanggepi darurat; laporake kedadeyan panyimpenan infrastruktur menyang CERT-In (incident@cert-in.org.in) ing jendela wajib 6 jam.

Pitakonan sing kerep ditakoni¶

Ngapa mdadm --assemble --force nolak kanggo miwiti RAID sandi 5 Uploaded karo not enough to start the array?¶

Ing 4-drive RAID 5 array, paling ora 3 saka 4 drive kudu liwat menyang mdadm --assemble --force. Mlayu sudo mdadm --examine /dev/sd[a-z]3 kanggo mriksa kenapa drive katelu ditolak: sampeyan bisa ngliwati kabeh disk tinimbang partisi (/dev/sdd tinimbang /dev/sdd3), superblok kasebut ditandhani minangka a nyisakke dening dibangun maneh diselani, utawa otomatis assembler Ubuntu dikunci siji drive dadi ora aktif /dev/md127 piranti (run sudo mdadm --stop --scan pisanan, banjur mbukak maneh mdadm --assemble --force --readonly).

Apa yen drive wiwit dibangun maneh (Recovery = 12%) sadurunge drive kapindho dropped metu?¶

Yen Drive 2 mati, sampeyan masang Drive panggantos 2, lan ing 12% proses mbangun maneh Drive 3 dropped offline amarga sektor ala, aja nganggo Drive 2 sing wis dibangun maneh 12%.. Nanging, kloning asli Drive 3 karo ngluwari. Amarga Drive 3 wis rampung saiki nganti mbangun mandeg ing 12%, pasukan-ngrakit array mung diwaca nggunakake Drive 1, ngluwari klone Drive 3, lan Drive 4 (ninggalake Drive 2 metu) menehi Uploaded konsisten.

Apa aku bisa nyelehake drive Synology utawa QNAP menyang sasis NAS sing anyar yen sumber daya utawa papan NAS mati?¶

Ya, loro Synology (Migrasi HDDlan QNAP (Migrasi NAS Langsung) nyimpen konfigurasi RAID ing drive dhewe. Nanging, yen loro utawa luwih drive wis ilang (`Volume Crashed`) sadurunge sasis mati, ora boot mau nang sasis NAS anyar, amarga tuntunan migrasi bisa nimpa partisi utawa micu mbangun maneh sing ngrusak. Nylametake data mung diwaca ing Ubuntu dhisik.

Carane aku ngerti yen drive dropped aman kanggo Klone ddrescue mungsuh kudu lab cleanroom?¶

Sambungake drive menyang SATA, uripake, lan ngrungokake 10 detik nalika nonton sudo dmesg -w. Yen drive nggawe swara ngeklik, scraping, utawa buzzing irama, muter munggah lan muter maneh mudhun, utawa laporan kapasitas minangka 0 B / 4,1 GB ing lsblk, kepala maca / nulis wis gagal fisik: Cut daya langsung lan nggunakake lab cleanroom. Yen drive muter lancar, nuduhake kapasitas lengkap ing lsblk, lan mung log Saiki_Tunda_Sektor utawa wektu entek kasalahan, Klone karo ngluwari.

Apa "RAID 5 Tulis Lubuk," lan carane ZFS utawa Btrfs nyegah nalika mati listrik?¶

Ing tradisional RAID 5 / RAID 6 tanpa jurnal, nganyari belang mbutuhake nulis pemblokiran data lan pemblokiran paritas kanggo rong disk bebarengan. Yen daya gagal ing tengah nulis, data lan paritas ora cocog maneh (ing Tulis Lubang). ZFS (`RAIDZ`) lan Btrfs mbusak bolongan nulis nggunakake Copy-on-Write (`CoW`), nulis saben garis anyar menyang blok sing ora digunakake lan nganyari Uberblock / pointer root mung sawise garis lengkap ing disk.

Aku bisa nggunakake dmsetup overlay kanggo nyoba paramèter RAID tanpa ngowahi drive kloning?¶

Ya, sampeyan bisa nggawe Copy-on-Write (`CoW`) overlay ing ndhuwur piranti loop mung diwaca (`losetup --read-only`) nggunakake Linux dmsetup (`snapshot` target) didhukung dening file sing jarang ing /tmp. Sembarang nulis saka mdadm --assemble --force utawa fsck -y pindhah menyang disposable /tmp file overlay, ngijini sampeyan ngreset ing 1 detik yen perlu.

Pandhuan sing gegandhengan¶

• Array NAS RAID rusak, sawetara drive gagal, lan pemulihan ZFS/Btrfs
• RAID kertu controller mati, ngimpor konfigurasi manca, lan apa sampeyan kudu tau initialize disk
• Gagal hard drive lan Recovery data
• SSD lan NVMe modus mung maca dadakan, 0% blok cadangan, lan TRIM mateni nylametake
• rm -rf utawa Shift+Delete sing ora disengaja ing Linux, macOS, utawa Windows: remount mung maca langsung
• Serep komputer, strategi 3-2-1, lan pemulihan bencana
• Nomer darurat miturut negara

Sumber lan panuntun dhumateng resmi¶

• Linux Raid Wiki (raid.wiki.kernel.org) & Organisasi Kernel Linux: * Mbalekake RAID Piranti Lunak Gagal (mdadm --assemble --force --readonly lan Kontra Acara Ora cocog)*.
• Yayasan Perangkat Lunak Gratis (GNU Project): GNU ddrescue Manual: Forensic Data Recovery saka Gagal Media.
• Dokumentasi OpenZFS (openzfs.github.io): * ZFS Pool Import Recovery (zpool import -F, Impor Mung Waca, lan zdb Inspeksi)*.
• Synology Inc.: Synology Knowledge Center: Kepiye cara nggunakake PC kanggo mbalekake data nalika Synology NAS malfunctions (mdadm + LVM2 Pemasangan).
• Institut Standar lan Teknologi Nasional (NIST) (Amerika Serikat): Publikasi Khusus 800-209: Pedoman Keamanan kanggo Infrastruktur Panyimpenan.