RAID Array Failure, ødelagt NAS Storage Pool, og Rebuild Safety¶

Når en hjemme- eller en liten bedrift Network Attached Storage (NAS)-enhet (for eksempel en Synology DiskStation, QNAP Turbo NAS, TrueNAS eller Unraid-server) begynner å pipe med en gul LED og rapporterer "Storage Pool Degraded" eller "Volum Crashed," eierens aller neste klikk avgjør om det er mulig å ta bilder av familien eller ikke. er lagret eller permanent ødelagt. I flere tiår har brukere blitt lært at når en stasjon i et RAID 5- eller RAID 1-array blir rødt, trekker du ganske enkelt den døde stasjonen ut, skyver en helt ny tom stasjon inn og klikker "Reparer / Rebuild."

I moderne lagringsbassenger med høy kapasitet bygget med 8 TB til 24 TB stasjoner kjøpt fra samme produksjonsgruppe, blindet å starte en RAID-gjenoppbygging på stedet er #1 årsak til total, uopprettelig dødsfall for flere stasjoner. Gjenoppbygging av en 4-stasjons 16 TB RAID 5-array tvinger hver gjenværende aldrende stasjon til å lese 100 prosent av sektorene sine non-stop i 24 til 72 timer ved maksimal termisk og mekanisk belastning. Når en av de overlevende søskenstasjonene treffer en ukorrigerbar lesefeil (URE) eller lider av hodedegradering halvveis gjennom gjenoppbyggingen, sparker RAID-kontrolleren den andre stasjonen ut av bassenget og krasjer hele arrayen. Å overleve en RAID-, ZFS- eller Btrfs-nødsituasjon krever at alle skrivinger settes på pause umiddelbart, og S.M.A.R.T. telemetri på tvers av alle overlevende stasjoner, sikkerhetskopiering av kritiske mapper før berøring av array-topologien, og avbildning av degraderte medlemsdisker med GNU ddrescue før du noen gang forsøkte en paritetsgjenoppbygging eller skrivebeskyttet metadatasammenstilling.

Gjør dette nå¶

1. ** Trekk ALDRI ut flere stasjoner for å "plassere dem på nytt" mens NAS-en eller serveren er slått på, og ALDRI bytt stasjoner uten å merke deres eksakte spornummer.** Før du berører en enkelt stasjonsskuff, ta en Sharpie eller merkemaskin og merk den fysiske toppen av hver stasjon med dets nøyaktige plassnummer (Bay 1 / sda, Bay 2 / sdb, Bay 3 / sdc). Selv om det er moderne Linux mdadm, LVM og ZFS-matriser lagrer UUID-superblokker på hver disk, maskinvare-RAID-kontrollere (Dell PERC, HP Smart Array, Broadcom/LSI MegaRAID) binder ofte konfigurasjonsmetadata til fysiske SAS/SATA-bakplanspornumre.
2. IKKE umiddelbart klikk på "Reparer" eller "Rebuild" på en degradert RAID 5 / SHR-1-array hvis du ikke har en oppdatert ekstern sikkerhetskopi. Mens en single-parity-array (RAID 5, Synology SHR-1 eller ZFS RAIDZ1) er i Degradert modus (1 stasjon døde på nettet), kan fortsatt leses 0 prosent av filene dine på nettet. akkurat nå. Plugg en ekstern USB 3.0-harddisk direkte inn i NAS-en og kopier de mest kritiske, uerstattelige mappene dine fra det degraderte bassenget før du utsetter de overlevende stasjonene for den brutale 48-timers stresstesten av en paritetsgjenoppbygging.
3. ** Klikk ALDRI "Initialiser disk", "Opprett ny gruppe", "Slett konfigurasjon" eller kjør fsck -y / btrfs check --repair på et krasjet array.** Når to stasjoner faller ut av en RAID 5-array samtidig (ofte på grunn av en kort strømforsyningsdip eller SATA-tidsavbrudd i stedet for ekte fysisk død), vil NAS GUI merke Storage Pool som "Crashed" og tilby å initialisere eller gjenskape volumet. Initialisering skriver ferske superblokker og nuller over paritetsstripene, og ødelegger gjenopprettbare data. På samme måte løper btrfs check --repair på et ødelagt Btrfs-volum er beryktet i Linux-kjernefellesskapet for å ødelegge utstrekningstreet utenfor gjenoppretting.
4. Stopp alle Docker-beholdere, virtuelle maskiner, Plex-medieservere, overvåkingskameraopptak og planlagte RAID-scrubs umiddelbart. Hver skriveoperasjon til en degradert array øker risikoen for et paritetsskrivehull eller å skyve en marginal andre stasjon over kanten. Logg inn på NAS-nettgrensesnittet eller SSH-terminalen og stopp alle bakgrunnstjenester og høy-I/O-oppgaver.
5. Hvis en stasjon i NAS-en lager rytmiske klikke-, banke-, slipe- eller skriklyder, slå av NAS-en rent nå. En klikkende eller slipende stasjon har fått et fysisk lese-/skrivehodekrasj (se Harddiskfeil og datagjenoppretting). Hvis du lar den snurre inne i NAS-kabinettet, vil de magnetiske platene bli til støv i løpet av minutter.
6. Sjekk om "NAS-feilen" faktisk bare er et dødt NAS-hovedkort eller ekstern strømkloss. Hvis Synology-, QNAP- eller Asustor-NAS-en din plutselig ikke vil slå seg på i det hele tatt, eller blinker den blå strøm-LED-en uendelig (for eksempel den berømte Intel Atom C2000-klokkesignalfeilen), harddiskene dine og dataene dine er nesten helt i orden 100 prosent. Du kan migrere disse stasjonene til en erstatnings-NAS eller montere dem skrivebeskyttet på en hvilken som helst Ubuntu Linux-stasjonær PC ved å bruke standard SATA-porter.

