RAID Array nasazlığı, pozulmuş NAS saxlama hovuzu və yenidən qurulma təhlükəsizliyi¶

Ev və ya kiçik biznes Şəbəkəsinə Qoşulmuş Yaddaş (NAS) cihazı (məsələn, Synology DiskStation, QNAP Turbo NAS, TrueNAS və ya Unraid serveri) sarı LED ilə siqnal verməyə başlayanda və "Storage Pool Degraded" və ya **"Səs Məhdudlaşdı" xəbərini verəndə, adətən, sahibləri çox 20 kliklədiyini müəyyən edir. əvəzolunmaz ailə fotoşəkilləri və iş qeydləri saxlanılır və ya həmişəlik məhv edilir. Onilliklər ərzində istifadəçilərə öyrədilib ki, RAID 5 və ya RAID 1 massivindəki disk qırmızı rəngə çevrildikdə siz sadəcə ölü diski çıxarıb yeni boş diski sürüşdürərək "Təmir et/Yenidən qur" düyməsini sıxırsınız.

Eyni istehsal partiyasından alınmış 8 TB-dan 24 TB-a qədər disklərlə qurulmuş müasir yüksək tutumlu yaddaş hovuzlarında kor-koranə yerdə RAID-in yenidən qurulmasına başlamaq çoxlu diskli massivlərin bərpa olunmayan ümumi ölümünün №1 səbəbidir. 4-sürücülü 16 TB RAID 5 massivinin yenidən qurulması hər bir köhnəlmiş diski maksimum istilik və mexaniki yükdə 24-72 saat ərzində sektorlarının 100 faizini fasiləsiz oxumağa məcbur edir. Sağ qalan qardaş sürücülərdən biri düzəldilə bilməyən oxu xətası (URE) ilə qarşılaşdıqda və ya yenidən qurulmanın yarısında baş deqradasiyasına məruz qaldıqda, RAID nəzarətçisi həmin ikinci sürücünü hovuzdan çıxarır və bütün massivi çökdürür. RAID, ZFS və ya Btrfs fövqəladə vəziyyətindən xilas olmaq üçün S.M.A.R.T.-nin yoxlanılması, bütün yazıların dərhal dayandırılması tələb olunur. bütün sağ qalan disklər üzrə telemetriya, massiv topologiyasına toxunmadan *əvvəl kritik qovluqların ehtiyat nüsxəsini çıxarmaq və GNU ilə deqradasiya olunmuş üzv diskləri təsvir etmək ddrescue paritetin yenidən qurulmasına və ya yalnız oxuna bilən metadata yığımına cəhd etməzdən əvvəl.

Bunu indi edin¶