flowchart TD
    A["NAS-piping / RAID-array rapporterer degradert eller krasj-status"] --> B{"Er det noen stasjoner som lager mekanisk klikk-, slipe- eller skrapelyder?"}
    B -->|"Ja: Fysisk hodekrasj"| C["Slå av NAS-en umiddelbart, merk hver stasjon med sitt plassnummer, og fjern den klikkende stasjonen"]
    B -->|"Nei: Stillegående drift"| D{"Hva er Storage Pool-statusen?"}
    D -->|"DEGRADERET (1 stasjon mislyktes, volumet fortsatt lesbart)"| E["STOPP all Docker/VM/Surveillance-skriving og IKKE klikk på Gjenoppbygg ennå"]
    E --> F["Sjekk S.M.A.R.T. Attributter (ID 5, 187, 197, 198) på alle SURVIVING-stasjoner"]
    F --> G["Koble til ekstern USB-stasjon og kopier kritiske filer fra det degraderte bassenget FØRST"]
    G --> H{"Viser noen overlevende stasjoner dårlige sektorer (ID 5 / 197 > 0)?"}
    H -->|"Ja: Andre stasjon svikter"| I["Slå av og klon hver stasjon med GNU ddrescue før du forsøker noen gjenoppbygging"]
    H -->|"Nei: Å overleve driver 100 % sunt"| J["Sett inn en ny CMR-stasjon (aldri SMR) og kjør parity Rebuild"]
    D -->|"KRASHET / OFFLINE (flere stasjoner falt ut)"| K["IKKE initialiser eller kjør fsck/btrfs --repair; slå av og merk alle stasjonsbrønner"]
    C --> L["Klon alle degraderte medlemsstasjonene til sunne stasjoner ved å bruke GNU ddrescue + mapfiler"]
    K --> L
    L --> M["Sett sammen klonede stasjoner i skrivebeskyttet modus via Linux mdadm/LVM, zpool import -o readonly=on eller UFS Explorer RAID"]

Forstå hvorfor RAID-gjenoppbygging mislykkes: "Sibling Drive Batch" og "SMR Drive" feller¶

For å ta sikre avgjørelser under en NAS-nødsituasjon, må du forstå de to fysiske fellene som dreper RAID-arrayer under gjenoppretting:

Felle 1: Korrelert batchfeil og ukorrigerbare lesefeil (URE)¶