1. NAS və ya server işə salındıqda onları "yenidən yerləşdirmək" üçün heç vaxt birdən çox diski çıxartmayın və dəqiq yuva nömrələrini qeyd etmədən diskləri dəyişdirməyin. Tək bir sürücü qabına toxunmazdan əvvəl iti və ya etiket istehsalçısı götürün və hər diskin fiziki yuxarı hissəsini onun dəqiq yuva nömrəsi ilə qeyd edin (Bay 1 / sda, Bay 2 / sdb, Bay 3 / sdc). Müasir Linux olsa da mdadm, LVM və ZFS massivləri hər diskdə UUID superbloklarını saxlayır, aparat RAID kontrollerləri (Dell PERC, HP Smart Array, Broadcom/LSI MegaRAID) tez-tez konfiqurasiya metadatasını fiziki SAS/SATA arxa plan slot nömrələrinə bağlayır.
2. Əgər müasir xarici ehtiyat nüsxəniz yoxdursa, deqradasiya olunmuş RAID 5 / SHR-1 massivində dərhal “Təmir et” və ya “Yenidən qur” seçiminə Klikləməyin. Tək paritetli massiv (RAID 5, Synology SHR-1 və ya ZFS RAIDZ1) rejimində olarkən (1 diskiniz sökülüb ** rejimindədir), bütün diskiniz hələ də onlayn rejimdə qalır), Hazırda 100 faiz oxuna bilir. Xarici USB 3.0 sabit diskini birbaşa NAS-a qoşun və sağ qalan diskləri paritetin yenidən qurulmasının qəddar 48 saatlıq stress testinə məruz qoymazdan * əvvəl* ən kritik, əvəzolunmaz qovluqlarınızı deqradasiya olunmuş hovuzdan köçürün.
3. Heç vaxt "Diski işə salın", "Yeni hovuz yarat", "Konfiqurasiyanı təmizləyin" və ya işə salmayın. fsck -y / btrfs check --repair qəzalı massivdə. İki disk eyni vaxtda RAID 5 massivindən çıxdıqda (çox vaxt qısa enerji təchizatı itkisi və ya həqiqi fiziki ölüm əvəzinə SATA fasiləsi səbəbindən), NAS GUI Yaddaş Hövzəsini "Xəzalı" kimi qeyd edəcək və həcmi işə salmağı və ya yenidən yaratmağı təklif edəcək. Başlama paritet zolaqları üzrə təzə superbloklar və sıfırlar yazır, bərpa oluna bilən məlumatları məhv edir. Eynilə, qaçış btrfs check --repair zədələnmiş Btrfs həcmi üzrə Linux nüvəsi icmasında miqyas ağacını bərpa olunmayan şəkildə məhv etdiyinə görə məşhurdur.
4. Bütün Docker konteynerlərini, Virtual Maşınları, Plex media serverlərini, müşahidə kamerası qeydlərini və planlaşdırılan RAID Skrublarını dərhal dayandırın. Deqradasiya edilmiş massiv üçün hər bir yazma əməliyyatı paritet yazma dəliyi riskini artırır və ya ikinci diski kənardan itələyir. NAS veb interfeysinə və ya SSH terminalına daxil olun və bütün fon xidmətlərini və yüksək I/O tapşırıqlarını dayandırın.
5. Əgər NAS-da hər hansı disk ritmik klik, döymə, daşlama və ya qışqırıq səsləri çıxarırsa, NAS-ı indi təmiz şəkildə bağlayın. Klikləmə və ya üyütmə diskində fiziki oxu/yazma başlığı qəzaya uğradı (bax). Sərt diskin nasazlığı və məlumatların bərpası). Onu NAS korpusunun içərisində fırlanan vəziyyətdə buraxmaq dəqiqələr ərzində maqnit lövhələrini toza çevirəcək.
6. "NAS nasazlığının" əslində sadəcə ölü NAS anakartı və ya xarici elektrik kərpici olub-olmadığını yoxlayın. Synology, QNAP və ya Asustor NAS birdən-birə ümumiyyətlə işə düşməyəcəksə və ya mavi güc LED-i dayanmadan yanıb-sönürsə (məşhur Intel Atom C2000 saat siqnalı xətası kimi), **sabit diskləriniz və məlumatlarınız demək olar ki, yaxşı **10 faizdir. Siz bu diskləri əvəzedici NAS-a köçürə və ya standart SATA portlarından istifadə edərək istənilən Ubuntu Linux masaüstü kompüterinə yalnız oxunmaq üçün quraşdıra bilərsiniz.

flowchart TD
    A["NAS siqnalı / RAID massivi Deqradasiya və ya Qəza vəziyyətindən xəbər verir"] --> B{"Hər hansı bir sürücü mexaniki klik, daşlama və ya qırıntı səsləri çıxarır?"}
    B -->|"Bəli: Fiziki baş qəzası"| C["NAS-ı dərhal söndürün, hər bir diski Bay Nömrəsi ilə etiketləyin və kliklənən diski çıxarın"]
    B -->|"Xeyr: Səssiz əməliyyat"| D{"Saxlama Hovuzu vəziyyəti necədir?"}
    D -->|"DEGRADED (1 disk uğursuz oldu, səs hələ də oxuna bilər)"| E["Bütün Docker/VM/Surveillance yazılarını STOP edin və hələ də Yenidən Qurma düyməsini Klikləməyin"]
    E --> F["S.M.A.R.T-ni yoxlayın. Bütün SURVIVING disklərində atributlar (ID 5, 187, 197, 198)"]
    F --> G["Xarici USB sürücüsünü yerləşdirin və İLK ÖLÇÜ pisləşmiş hovuzdan kritik faylları kopyalayın"]
    G --> H{"Sağ qalan disklər pis sektorları göstərirmi (ID 5 / 197 > 0)?"}
    H -->|"Bəli: İkinci sürücü nasazdır"| I["Hər hansı yenidən qurmağa cəhd etməzdən əvvəl gücü söndürün və hər bir diski GNU ddrescue ilə klonlayın"]
    H -->|"Xeyr: Sağ qalmaq 100% sağlam sürücülük edir"| J["Əvəzedici CMR sürücüsünü daxil edin (heç vaxt SMR deyil) və paritet Rebuild-i işə salın"]
    D -->|"QAZA OLDU / OFFLINE (Birdən çox disk buraxıldı)"| K["fsck/btrfs --repair-i işə salmayın və ya işə salmayın; gücü kəsin və bütün sürücü yuvalarını etiketləyin"]
    C --> L["GNU ddrescue + mapfiles istifadə edərək bütün deqradasiya olunmuş üzv diskləri sağlam disklərə klonlayın"]
    K --> L
    L --> M["Linux mdadm/LVM, zpool import -o readonly=on və ya UFS Explorer RAID vasitəsilə Yalnız oxumaq rejimində klonlanmış sürücüləri yenidən yığın"]