De fleste NAS-eiere kjøper alle fire eller seks harddiskene på samme dag fra samme forhandler. Disse stasjonene kommer fra samme fabrikkmonteringslinje, deler identiske fastvarerevisjoner, spinner i nøyaktig samme chassisvibrasjonsmiljø og akkumulerer nøyaktig samme antall oppstartstimer. * Når Drive 1 dør etter 38 000 timers drift, har Drives 2, 3 og 4 også 38 000 timers slitasje. * Hvis du setter en ny erstatningsstasjon inn i stasjon 1 og klikker på Rebuild på en RAID 5-array, må NAS-kontrolleren lese hver enkelt sektor på tvers av stasjoner 2, 3 og 4 for å XOR-beregne de manglende paritetsblokkene for bay 1. * Hvis stasjon 3 i det stille har huset 14 uleselige dårlige sektorer (Current Pending Sectors, S.M.A.R.T. ID 197) i en gammel mappe du ikke har åpnet på to år, vil gjenoppbyggingsprosessen slå med hodet først inn i de dårlige sektorene ved time 19. På mange maskinvare-RAID-kort og gamle RAID-kontroller, en enkel SCTLER-kontroller (Errorer) flersekunders lesestopp får kontrolleren til å merke Drive 3 som "Failed/Faulted," og slippe en andre stasjon ut av en enkeltparitets RAID 5-array og krasjer hele volumet.

Felle 2: Sett aldri inn en SMR-stasjon (Shingled Magnetic Recording) i en RAID- eller ZFS-array¶

Når du kjøper en nødharddisk i en lokal elektronikkbutikk for å gjenoppbygge NAS-en din, kontroller at erstatningsdisken bruker CMR (Conventional Magnetic Recording), ALDRI SMR (Shingled Magnetic Recording). * Budsjett stasjonære harddisker (som standard Western Digital Red ikke-Plus EFAX modeller fra 2 TB til 6 TB, Seagate Barracuda Compute-stasjonære stasjoner og mange billige eksterne USB-stasjoner som brukere "kaster" ut av plastdeksler) bruker Drive-Managed SMR, der magnetiske spor overlapper hverandre som takshingel. * Under en vedvarende multi-terabyte RAID eller ZFS resilver-skriving, fylles en SMR-stasjons interne mediebuffer helt opp innen 30 minutter. Når hurtigbufferen er full, stopper SMR-stasjonen i 10 til 30+ sekunder mens den internt leser og omskriver hele shingled-bånd, eller returnerer en ATA IDNF (Sector ID Not Found) tidsavbrudd. * Linux mdadm, Synology DSM, og spesielt ZFS (zed) tolker disse 20-sekunders SMR-stoppene som en død harddisk, sparker den splitter nye erstatningsdisken rett tilbake ut av arrayet midt i gjenoppbyggingen. Kjøp alltid CMR NAS/Enterprise-stasjoner (som WD Red Plus / WD Red Pro, Seagate IronWolf / IronWolf Pro / Exos eller Toshiba N300 / MG Enterprise).

Diagnostisk matrise: RAID-nivåer, feiltoleranse og overlevelsesregler¶

Trinn-for-trinn triage for en "degradert" NAS-pool (1 stasjon mislyktes, data fortsatt tilgjengelig)¶

Hvis NAS-en din piper fordi 1 stasjon i en RAID 1-, RAID 5-, SHR-1-, RAID 6- eller RAIDZ-pool har feilet, følg denne nøyaktige sekvensen før du bytter ut disken:

Trinn 1: Revisjon S.M.A.R.T. attributter på alle SURVIVING-stasjoner først¶

Åpne Storage Manager -> HDD/SSD -> Health Info -> S.M.A.R.T. Attributt (på Synology/QNAP) eller kjør smartctl -a /dev/sdX via SSH på hver sunn/online kjøretur som fortsatt er igjen i bassenget. Se på RAW_VALUE kolonne for disse fire kritiske attributtene: * ID 5 (Reallocated_Sector_Ct): Må ideelt sett være 0. Hvis en overlevende stasjon har dusinvis eller hundrevis av omfordelte sektorer, er tallerkenoverflaten eller hodene aktivt nedverdigende. * ID 187 (Reported_Uncorrect): Må være 0. * ID 197 (Current_Pending_Sector): KRITISK. Et hvilket som helst tall større enn 0 betyr at overlevende stasjon for øyeblikket har ulesbare sektorer som venter på å forårsake et krasj i det øyeblikket en RAID-gjenoppbygging prøver å lese dem. * ID 198 (Offline_Uncorrectable): Må være 0.

Beslutningsregel: * Hvis alle overlevende stasjoner viser 0 på ID-ene 5, 187, 197 og 198 kan du trygt sikkerhetskopiere dine kritiske mapper til en ekstern USB-stasjon og deretter fortsette med en vanlig NAS GUI Reparer / Gjenoppbygg ved å bruke en sunn CMR-erstatningsstasjon. * Hvis en hvilken som helst overlevende stasjon i en RAID 5/SHR-1/RAIDZ1-pool med én paritet viser Current_Pending_Sector > 0 eller eskalerende Reallocated_Sector_Ct, IKKE KJØR EN OMBYGGING. Kopier alle data fra den degraderte NAS-en til eksterne USB-stasjoner umiddelbart mens volumet fortsatt er montert; hvis volumet allerede sliter, slår du av NAS-en og kloner de sviktende medlemsstasjonene på en Linux-PC med GNU ddrescue først.

Trinn-for-trinn redning når et RAID/NAS-volum "krasjer" (flere stasjoner falt ut)¶

Hva om du våkner og din 4-bay RAID 5 NAS sier "Storage Pool 1: Crashed" fordi Drive 2 mislyktes tirsdag kveld og Drive 4 falt ut onsdag morgen?

Hvorfor de fleste "2-stasjonsfeil" faktisk kan gjenopprettes: Med mindre huset ditt ble truffet av lynet eller NAS-en ble falt ned en trapp, vil to mekaniske harddisker nesten aldri lide totalt katastrofale hodekrasj i nøyaktig samme sekund. I stedet er det som faktisk skjedde sekvensielt: 1. Drive 2 utviklet noen få dårlige sektorer og ble kastet ut av arrayet dager eller timer tidligere (og la arrayet kjøre i degradert modus på stasjoner 1, 3 og 4). 2. Senere møtte Drive 4 én enkelt uleselig sektor (eller en kort SATA-timeout) mens NAS-en kjørte en bakgrunnsskrubb. Fordi arrayet ikke lenger hadde redundans for å fikse den eneste dårlige sektoren på Drive 4, sparket RAID-driveren også Drive 4 ut og markerte hele bassenget Crashed.

I dette scenariet har Drive 4 den ferskeste, oppdaterte raid-hendelsetelleren (Events teller) og er 99,9999 % frisk, mens Drive 2 er litt utdatert ("foreldet").

Hvordan gjenopprette en krasjet Synology, QNAP eller Linux mdadm array trygt på en Linux-PC¶

Trinn 1: Slå av NAS-en, merk hver stasjonsbrønn og koble stasjonene til en stasjonær PC som kjører Ubuntu Linux Live USB¶

1. Slå av NAS-en. Merk hver stasjon (Bay 1, Bay 2, Bay 3, Bay 4).
2. Koble stasjonene til hovedkortets SATA-porter (eller et HBA-kort som en LSI 9211-8i/9300-8i i IT-modus; unngå billige USB-huber som kobles fra under belastning) på en stasjonær PC som er startet opp i en Ubuntu Linux Live USB.
3. Åpne en terminal og inspiser partisjonsoppsettet og mdadm superblokker strengt i skrivebeskyttet diagnostisk modus:

# 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

Trinn 2: Les Events teller og Array State utgang fra mdadm --examine¶

Se nøye på utgangen av sudo mdadm --examine /dev/sd[a-d]3 for hver stasjon: * Du vil se linjer som: * /dev/sda3: Events : 48210, Array State : A.AA (A = Aktiv, . = mangler) * /dev/sdb3 (Kjøring 2, droppet ut først): Events : 47950, Array State : AAAA * /dev/sdc3: Events : 48210, Array State : A.AA * /dev/sdd3 (Kjøring 4, droppet ut sist): Events : 48209, Array State : A.AA * Legg merke til hva Events telleren forteller deg: Stasjoner 1, 3 og 4 (sda3, sdc3, sdd3) er innenfor 1 hendelse fra hverandre (48210 vs 48209), mens Drive 2 (sdb3) falt ut mye tidligere under arrangementet 47950. * Kritisk regel: I en 4-stasjons RAID 5-array trenger du bare 3 stasjoner for å rekonstruere 100 prosent av dataene. Du MÅ sette sammen arrayet ved å bruke de 3 ferskeste stasjonene (sda3, sdc3, og sdd3) og utelat den foreldede stasjonen (sdb3). Hvis du ved et uhell tvangsmontere med den gamle foreldede stasjonen (sdb3), vil filsystemets metadata fra to dager siden ikke samsvare med gjeldende datastriper på de andre stasjonene og ødelegge mappene dine.