RAID-in yenidən qurulmasının niyə uğursuz olduğunu başa düşmək: "Qardaş Sürücü Batch" və "SMR Drive" tələləri¶

NAS-da fövqəladə vəziyyət zamanı təhlükəsiz qərarlar qəbul etmək üçün bərpa zamanı RAID massivlərini öldürən iki fiziki tələni başa düşməlisiniz:

Tələ 1: Əlaqəli Partiya Uğursuzluğu və Düzəliş Olmayan Oxuma Səhvləri (URE)¶

Əksər NAS sahibləri dörd və ya altı sabit diskin hamısını eyni satıcıdan eyni gündə alırlar. Bu disklər eyni zavod montaj xəttindən çıxır, eyni proqram təminatı reviziyalarını paylaşır, eyni şassi vibrasiya mühitində fırlanır və eyni sayda işə salınma saatını toplayır. * Drive 1 38.000 saatlıq əməliyyatdan sonra öləndə, Drive 2, 3 və 4 də 38.000 saat köhnəlmiş olur. * Bay 1-ə təzə əvəzedici diski yükləsəniz və RAID 5 massivində Yenidənqurma düyməsini klikləsəniz, NAS nəzarətçisi Bay 1 üçün çatışmayan paritet bloklarını XOR hesablamaq üçün Disk 2, 3 və 4-də hər bir sektoru oxumalıdır. * Əgər Disk 3 iki il ərzində açmadığınız köhnə qovluqda 14 oxunmayan pis sektoru (Mövcud Gözləyən Sektorlar, S.M.A.R.T. ID 197) sakitcə saxlayırsa, yenidən qurma prosesi 19-cu saatda ilk növbədə həmin pis sektorlara zərbə vuracaq. bir çox saniyəlik oxuma bloku nəzarətçinin Sürücü 3-ü "Uğursuz/Xətalı" kimi işarələməsinə səbəb olur, ikinci diski tək paritetli RAID 5 massivindən çıxarır və bütün həcmi sıradan çıxarır.

Tələ 2: Heç vaxt SMR (Şingled Magnetic Recording) diskini RAID və ya ZFS massivinə daxil etməyin¶

NAS-ı yenidən qurmaq üçün yerli elektronika mağazasında təcili əvəzedici sabit disk alarkən, əvəzedici diskin CMR (Ənənəvi Maqnit Qeydiyyatı), HEÇ VAXT SMR (Şingled Magnetic Recording) istifadə etdiyini yoxlayın. * Büdcə masa üstü sərt diskləri (məsələn, standart Western Digital Red qeyri-Plus EFAX 2 TB-dən 6 TB-a qədər modellər, Seagate Barracuda Compute masa üstü diskləri və istifadəçilərin plastik qutulardan "çıxardığı" bir çox ucuz xarici USB disklər) maqnit izlərinin dam örtüyü kimi üst-üstə düşdüyü Drive-Managed SMR istifadə edir. * Davamlı çox terabaytlıq RAID və ya ZFS resilver yazısı zamanı SMR sürücüsünün daxili media keşi 30 dəqiqə ərzində tamamilə doldurulur. Keş dolduqdan sonra SMR diski 10 ilə 30+ saniyəyə dayanır və bütün şingled lentləri daxildən oxuyur və yenidən yazır və ya ATA qaytarır. IDNF (Sector ID Not Found) fasilə. * Linux mdadm, Synology DSM və xüsusilə ZFS (zed) həmin 20 saniyəlik SMR stendlərini ölü sabit disk kimi şərh edin, yenidən qurma işinin ortasında yeni əvəzedici diski silsilədən çıxararaq. Həmişə CMR NAS/Enterprise diskləri alın (məsələn, WD Red Plus / WD Red Pro, Seagate IronWolf / IronWolf Pro / Exos və ya Toshiba N300 / MG Enterprise).

Diaqnostik matrisa: RAID səviyyələri, nasazlığa dözümlülük və sağ qalma qaydaları¶

"Deqradasiya edilmiş" NAS Hovuzu üçün addım-addım sınaq (1 disk uğursuz oldu, məlumat hələ də əlçatandır)¶

RAID 1, RAID 5, SHR-1, RAID 6 və ya RAIDZ hovuzunda 1 sürücü uğursuz olduğu üçün NAS siqnal verirsə, diski dəyişdirməzdən əvvəl bu dəqiq ardıcıllığa əməl edin:

Addım 1: Audit S.M.A.R.T. ilk olaraq bütün SURVIVING disklərində atributlar¶

Açın Storage Manager -> HDD/SSD -> Health Info -> S.M.A.R.T. Atribut (Synology/QNAP-də) və ya işə salın smartctl -a /dev/sdX Hovuzda qalan hər sağlam/onlayn sürücüdə SSH vasitəsilə. bax RAW_VALUE bu dörd kritik atribut üçün sütun: * ID 5 (Reallocated_Sector_Ct): İdeal olaraq olmalıdır 0. Sağ qalan sürücünün onlarla və ya yüzlərlə yenidən bölüşdürülmüş sektoru varsa, onun lövhə səthi və ya başlıqları aktiv şəkildə deqradasiyaya uğrayır. * ID 187 (Reported_Uncorrect): Olmalıdır 0. * ID 197 (Current_Pending_Sector): KRİTİK. Hər hansı bir ədəddən çox 0 o deməkdir ki, sağ qalan sürücü *hazırda RAID-in yenidən qurulması onları oxumağa çalışdığı anda qəzaya səbəb olmağı gözləyən oxunmayan sektorlara malikdir. * ID 198 (Offline_Uncorrectable): Olmalıdır 0.

Qərar Qaydası: * Sağ qalan bütün sürücülər ** göstərirsə0** 5, 187, 197 və 198 ID-lərdə siz kritik qovluqlarınızın ehtiyat nüsxəsini təhlükəsiz şəkildə xarici USB sürücüsünə çıxara və sonra sağlam CMR dəyişdirmə sürücüsündən istifadə edərək normal NAS GUI Təmir / Yenidənqurma ilə davam edə bilərsiniz. * Tək paritetli RAID 5 / SHR-1 / RAIDZ1 hovuzunda hər hansı sağ qalan sürücü ** göstərirsəCurrent_Pending_Sector > 0** və ya artır Reallocated_Sector_Ct, YENİDƏN TURMA İŞLƏTMƏYİN. Həcmi hələ də quraşdırılmış vəziyyətdə olan bütün məlumatları xarab olmuş NAS-dan dərhal xarici USB disklərə köçürün; Əgər səs artıq mübarizə aparırsa, NAS-ı söndürün və uğursuz üzv sürücüləri GNU istifadə edərək Linux PC-də klonlayın. ddrescue birinci.

RAID / NAS Həcmi "Qızıldıqda" addım-addım xilasetmə (Birdən çox disk buraxıldı)¶

Çərşənbə axşamı gecəsi Drive 2 uğursuz oldu və Drive 4 çərşənbə günü səhər saatlarında oyandıqda və 4 yuvalı RAID 5 NAS "Yaddaş Hövzəsi 1: Qəzaya uğradı" deyirsə, onda necə?

Niyə əksər "2 sürücülü nasazlıqlar" həqiqətən bərpa edilə bilər: Evinizi ildırım vurmadıqca və ya NAS pilləkənlərdən aşağı düşmədikcə, iki mexaniki sabit disk demək olar ki, eyni saniyədə tamamilə fəlakətli baş qəzalarına məruz qalmır. Bunun əvəzinə əslində baş verənlər ardıcıldır: 1. Drive 2 bir neçə pis sektor inkişaf etdirdi və günlər və ya saatlar əvvəl serialdan çıxarıldı (massiv Disk 1, 3 və 4-də Deqradasiya rejimində işləyir). 2. Daha sonra, Drive 4, NAS fon skrabını işləyərkən bir oxunmayan sektorla (və ya qısa SATA fasiləsi) qarşılaşdı. Disk 4-də həmin tək pis sektoru düzəltmək üçün massiv artıq ehtiyata malik olmadığı üçün RAID sürücüsü Disk 4-ü də çıxardı və bütün hovuzu Xəzalı qeyd etdi.