Trinn 3: Klon enhver stasjon med dårlige sektorer ved å bruke GNU ddrescue først¶

Før du monterer, klone den nylig tapte stasjonen (/dev/sdd) (og ideelt sett alle medlemsstasjoner) til en sunn erstatningsstasjon ved hjelp av ddrescue (se Harddiskfeil og datagjenoppretting for fullt ddrescue syntaks):

# 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

Koble nå fra originalen som feiler /dev/sdd og legg den trygt på en hylle slik at du jobber med den sunne klonen (/dev/sde).

Trinn 4: Sett sammen RAID-arrayet, LVM-volumgruppen og filsystemet på nytt i streng KUN-modus¶

På Synology (SHR / RAID) og QNAP-systemer har lagringsstakken opptil tre lag: mdadm (RAID) -> LVM2 (Logisk volumbehandler) -> ext4 eller Btrfs (Filsystem). Her er den nøyaktige kommandosekvensen for å montere dem trygt i skrivebeskyttet modus på 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

En gang /mnt/nas_rescue monterer, alle dine delte NAS-mapper (photo, homes, video, documents) vises på innsiden /mnt/nas_rescue/ slik at du kan kopiere dem rett til en ekstern USB-sikkerhetskopieringsstasjon.

• Hva om din Synology NAS hadde "Synology Hybrid RAID (SHR)" med blandede stasjonsstørrelser? Synology SHR deler ganske enkelt større stasjoner i flere partisjoner (sda5, sda6) og oppretter en separat mdadm array på tvers av hvert partisjonsnivå, og føyer seg deretter sammen md arrays sammen inne i en enkelt LVM volumgruppe (vg1000). Løper sudo mdadm --assemble --scan --readonly og sudo vgchange -ay syr automatisk flerlags SHR-volumer sammen igjen på Ubuntu.
• Kommersielt GUI-alternativ (Windows/macOS/Linux): Hvis du er ukomfortabel med Linux-terminalkommandoer eller har en kompleks QNAP-tynt-provisionert LVM-pool, kan UFS Explorer RAID Recovery eller ReclaiMe Free RAID Recovery inspisere alle tilkoblede NAS-stasjoner på en Windows- eller Linux-modus, les automatisk i 100% av programvarestørrelsen. rotasjon og LVM-forskyvninger, og kopier mappene dine ut uten å endre en enkelt sektor på NAS-stasjonene.

ZFS (zpool) og Btrfs nødredningskommandoer¶

Moderne NAS-plattformer (TrueNAS SCALE/CORE, Proxmox, Ubuntu Server, Unraid og Synology Btrfs-volumer) bruker i økende grad kopier-på-skriv (CoW) filsystemer i stedet for eldre ext4. Hvis en ZFS zpool eller Btrfs pool nekter å montere eller forårsaker kjernepanikk ved oppstart etter strømbrudd eller stasjonsfeil, normal montering vil mislykkes fordi operativsystemet prøver å spille av skadede skrivetransaksjoner. Du må bruke skrivebeskyttede tilbakestillingsparametere for transaksjoner.

1. ZFS (zpool) Nødgjenoppretting (TrueNAS / Proxmox / Linux ZFS)¶

Hvis en ZFS-pool sier FAULTED, UNAVAIL, eller krasjer serveren (kjernepanikk) i det øyeblikket du prøver å importere den etter et urent strømbrudd:

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

En gang montert under /mnt/zfs_rescue, kopier datasettene dine av med rsync eller zfs send før du noen gang prøver å importere bassenget lese-skrive.

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

Prøv i stedet å montere eller trekke ut Btrfs-volumet i strengt progressiv rekkefølge, fra minst invasiv til dypeste skanning:

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

Nødsituasjoner med maskinvare RAID-kontroller: "Foreign Configuration" og døde RAID-kort¶

Enterprise-servere (Dell PowerEdge med PERC-kort, HPE ProLiant med Smart Array, Lenovo ThinkSystem eller arbeidsstasjoner med Broadcom/LSI MegaRAID-kontrollere) bruker maskinvare-RAID-kort med innebygd NVRAM og batteri-/superkondensatorbuffer (BBU / CacheVault).