Bu ssenaridə, Drive 4 ən təzə, ən müasir reyd hadisə sayğacına malikdir (Events sayı) və 99,9999% sağlamdır, Drive 2 isə bir qədər köhnəlib ("köhnəlmiş").

Qəzaya uğramış Synology, QNAP və ya Linux-u necə bərpa etmək olar mdadm Linux PC-də təhlükəsiz şəkildə yığın¶

Addım 1: NAS-ı söndürün, hər sürücü yuvasını etiketləyin və sürücüləri Ubuntu Linux Live USB ilə işləyən masaüstü kompüterə qoşun¶

1. NAS-ı bağlayın. Hər diski etiketləyin (Bay 1, Bay 2, Bay 3, Bay 4).
2. Sürücüləri Ubuntu Linux Live USB-ə yüklənmiş masaüstü kompüterdə anakartın SATA portlarına (və ya İT rejimində LSI 9211-8i/9300-8i kimi HBA kartı; yük altında ayrılan ucuz USB mərkəzlərindən qaçın) qoşun.
3. Terminal açın və bölmə planını yoxlayın və mdadm superbloklar yalnız oxumaq üçün diaqnostik rejimdə:

# 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

Addım 2: Oxuyun Events sayğac və Array State -dən çıxış mdadm --examine¶

Çıxışına diqqətlə baxın sudo mdadm --examine /dev/sd[a-d]3 hər sürücü üçün: * Belə xətləri görəcəksiniz: * /dev/sda3: Events : 48210, Array State : A.AA (A = Aktiv, . = itkin) * /dev/sdb3 (Sürücü 2, birinci buraxıldı): Events : 47950, Array State : AAAA * /dev/sdc3: Events : 48210, Array State : A.AA * /dev/sdd3 (Sürücü 4, sonuncu buraxıldı): Events : 48209, Array State : A.AA * Nə olduğuna diqqət yetirin Events sayğac sizə deyir: Sürücü 1, 3 və 4 (sda3, sdc3, sdd3) bir-birinin 1 hadisəsi daxilindədir (48210 vs 48209), Sürərkən 2 (sdb3) tədbirdə çox erkən düşdü 47950. * Kritik qayda: 4-sürücülü RAID 5 massivində məlumatın 100 faizini yenidən qurmaq üçün sizə yalnız 3 disk lazımdır. Siz 3 ən təzə diskdən istifadə edərək massivi yığmalısınız (sda3, sdc3, və sdd3) və köhnə diski buraxın (sdb3). Təsadüfən köhnə köhnə sürücüdən istifadə edərək zorla yığırsınızsa (sdb3), iki gün əvvəlki fayl sistemi metadatası digər disklərdəki cari məlumat zolaqlarına uyğun gəlməyəcək və qovluqlarınızı korlayacaq.

Addım 3: GNU istifadə edərək hər hansı bir diski pis sektorlarla klonlayın ddrescue birinci¶

Quraşdırmadan əvvəl bu yaxınlarda düşmüş sürücünü klonlayın (/dev/sdd) (və ideal olaraq bütün üzv sürücülər) istifadə edərək sağlam bir əvəz sürücüsünə ddrescue (bax Sərt diskin nasazlığı və məlumatların bərpası tam üçün ddrescue sintaksis):

# 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

İndi uğursuz olan orijinalı ayırın /dev/sdd və sağlam klonla işləməyiniz üçün onu təhlükəsiz şəkildə rəfə qoyun (/dev/sde).

Addım 4: RAID massivini, LVM həcmi qrupunu və fayl sistemini YALNIZ OXUYAN rejimdə yenidən yığın¶

Synology (SHR / RAID) və QNAP sistemlərində yaddaş yığını üç qata qədər malikdir: mdadm (RAID) -> LVM2 (Məntiqi Həcm Meneceri) -> ext4 və ya Btrfs (Fayl Sistemi). Onları Ubuntu-da yalnız oxumaq rejimində təhlükəsiz quraşdırmaq üçün dəqiq əmr ardıcıllığı budur:

# 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

Bir dəfə /mnt/nas_rescue montajlar, bütün NAS paylaşılan qovluqlarınız (photo, homes, video, documents) içəridə görünəcək /mnt/nas_rescue/ beləliklə siz onları birbaşa xarici USB ehtiyat sürücüsünə kopyalaya bilərsiniz.