1. Importer utenlandsk konfigurasjon kontra slett konfigurasjon (KRITISK)¶

Når en stasjon kobles fra et øyeblikk eller du flytter stasjoner inn i et erstatningsserverchassis, vil Dell PERC- eller LSI MegaRAID BIOS-oppstartsskjermen settes på pause og kunngjøre: "Utenlandske konfigurasjon(er) funnet på adapteren." * Velg ALLTID Import Foreign Configuration (eller Preview Foreign Configuration -> Import). "Foreign"-taggen betyr ganske enkelt at RAID-kontrolleren ser gyldige eksisterende RAID-metadata skrevet på selve harddiskene (Disk Data Format / DDF eller LSI-konfigurasjonssektorene på slutten av stasjonene) som er forskjellig fra kortets nåværende NVRAM-tilstand. Importering leser array-oppsettet rett fra stasjonene og bringer den virtuelle disken din online igjen uten å miste en eneste byte. * ** Velg ALDRI Clear Foreign Configuration eller Initialize Virtual Disk.** Sletting eller initialisering sletter array-metadataene eller nulstiller stasjonene. * Unntaksadvarsel: Hvis en enkelt stasjon falt ut for tre uker siden, fortsatte du å skrive nye data til det degraderte arrayet i tre uker, og deretter kobler du den gamle 3-ukers gamle enkeltstasjonen inn igjen, Ikke importer den utenlandske konfigurasjonen fra den gamle stasjonen over de sunne aktive stasjonene dine; i stedet erstatte eller klone den foreldede stasjonen.

2. Hva hvis selve maskinvare-RAID-kortet dør?¶

Hvis serverens hovedkort eller PCIe-maskinvare RAID-kontrollerkortet har en elektronisk feil og ikke vil starte: * Du trenger IKKE å kjøpe nøyaktig samme revisjon av hovedkortet, og dataene dine er fortsatt intakte på stasjonene. * Kjøp en erstatnings RAID-kontroller fra samme kontrollerebrikkesettfamilie (for eksempel kan et hvilket som helst LSI/Broadcom MegaRAID SAS 2108/2208/3108 eller Dell PERC H710/H730/H740-kort lese DDF-metadata fra et eldre PERC-kort). * Installer det nye RAID-kortet i en fungerende PC, koble til de merkede stasjonene i den opprinnelige rekkefølgen, start opp i kontrollerens BIOS (Ctrl+R eller Ctrl+H eller UEFI HII-menyen), og velg Importer utenlandsk konfigurasjon. Kontrolleren vil lese RAID-oppsettet fra stasjonene og montere volumet umiddelbart.

Ofte stilte spørsmål¶

Relaterte guider¶

• Harddiskfeil og datagjenoppretting
• Utilsiktet sletting av filer, formatert stasjon og bildegjenoppretting
• Datasikkerhetskopiering: 3-2-1 strategi og katastrofegjenoppretting
• Linux-systemoppstartsfeil og GRUB-reparasjon
• Ransomware og skadelig nødhjelp
• Globale nødnumre

Kilder sjekket¶

• Linux-kjerneorganisasjon (internasjonal): Linux RAID (mdadm) Wiki (raid.wiki.kernel.org), Gjenoppretting av en mislykket programvare-RAID og Btrfs-kjernedokumentasjon (btrfs.readthedocs.io på btrfs rescue og btrfs restore).
• OpenZFS Documentation Project (internasjonalt): zpool import Skrivebeskyttet og tilbakerulling av transaksjonsgruppe (-F -o readonly=on) Administrasjonsreferanse.
• Synology Inc. (Taiwan/Internasjonalt): Offisiell Synology Knowledge Base-artikkel KB-1079 (Hvordan kan jeg bruke en PC til å gjenopprette data når Synology NAS-en min fungerer feil ved bruk av Ubuntu mdadm og lvm2).
• GNU Project / Free Software Foundation (internasjonalt): GNU ddrescue Håndbok for ikke-destruktiv bildebehandling på blokknivå av degraderte RAID-medlemsdisker.
• National Institute of Standards and Technology (NIST) (USA): Spesialpublikasjon 800-86 og lagringspålitelighetsveiledning om RAID Rebuild Exposure Windows and Uncorrectable Read Error (URE) Probabilities.