• Synology NAS-da qarışıq sürücü ölçüləri ilə "Synology Hybrid RAID (SHR)" varsa necə? Synology SHR sadəcə olaraq daha böyük diskləri çoxsaylı bölmələrə ayırır (sda5, sda6) və ayrıca yaradır mdadm hər bölmə səviyyəsi üzrə massiv, sonra bunlara qoşulur md massivlər bir LVM Həcmi Qrupunda (vg1000). Qaçış sudo mdadm --assemble --scan --readonly və sudo vgchange -ay avtomatik olaraq Ubuntu-da çox səviyyəli SHR həcmlərini yenidən birləşdirir.
• Kommersiya GUI Alternativi (Windows/macOS/Linux): Əgər siz Linux terminal əmrlərindən narahatsınızsa və ya mürəkkəb QNAP incə təminatlı LVM hovuzunuz varsa, UFS Explorer RAID Bərpa və ya ReclaiMe Pulsuz RAID Bərpası bütün qoşulmuş NAS disklərini yoxlaya bilər, Windows1 və ya Linux rejimində avtomatik olaraq proqram təminatını oxuya bilər. ölçüsü, paritet fırlanması və LVM ofsetləri və NAS disklərində bir sektoru dəyişdirmədən qovluqlarınızı kopyalayın.

ZFS (zpool) və Btrfs təcili xilasetmə komandaları¶

Müasir NAS platformaları (TrueNAS SCALE/CORE, Proxmox, Ubuntu Server, Unraid və Synology Btrfs cildləri) köhnəlik əvəzinə getdikcə daha çox kopyala-yazma (CoW) fayl sistemlərindən istifadə edir. ext4. Əgər ZFS zpool və ya Btrfs hovuzu quraşdırmaqdan imtina edir və ya elektrik kəsilməsi və ya sürücünün nasazlığından sonra yükləmə zamanı nüvə panikasına səbəb olur, normal quraşdırma uğursuz olacaq, çünki ƏS zədələnmiş yazma əməliyyatlarını təkrarlamağa çalışır. Siz yalnız oxumaq üçün əməliyyatların geri qaytarılması parametrlərindən istifadə etməlisiniz.

1. ZFS (zpool) Təcili Bərpa (TrueNAS / Proxmox / Linux ZFS)¶

Əgər ZFS hovuzu göstərilirsə FAULTED, UNAVAIL, və ya təmiz olmayan enerji itkisindən sonra onu idxal etməyə çalışdığınız anda serveri çökdürür (kernel panik):

# 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>

Bir dəfə altına quraşdırılmışdır /mnt/zfs_rescue, istifadə edərək məlumat dəstlərinizi kopyalayın rsync və ya zfs send hovuz oxumaq-yazmaq idxal etməyə cəhd etməzdən əvvəl.

2. Btrfs Emergency Recovery (Synology Btrfs / Unraid Cache Pool / Linux Btrfs)¶

Bunun əvəzinə, Btrfs həcmini ən az invazivdən ən dərin taramaya qədər ciddi mütərəqqi qaydada quraşdırmağa və ya çıxarmağa cəhd edin:

# 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/

Hardware RAID Controller Fövqəladə Hallar: "Xarici Konfiqurasiya" və Ölü RAID Kartları¶

Müəssisə serverləri (PERC kartları ilə Dell PowerEdge, Smart Array ilə HPE ProLiant, Lenovo ThinkSystem və ya Broadcom/LSI MegaRAID nəzarətçiləri olan iş stansiyaları) bortda NVRAM və batareya/superkondansatör keşi olan aparat RAID kartlarından istifadə edir.BBU / CacheVault).

1. Xarici Konfiqurasiyanı İdxal Edin və Aydın Konfiqurasiya (KRİTİK)¶

Sürücü bir anlıq əlaqəni kəsdikdə və ya siz sürücüləri əvəzedici server şassisinə köçürdükdə, Dell PERC və ya LSI MegaRAID BIOS açılış ekranı fasilə verəcək və elan edəcək: "Adapterdə xarici konfiqurasiya(lar) tapıldı." * ** HƏMİŞƏ seçin Import Foreign Configuration (və ya Preview Foreign Configuration -> Import).** "Xarici" etiketi sadəcə olaraq o deməkdir ki, RAID nəzarətçi sabit disklərin özlərində yazılmış etibarlı mövcud RAID metadatasını görür (sürücülərin sonundakı Disk Data Format / DDF və ya LSI konfiqurasiya sektorları) kartın cari NVRAM vəziyyətindən fərqlənir. İdxal massiv tərtibatını birbaşa disklərdən oxuyur və virtual diskinizi bir bayt itirmədən onlayn rejimə qaytarır. * Heç vaxt seçməyin Clear Foreign Configuration və ya Initialize Virtual Disk. Silinməsi və ya işə salınması massiv metadatasını silir və ya diskləri sıfırlayır. * İstisna Xəbərdarlığı: Əgər bir disk üç həftə əvvəl sıradan çıxmışsa, siz üç həftə ərzində deqradasiya olunmuş massivə yeni məlumat yazmağa davam edirsiniz və sonra həmin köhnə 3 həftəlik köhnəlmiş tək diski yenidən daxil edirsinizsə, sağlam aktiv disklərinizin üstünə xarici konfiqurasiyanı həmin tək köhnəlmiş diskdən idxal ETMƏYİN; əvəzinə köhnə sürücünü dəyişdirin və ya klonlayın.

2. Hardware RAID Card özü ölürsə nə etməli?¶

Əgər server anakartınız və ya PCIe hardware RAID nəzarətçi kartınız elektron xəta ilə üzləşirsə və yükləməzsə: * Siz anakartın eyni versiyasını almağa ehtiyac yoxdur və məlumatlarınız hələ də disklərdə toxunulmazdır. * eyni nəzarətçi çipset ailəsindən əvəzedici RAID nəzarətçisi alın (məsələn, hər hansı LSI/Broadcom MegaRAID SAS 2108/2208/3108 və ya Dell PERC H710/H730/H740 kartı köhnə PERC kartından DDF metadatasını oxuya bilər). * Əvəz edilmiş RAID kartını işləyən kompüterə quraşdırın, etiketlənmiş sürücülərinizi orijinal yuva sırasına uyğunlaşdırın, nəzarətçi BIOS-a yükləyin (Ctrl+R və ya Ctrl+H və ya UEFI HII menyusu) seçin və Xarici Konfiqurasiya İmport seçin. Nəzarətçi sürücülərdən RAID sxemini oxuyacaq və səsinizi dərhal quraşdıracaq.

Tez-tez verilən suallar¶

Əlaqədar təlimatlar¶

• Sərt diskin nasazlığı və məlumatların bərpası
• Təsadüfən faylın silinməsi, formatlanmış sürücü və fotoşəkillərin bərpası
• Kompüter ehtiyat nüsxələri: 3-2-1 strategiyası və fəlakətin bərpası
• Linux sisteminin yüklənmə xətası və GRUB təmiri
• Ransomware və zərərli proqramlar üçün təcili reaksiya
• Qlobal təcili yardım nömrələri

Mənbələr yoxlanılıb¶

• Linux Kernel Təşkilatı (Beynəlxalq): Linux RAID (mdadm) Wiki (raid.wiki.kernel.org), Uğursuz proqram təminatı RAID-in bərpası və Btrfs Kernel Sənədi (btrfs.readthedocs.io haqqında btrfs rescue və btrfs restore).
• OpenZFS Documentation Project (Beynəlxalq): zpool import Yalnız oxumaq üçün və Transaksiya Qrupunun Geri qaytarılması (-F -o readonly=on) İdarəetmə arayışı.
• Synology Inc. (Tayvan/Beynəlxalq): Rəsmi Synology Bilik Bazasının Məqaləsi KB-1079 (Ubuntu istifadə edərək Synology NAS nasazlığı yarandıqda məlumatları bərpa etmək üçün kompüterdən necə istifadə edə bilərəm mdadm və lvm2).
• GNU Layihəsi / Azad Proqram təminatı Fondu (Beynəlxalq): GNU ddrescue Deqradasiyaya uğramış RAID Üzv Sürücülərinin Qeyri-dağıdıcı Blok Səviyyəli Görüntüsü üçün Təlimat.
• Milli Standartlar və Texnologiya İnstitutu (NIST) (Amerika Birləşmiş Ştatları): Xüsusi Nəşr 800-86 və RAID Rebuild Exposure Windows və Düzəliş Olmayan Oxuma Xətası (URE) Ehtimalları üzrə Saxlama Etibarlılığı Rəhbərliyi.