RAID 5, RAID 6 або ZFS Multiple Drive Drop: аднаўленне пашкоджанага масіва Synology, QNAP або TrueNAS без разбурэння цотнасці¶

Праслухоўванне Synology DiskStation, QNAP TS-сервера, сервера TrueNAS або Linux mdadm сервер захоўвання бесперапынна падае гукавы сігнал, паведамляючы пра Збой тома, Пагаршаны / няспраўны пул або Некалькі дыскаў адключаны - гэта надзвычайная сітуацыя для захоўвання. Калі адзін дыск выпадае з a RAID 5, Synology Hybrid RAID (SHR-1), або ZFS RAIDZ1 пул, масіў працуе з нулявой надмернасцю (degraded стан), аднаўляючы адсутныя блокі на хаду, чытаючы кожны пакінуты дыск паралельна. Калі другі дыск адключаецца ад сеткі праз некалькі гадзін або выдае непапраўную памылку чытання (URE) на паўдарозе пасля перабудовы на дыск для замены матэматыка цотнасці парушаецца, і пул захоўвання цалкам пераходзіць у аўтаномны рэжым. У паніцы адміністратары часта знішчаюць тэрабайты дадзеных, якія можна аднавіць, на працягу наступных шасцідзесяці секунд, націскаючы Ініцыялізаваць, пераствараючы масіў з дапамогай mdadm --create, або прымусовае неадкладнае аднаўленне ў рэжыме онлайн на няспраўным абсталяванні. Калі ваша карта апаратнага RAID-кантролера памерла, а не дыскі, пераключыцеся на Смерць карты кантролера RAID, імпарт чужой канфігурацыі і чаму вы ніколі не павінны ініцыялізаваць дыскі; калі асобны жорсткі дыск пстрыкае або адмаўляецца круціцца, парайцеся збой жорсткага дыска і аднаўленне дадзеных або Масіў NAS RAID пагаршаецца, збой некалькіх дыскаў і аднаўленне ZFS/Btrfs. Калі гэты збой захоўвання адключае бальнічную медыцынскую візуалізацыю (PACS), экстранай службы або інфраструктуры бяспекі жыццядзейнасці, патэлефануйце ў мясцовы нумар службы экстранай дапамогі (911 у Злучаных Штатах і Канадзе, 112 па ўсім Еўрапейскім Саюзе, 999 у Вялікабрытаніі) або праверце наш каталог нумары экстраных службаў.

Зрабіце гэта зараз¶

1. СПЫНІЦЕ і НЕ націскайце «Ініцыялізаваць», «Стварыць пул», «Адрамантаваць» або запускаць mdadm --create на выпушчаных дысках: націснуўшы «Ініцыялізаваць» у Synology DSM або QNAP QTS або запусціўшы mdadm --create у Linux запісвае зусім новыя суперблокі і пачынае абнуляць палосы цотнасці на ўсіх дысках-членах. Выпушчаны дыск звычайна ўсё яшчэ захоўваецца 99.99% вашых файлаў некранутымі, толькі пазначанымі несінхранізаванымі лічыльнікам падзей.
2. Чыста адключыце сілкаванне NAS або сервера (або падключыце сілкаванне, калі ён актыўна перабудоўваецца на дысках, якія пстрыкаюць), каб замарозіць лічыльнікі падзей: кожную секунду масіў застаецца ў сетцы ў часткова пагоршаным стане, аперацыйная сістэма павялічвае суперблок Update Time і Events лічыльнік на ацалелых дысках, у той час як выкінуты дыск застаецца замарожаным на больш старым нумары падзеі. Калі NAS спрабуе аўтаматычна аднавіць дыск з пашкоджанымі сектарамі, працяг чытання гэтага дыска можа пазбавіць пакрыццё магнітнай пласціны (head crash).
3. Пазначце кожны слот адсека для прывада фізічным маркерам або стужкай (Bay 1, Bay 2, Bay 3, Bay 4) перш чым высунуць латок: у Linux mdadm, LVM2, і ZFS адсочваць парадак дыскаў па UUID у кожным суперблоку падзелу, старыя апаратныя кантролеры і кіраўніцтва dmsetup рэканструкцыі табліцы патрабуюць дакладнага фізічнага парадку слотаў (0, 1, 2, 3...).
4. Ніколі не спрабуйце аднавіць, прымусова сабраць або fsck непасрэдна на арыгінальных дысках удзельнікаў; кланаваць кожны дыск біт за біт з дапамогай ddrescue першы: перад запускам mdadm --assemble --force або zpool import -F, далучыце кожны дыск удзельніка да працоўнай станцыі Linux праз прамы SATA/SAS (ніколі не танны мост USB, які хавае SMART або SCT ERC тайм-аўты) і кланаваць яго з дапамогай ddrescue на здаровыя запасныя дыскі або файлы малюнкаў.
5. Прымусова сабраць кланаваны масіў строга ў рэжыме ТОЛЬКІ ЧЫТАННЕ (--readonly або -o readonly=on): Пры зборцы mdadm масівы, лічыльнікі падзей якіх разышліся падчас адначасовага падзення некалькіх дыскаў, заўсёды праходзяць --readonly (mdadm --assemble --force --readonly /dev/md0 ...). У рэжыме толькі для чытання ні тое, ні другое mdadm, LVM2, ext4, Btrfs, ні ZFS можа перазапісаць палосы цотнасці або прайграць разбуральны часопіс.
6. Скапіруйце найбольш важныя даныя на незалежны знешні дыск для рэзервовага капіравання адразу ж пасля падключэння ў рэжыме толькі для чытання: спачатку эвакуіруйце свае дакументы, базы дадзеных, віртуальныя машыны і фатаграфіі на асобны дыск, а затым ачысціце і праверце дыскі з нуля.

Дрэва рашэнняў: экстраная сартаванне RAID з некалькімі дыскамі і пул ZFS¶

Выкарыстоўвайце гэтую блок-схему, каб вызначыць, ці пацярпеў ваш масіў лагічнае падзенне часу чакання (TLER / ERC неадпаведнасць), сапраўдны збой шматдыскавага дрэннага сектара падчас перабудовы або група транзакцый ZFS (TXG) памылка:

flowchart TD
    Start["Збой RAID 5 / RAID 6 / SHR / ZFS Pool пасля адключэння 2+ дыскаў"] --> StopIO["СПЫНІЦЕ ўсе перабудовы і неадкладна выключыце NAS"]
    StopIO --> Label["Пазначце кожны латок дыскавода нумарам адсека (ад адсека 1 да адсека N)"]
    Label --> ConnectLinux["Падключыце дыскі ўдзельнікаў да Ubuntu Linux Rescue Host праз Direct SATA / HBA"]

    ConnectLinux --> CheckSmart["Праверце SMART & Metadata толькі для чытання: smartctl -a / mdadm --examine / zdb -l"]
    CheckSmart --> PhysicalHealth{"Ці націскаюць якія-небудзь дыскі, адмаўляюцца круціцца або адключаюцца ў аўтаномным рэжыме ў dmesg?"}

    PhysicalHealth -->|"Так: механічны збой/адмова галоўкі на 2+ дысках у RAID 5"| Cleanroom["СПЫНІЦЬ харчаванне дыскаў -> Адправіць у лабараторыю аднаўлення дадзеных Cleanroom"]
    PhysicalHealth -->|"Не: усе дыскі раскручваюцца (магчыма, ёсць пашкоджаныя сектары ў чаканні або паніжэнне часу чакання)"| CloneAll["Кланіраваць кожны дыск-удзельнік з дапамогай GNU ddrescue (перадача наперад -> адваротнае сканаванне)"]

    CloneAll --> DisconnectOrig["Адключыце арыгінальныя дыскі і працуйце выключна з кланаванымі дыскамі / выявамі"]
    DisconnectOrig --> ArrayType{"Якая архітэктура захоўвання дадзеных выкарыстоўваецца?"}

    ArrayType -->|"Synology DSM (SHR / Класічны RAID)"| SynologyFlow["Праверце падзеі праз mdadm --examine -> Force-Assemble Read-Only -> Activate LVM2 / Btrfs толькі для чытання"]
    ArrayType -->|"QNAP QTS (HAL LVM Thin / Thick RAID)"| QnapFlow["Збярыце mdadm толькі для чытання -> Актывуйце ўзровень DRBD, калі ён прысутнічае -> Сканіраванне карыстальніцкіх суперблокаў QNAP LVM2"]
    ArrayType -->|"TrueNAS / ZFS (RAIDZ1 / RAIDZ2 / Люстэрка)"| ZfsFlow["Запусціце zpool import -d /dev/disk/by-id -> Імпарт толькі для чытання з адкатам: zpool import -f -o readonly=on -F"]
    ArrayType -->|"Стандартны Linux mdadm"| LinuxFlow["Параўнанне лічыльнікаў падзей -> Выканаць mdadm --assemble --force --readonly -> Падключыць файлавую сістэму з -o ro,noload"]

Фаза 1: чаму прымусовая перабудоўка знішчае даныя (Каскад URE і той жа партыі)¶

Каб зразумець, чаму націск Адрамантаваць/Аднавіць або замена аднаго дыска і чаканне 36 гадзін часта прыводзіць да поўнага збою масіва, вы павінны зразумець, як рэканструкцыя цотнасці ўплывае на старэнне магнітных носьбітаў і чаму спажывецкія назапашвальнікі настольных кампутараў выпадаюць з карпусоў NAS.

1. Матэматычная рэальнасць невыпраўляемых памылак чытання (UREs) падчас перабудовы RAID 5 або RAIDZ1¶

У 4-прывадным RAID 5 або ZFS RAIDZ1 пул, дадзеныя і блокі цотнасці (P) паласатай на ўсіх чатырох дысках з дапамогай выключнага АБО (XOR) разлік (D1 XOR D2 XOR D3 = P). Калі Драйв 2 цалкам загіне, у масіве засталося нулявое рэзерваванне. Каб перабудаваць Дыск 2 на цалкам новы дыск для замены, NAS павінен прачытаць кожны сектар ад байта 0 да канца дыска на Дыску 1, Дыску 3 і Дыску 4 адначасова (Reconstructed D2 = D1 XOR D3 XOR P).

Падумайце, што адбываецца, калі гэтыя дыскі ўяўляюць сабой чатыры жорсткія дыскі па 12 тэрабайт (12 000 гігабайт), набытыя з той жа вытворчай партыі чатыры гады таму: - Перабудова 12 тэрабайт патрабуе чытання 36 terabytes (2.88 x 1014 асобныя біты) бесперапынна на працягу 24-48 гадзін пры максімальнай цеплавой і механічнай нагрузцы. - Спажывецкія жорсткія дыскі звычайна нясуць непапраўную памылку чытання (URE) спецыфікацыя 1 error in 1014 bits (12.5 terabytes), і састарэлыя дыскі ўзнікаюць бясшумныя схаваныя памылкі сектараў (Current_Pending_Sector) у халодных месцах дыска, якія не чыталіся гадамі. - У той момант, калі Дыск 3 трапляе ў адзін нечытэльны сектар памерам 4 кілабайта (0,004 мегабайта), а Дыск 2 усё яшчэ адсутнічае або напалову адноўлены, XOR ураўненне мае два невядомыя (D2 і D3).

2. Чаму настольныя дыскі без TLER / SCT ERC быць цалкам выгнаны за 1 дрэнны сектар¶

Вось пастка, якая выклікае катастрафічнае падзенне некалькіх дыскаў у Synology, QNAP і 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.                 |
+-------------------------------------------------------------------------+

Звярніце ўвагу, што насамрэч адбылося: Драйв 3 не мёртвы. Гэта мае 99.999999% здаровыя сектары і толькі 1 ці 2 нечытэльныя 4-кілабайтныя сектары (8 kilobytes з 12 terabytes). Яшчэ таму што mdadm выключыў Drive 3 з масіва з-за 30-секунднага тайм-аўту каманды, увесь том паказваецца як Збой. Калі вы кланіруеце Drive 3 з ddrescue (які вытанчана прапускае 8 кілабайт пашкоджаных сектараў і капіюе астатнія 12 тэрабайт) і прымусова сабраць масіў толькі для чытання, вы аднаўляеце практычна 100 працэнтаў вашых файлаў.

3. Чаму вы НІКОЛІ не павінны бегаць mdadm --create або націсніце «Ініцыялізаваць»¶

Калі масіў выходзіць з ладу, у інтэрнэце цыркулююць два разбуральныя міфы: - Міф 1: «Паўторна стварыце масіў з сапраўды такім жа парадкам дыскаў, выкарыстоўваючы mdadm --create" Нават з --assume-clean, сучасныя версіі mdadm па змаўчанні розныя Data Offset значэння ў залежнасці ад ядра і mdadm рэліз (2048 sectors супраць 262144 sectors). Калі mdadm --create піша новую версію 1.2 суперблок з няправільным зрушэннем або з неадпаведным памерам кавалка, ён перазапісвае LVM2 загаловак фізічнага тома або ext4 суперблок у пярэдняй частцы тома. - Міф 2: «Выцягніце другі дыск, які толькі што выпаў, падключыце яго назад і націсніце «Адрамантаваць». Калі Дыск 1 адключыўся тры дні таму (таму яго даныя састарэлыя 3 дні), а Дыск 3 адключыўся 10 хвілін таму (такім чынам, даныя актуальныя), выцягванне і паўторная ўстаўка няправільнага дыска або прымусовае аднаўленне з Дыскам 1, пазначаным як «актыўны» і Дыскам 3, пазначаным як «запасны», прымушае NAS перазапісваць абноўлены масіў на 3-дзённыя састарэлыя паласы цотнасці, якія пашкоджваюць кожны каталог і файл, зменены за апошнія 72 гадзіны.

Этап 2: Агляд суперблокаў і Event лічыльнікі бяспечна на хост выратавання Linux¶

Каб бяспечна выратаваць разбураны масіў Synology, QNAP, TrueNAS або Linux, выдаліце ўсе дыскі-члены (пасля пазначэння іх нумароў адсекаў) і падключыце іх да настольнага ПК або сервера пад кіраваннем Ubuntu 22.04 LTS / 24.04 LTS (нават загружанага з USB-назапашвальніка Live).

Крок 1: Усталюйце набор інструментаў судова-медыцынскай экспертызы ў Ubuntu¶

Адкрыйце тэрмінал на вашай выратавальнай машыне Ubuntu і ўсталюйце неабходныя ўтыліты:

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

Крок 2: Адлюструйце кожную літару дыска, серыйны нумар і схему падзелу¶

Пералічыце ўсе падлучаныя блокавыя прылады і серыйныя нумары іх абсталявання, каб ніколі не пераблытаць выратавальны дыск з зыходным дыскам NAS:

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

Паглядзіце на табліцу падзелаў тыповага дыска Synology DSM, QNAP або TrueNAS:

Крок 3: Праверце mdadm --examine каб даведацца, чаму адбыўся збой масіва (Матрыца лічыльніка падзей)¶

На Synology, QNAP або Linux mdadm масіў, вывучыце метаданыя RAID у раздзелах дадзеных карыстальніка (напрыклад, раздзел 3 на /dev/sdb3, /dev/sdc3, /dev/sdd3, /dev/sde3) без мантажу або змены нічога:

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

Параўнайце выхад на ўсіх чатырох дысках:

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

Уважліва прачытайце гэтую крыміналістычную гісторыю: 1. /dev/sdc3 (Device Role 1) мае Events кол 479012 ад два дні таму (Oct 29). Гэты дыск выпаў першым, два дні таму, і з таго часу быў па-за сеткай. 2. /dev/sdb3 (Role 0) і /dev/sde3 (Role 3) у абодвух ёсць Events : 482190 у 14:12:09. 3. /dev/sdd3 (Role 2) мае Events : 482188 у 14:12:04, усяго 5 секунд і 2 падзеі ззаду sdb3 і sde3. 4. Выснова: вы павінны аднавіць масіў з дапамогай sdb3 (Role 0), sdd3 (Role 2), і sde3 (Role 3) (чые лічыльнікі падзей знаходзяцца толькі на 2 галачкі адзін ад аднаго), у той час як сыходзіць sdc3 (Role 1) цалкам.

Фаза 3: кланаванне кожнага дыска біт за біт GNU ddrescue¶

Перад бегам mdadm --assemble --force або zpool import -F, кланаваць кожны неабходны дыск (асабліва дыск, які выпаў апошнім з-за пашкоджаных сектараў, такіх як /dev/sdd у прыведзеным вышэй прыкладзе) на здаровы пусты дыск роўнай або большай ёмістасці, або ў сыры .img файл на вялікім аб'ёме захоўвання.

Крок 1: Чаму ddrescue з файлам карты з'яўляецца абавязковым¶

Стандартны dd перапыняецца на першым дрэнным сектары, або з conv=noerror,sync марнуе гадзіны на шліфоўку галовак чытання па пашкоджанай дарожцы, адначасова запаўняючы мегабайты добрымі дадзенымі побач. GNU ddrescue працуе ў інтэлектуальных шматступеністых праходах: 1. Праход 1 (фаза капіравання): капіюе ўсе здаровыя, хутка рэагуючыя вобласці дыска на поўнай паслядоўнай хуткасці (150 MB/s каб 250 MB/s), неадкладна пераскокваючы любыя павольныя або нечытэльныя блокі, каб дыск не перагрэўся і не памёр, перш чым вы атрымаеце 99.99% добрыя дадзеныя. 2. Праход 2 (фаза абрэзкі): чытанне аж да дакладных краёў кожнага дрэннага блока як спераду, так і ззаду (reverse direction), каб ізаляваць пашкоджаную вобласць дакладна да 4-кілабайтнага апаратнага сектара. 3. Праход 3 (фаза выскрабання): асцярожна паўторна апрацоўвае пашкоджаныя сектары без скіду шыны без неабходнасці.

Крок 2: запусціце 2 этапы ddrescue каманда clone¶

Заўсёды ўказвайце файл карты (sdd_rescue.map). Калі паміраючы зыходны дыск адключаецца і патрабуе ўключэння, ddrescue счытвае файл карты і аднаўляе працу ў тым самым байце, дзе ён спыніўся, не чытаючы ніводнага ўжо скапіраванага сектара:

# 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

Этап 4: Рэканструкцыя Synology DSM (SHR-1 / SHR-2 / Класічны RAID), QNAP і Linux mdadm¶

Пасля таго, як вашы кланаваныя дыскі (або прылады цыкла толькі для чытання) будуць гатовыя і арыгінальныя дыскі NAS будуць бяспечна адключаны, выконвайце дакладную паслядоўнасць неразбуральнай зборкі для вашай платформы.

Сцэнар A: Стандартны Linux mdadm або Synology Classic RAID (RAID 5 / RAID 6)¶

1. Спыніць любы частковы md масіў, які Ubuntu магла спрабаваць запусціць:

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

2. Прымусова сабраць кланаваныя раздзелы (sdb3, sdd3, sde3, апускаючы даўно памерлых sdc3) у рэжыме строга толькі для чытання:

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

   Глядзіце выхад: mdadm будзе дакладваць forcing event count in /dev/sdd3(2) from 482188 up to 482190 і mdadm: /dev/md2 has been started with 3 drives (out of 4).
3. Пераканайцеся, што масіў актыўны і пазначаны (auto-read-only) або (read-only):

   cat /proc/mdstat
   

Сцэнар B: Synology Hybrid RAID (SHR-1 і SHR-2) з LVM2 і Btrfs / ext4¶

SHR ад Synology (Synology Hybrid RAID) гэта 100-працэнтны стандарт Linux mdadm + LVM2 (Logical Volume Manager): - Калі ўсе дыскі ў пуле SHR аднолькавага памеру (напрыклад, чатыры дыскі па 8 тэрабайт), Synology стварае адзін mdadm Падзел RAID 5 (md2 на раздзеле 3 кожнага дыска) і змяшчае an LVM2 група тамоў (vg1000 або vg1) зверху md2. - Калі дыскі ў пуле SHR маюць змешаныя памеры (напрыклад, два дыскі па 8 тэрабайт і два дыскі па 16 тэрабайт), Synology стварае два асобныя mdadm масівы: md2 праз раздзел 5 (8 TB фрагмент на ўсіх 4 дысках у RAID 5) і md3 праз Падзел 6 (астатнія 8 TB зрэз на двух дысках па 16 ТБ у RAID 1), затым злучаецца md2 + md3 у адзінае цэлае LVM2 Група тамоў (vg1000).

Каб змантаваць том Synology SHR толькі для чытання ў Ubuntu пасля прымусовай зборкі /dev/md2 (і /dev/md3 калі SHR змешанага памеру): 1. Сканаванне фізічных тамоў і груп тамоў Synology LVM2:

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

Сцэнар C: шыфраванне тамоў Synology DSM 7+ або шыфраванне агульнай тэчкі (eCryptfs)¶

• Шыфраванне агульнай тэчкі (@sharename@ папкі, якія змяшчаюць ECRYPTFS_FNEK_ENCRYPTED... імёны файлаў): Скапіруйце цалкам @encrypted_share@ тэчка выкл /mnt/synology_rescue спачатку зманціруйце і расшыфруйце яго на Ubuntu, выкарыстоўваючы пароль шыфравання Synology або .key файл:

  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+ (LUKS)**: Калі /dev/vg1000/lv паказвае TYPE="crypto_LUKS" ст blkid, разблакіруйце яго толькі для чытання з дапамогай .rkey Файл ключа аднаўлення спампаваны пры стварэнні тома:

  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
  

Сцэнар D: QNAP QTS (LVM2 Thin Provisioning і DRBD пласт)¶

Сучасныя прылады QNAP NAS (QTS 4.3+ / 5.x) устаўце ўнутраны адзіночны вузел DRBD прылада (/dev/drbd1) паміж /dev/md1 і LVM2 Група тамоў (vg1). 1. Спачатку прымусова збярыце раздзелы дадзеных QNAP (/dev/sd[b-e]3) толькі для чытання ў /dev/md1:

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

Этап 5: Выратаванне TrueNAS і Linux ZFS басейны (RAIDZ1, RAIDZ2, RAIDZ3)¶

Калі ваш сервер захоўвання дадзеных працуе пад кіраваннем TrueNAS CORE, TrueNAS SCALE, Proxmox VE або Ubuntu ZFS, аднаўленне не выкарыстоўвае mdadm. Замест гэтага ZFS аб'ядноўвае дыспетчар тамоў і капіраванне пры запісе (CoW) файлавай сістэмы ў адзіную транзакцыйную архітэктуру, пабудаваную вакол Uberblocks і паслядоўных груп транзакцый (TXGs).

Крок 1: праверце 4 цэтлікі ZFS vdev (L0, L1, L2, L3) на кожным кланаваным дыску¶

Кожны раздзел члена ZFS захоўвае чатыры аднолькавыя копіі канфігурацыі пула і масіў з апошніх 128 Uberblocks (дзве пазнакі ў пярэдняй частцы падзелу, L0 і L1і дзве этыкеткі ў самым канцы, L2 і L3). Бегчы zdb -l на кожным кланаваным раздзеле, каб праверыць стан пула і групу транзакцый з самым высокім узроўнем (txg):

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

Параўнайце txg: нумары на ўсіх кланаваных дысках. Проста як mdadm's Events Лічыльнік, калі адзін дыск выпаў з ладу за 5 хвілін да адключэння харчавання або падзення другога дыска, яго txg будзе крыху ніжэй, чым астатнія дыскі.

Крок 2: Імпартуйце пул ZFS у рэжыме толькі для чытання (-o readonly=on)¶

Спачатку праверце імпартуемыя пулы, не мантуючы нічога праз sudo zpool import -d /dev/disk/by-id. Ніколі не імпартуйце пашкоджаны пул ZFS або пул ZFS з некалькіх дыскаў у рэжыме чытання і запісу. Пры імпарце с -o readonly=on, ZFS не спрабуе ініцыяваць resilver, не піша новыя Uberblocks і не можа панікаваць ядро, калі пашкоджана карта прасторы (spacemap) сустракаецца падчас размеркавання запісу:

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

Крок 3: Калі zpool import не спраўляецца з I/O error або corrupted data, выкарыстоўвайце TXG Rollback (-F і -T)¶

Калі два дыскі выпадалі з інтэрвалам у некалькі секунд падчас інтэнсіўнай пары запісу, самая апошняя група транзакцый (TXG N) можа быць няпоўным па захаваных палосах цотнасці TXG N-1 або TXG N-2 (напісана ад 5 да 15 секунд раней) знаходзіцца на 100 працэнтаў у цэласці ўнутры кальцавога буфера Uberblock.

1. Праверце неразбуральны папярэдні прагляд адкату ў сухім рэжыме (-F -n):

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

   Калі ZFS паведамляе Would be able to return pool to its state as of <timestamp>, запусціце імпарт адкату толькі для чытання без -n:

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

2. Калі -F па-ранейшаму не магу змантаваць апошнія Uberblocks, пералічыць гістарычныя нумары Uberblock TXG zdb і імпартаваць пэўны стары TXG (-T):

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

   Выберыце а txg колькасць ад 30 да 60 секунд да аварыі (напрыклад, txg = 9481020) і імпартаваць пул, замарожаны ў гэты дакладны момант часу ў рэжыме толькі для чытання:

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

Этап 6: Праверка пасля аднаўлення і прадухіленне будучых каскадаў аднаўлення¶

Пасля таго, як вы скапіявалі 100 працэнтаў адноўленых дадзеных з /mnt/synology_rescue або /mnt/zfs_rescue на незалежную мэту рэзервовага капіявання, прытрымлівайцеся гэтага кантрольнага спісу абсталявання і канфігурацыі, перш чым зноў уключыць NAS:

• Ніколі не купляйце ўсе дыскі NAS у аднаго прадаўца ў адзін і той жа дзень: дыскі з адной і той жа вытворчай партыі выкарыстоўваюць аднолькавыя галаўныя партыі і ўбудаванае праграмнае забеспячэнне, у выніку чаго яны выходзяць з ладу на працягу некалькіх гадзін падчас перабудовы. Змяшайце партыі або вытворцы (Seagate IronWolf / Exos, WD Red Plus / Ultrastar, Toshiba N300 / MG).
• Выкарыстоўвайце толькі дыскі NAS/Enterprise з TLER / SCT ERC уключаны (або падняць Linux mdadm Тайм-аўты SCSI для настольных дыскаў): для спажывецкіх дыскаў у Linux mdadm, выкарыстоўваць a udev правіла павышаць /sys/block/sdX/device/timeout ад 30 секунд да 180 секунд так mdadm чакае перапрызначэння ўнутранага сектара замест таго, каб скідаць дыск.
• Перанесці масівы з дыскамі памерам больш за 8 TB ад RAID 5 / SHR-1 / RAIDZ1 каб RAID 6 / SHR-2 / RAIDZ2: З 12 TB каб 24 TB дыскі, час перабудовы з адной цотнасцю перавышае 30 гадзін, што робіць двайную цотнасць (RAID 6 / SHR-2 / RAIDZ2) важна, каб перажыць дрэнны сектар падчас аднаўлення срэбра.
• Графік штомесяц Data Scrubbing (mdadm check / zpool scrub) і Пашыраны SMART тэсты: штомесячная ачыстка выпраўляе схаваныя памылкі сектараў (Current_Pending_Sector), пакуль усе дыскі онлайн.
• Памятайце, што RAID - гэта высокая даступнасць, а не рэзервовае капіраванне: выконвайце інструкцыі Стратэгія рэзервовага капіравання 3-2-1 з пазасеткавай копіяй.

Рэгіянальныя нумары экстраных службаў і пратаколы агенцтваў¶

Перабоі ў сховішчы, якія ўплываюць на сетку аховы здароўя, экстраную сувязь або асабістыя запісы, патрабуюць неадкладнай эскалацыі:

• ЗША і Канада: набярыце 911 калі збой захоўвання адключае бальнічныя клінічныя сістэмы (EHR / PACS) або адпраўка. Паведаміць аб праграме-вымагальніку, арыентаванай на NAS (DeadBolt, LockBit, Akira) у CISA (1-844-Say-CISA / cisa.gov/report), ФБР IC3 (ic3.gov) або Канадскі цэнтр кібербяспекі (1-833-CYBER-88).
• Вялікабрытанія: набярыце 999 для надзвычайных сітуацый, якія ўплываюць на бяспеку жыцця або неадкладную дапамогу NHS. Згодна з GDPR Вялікабрытаніі, ацаніце, ці патрабуе пастаянная страта персанальных даных без рэзервовай копіі паведамляць ICO (0303 123 1113) на працягу 72 гадзін.
• Еўрапейскі саюз: набярыце 112 па ўсім ЕС. Суб'екты ў адпаведнасці з Дырэктывай NIS2 павінны паведамляць аб сур'ёзных збоях у працы сваёй нацыянальнай CSIRT на працягу 24 гадзін, а пастаянная страта даступнасці персанальных даных выклікае статут 33 GDPR - паведамляць на працягу 72 гадзін.
• Аўстралія і Новая Зеландыя: набярыце 000 у Аўстраліі або 111 у Новай Зеландыі; паведамляць аб інцыдэнтах інфраструктуры або праграм-вымагальнікаў NAS у ACSC (1300 CYBER1) або CERT NZ (0800 237 869).
• Індыя і Азіяцка-Ціхаакіянскі рэгіён: набярыце 112 у Індыі для рэагавання на надзвычайныя сітуацыі; паведамляць пра інцыдэнты захоўвання інфраструктуры ў CERT-In (incident@cert-in.org.in) у межах абавязковага 6-гадзіннага акна.

Часта задаюць пытанні¶

Чаму зрабіў mdadm --assemble --force адмовіцца запускаць мой масіў RAID 5 з not enough to start the array?¶

У 4-прывадным RAID 5 масіў, па меншай меры 3 з 4 дыскаў трэба перадаць mdadm --assemble --force. Бегчы sudo mdadm --вывучыць /dev/sd[a-z]3 каб праверыць, чаму трэці дыск быў адхілены: альбо вы перадалі ўвесь дыск замест падзелу (/dev/sdd замест таго, каб /dev/sdd3), яго суперблок быў пазначаны як a Запасны з-за перапыненай перабудовы, або аўтазборшчык Ubuntu заблакаваў адзін дыск у неактыўны /dev/md127 прылада (бег sudo mdadm --stop --scan спачатку, потым паўторна mdadm --assemble --force --readonly).

Што рабіць, калі дыск пачаў перабудоўвацца (Recovery = 12%) перад тым, як выпаў другі дыск?¶

Калі Drive 2 памёр, вы ўставілі новы Drive 2 і ў 12% прагрэс аднаўлення Drive 3 адключыўся ад сеткі з-за дрэннага сектара, не выкарыстоўвайце 12% перабудаваны замену Drive 2. Замест гэтага клануйце арыгінал Прывад 3 з ddrescue. Паколькі Drive 3 быў цалкам актуальным аж да таго часу, пакуль аднаўленне не спынілася на 12%, прымусовая зборка масіва толькі для чытання з выкарыстаннем Drive 1, ddrescue клон Drive 3 і Drive 4 (за выключэннем Drive 2) дае вам паслядоўны масіў.

Ці магу я змясціць свае дыскі Synology або QNAP у зусім новы шасі NAS, калі блок харчавання або плата NAS не працуюць?¶

Так, абодва Synology (Міграцыя HDD) і QNAP (Прамая міграцыя NAS) захоўваць канфігурацыю RAID на саміх дысках. аднак, калі два ці больш дыскаў ужо выпалі (`Volume Crashed`) да таго, як корпус памёр, не загружайце іх у новы корпус NAS, таму што майстар міграцыі можа перазапісаць раздзелы або выклікаць дэструктыўнае аднаўленне. Спачатку выратавайце дадзеныя толькі для чытання ў Ubuntu.

Як даведацца, ці бяспечна кланаваць выкінуты дыск ddrescue у параўнанні з неабходнасцю лабараторыі чыстых памяшканняў?¶

Падключыце дыск да SATA, уключыце яго і слухайце 10 секунд падчас прагляду sudo dmesg -w. Калі прывад выдае рытмічныя пстрычкі, скрыгат або гудзенне, раскручваецца і зноў апускаецца або паведамляе пра ёмістасць як 0 Б / 4,1 ГБ ст lsblk, галоўкі чытання/запісу выйшлі з ладу фізічна: неадкладна адключыце электрычнасць і скарыстайцеся лабараторыяй у чыстым памяшканні. Калі назапашвальнік круціцца плаўна, паказвае сваю поўную ёмістасць lsblk, і толькі лагі Бягучы_сектар_у_чаканні або памылкі тайм-аўту, клануйце яго з дапамогай ddrescue.

Што такое "дзірка для запісу RAID 5" і як гэта робіць ZFS або Btrfs пазбегнуць гэтага падчас адключэння электрычнасці?¶

У традыцыйным RAID 5 / RAID 6 без часопіса, абнаўленне паласы патрабуе запісу блока даных і блока цотнасці на два дыскі адначасова. Калі падчас запісу адключаецца харчаванне, дадзеныя і цотнасць больш не супадаюць (the Напісаць дзірку). ZFS (`RAIDZ`) і Btrfs ліквідаваць дзірку для запісу з дапамогай Copy-on-Write (`CoW`), запісваючы кожную новую паласу ў нявыкарыстаныя блокі і абнаўляючы паказальнік Uberblock/root толькі пасля таго, як поўная паласа будзе на дыску.

Ці магу я выкарыстоўваць dmsetup накладкі для праверкі параметраў RAID без змены кланаваных дыскаў?¶

Так, вы можаце стварыць Copy-on-Write (`CoW`) накладваецца на прылады цыкла толькі для чытання (`losetup --read-only`) з дапамогай Linux dmsetup (`snapshot` мэта) з падтрымкай разрэджаных файлаў у /tmp. Любы піша з mdadm --assemble --force або fsck -y перайсці ў аднаразовы /tmp файл накладання, які дазваляе скінуць налады за 1 секунду пры неабходнасці.

Звязаныя даведнікі¶

• Масіў NAS RAID пагаршаецца, збой некалькіх дыскаў і аднаўленне ZFS/Btrfs
• Смерць карты кантролера RAID, імпарт чужой канфігурацыі і чаму вы ніколі не павінны ініцыялізаваць дыскі
• Збой жорсткага дыска і аднаўленне дадзеных
• SSD і NVMe раптоўны рэжым толькі для чытання, 0% запасных блокаў і выратаванне ад адключэння TRIM
• Выпадковае rm -rf або Shift+Delete на Linux, macOS або Windows: неадкладнае паўторнае мантаванне толькі для чытання
• Рэзервовае капіраванне кампутара, стратэгія 3-2-1 і аварыйнае аднаўленне
• Нумары экстраных службаў па краінах

Крыніцы і афіцыйнае кіраўніцтва¶

• Linux Raid Wiki (raid.wiki.kernel.org) & Арганізацыя ядра Linux: Аднаўленне няўдалага праграмнага RAID (mdadm --assemble --force --readonly і неадпаведнасці лічыльніка падзей).
• Фонд свабоднага праграмнага забеспячэння (GNU Project): GNU ddrescue Кіраўніцтва: Судова-медыцынскае аднаўленне дадзеных з няспраўных носьбітаў.
• Дакументацыя OpenZFS (openzfs.github.io): Аднаўленне імпарту пула ZFS (zpool import -F, Імпарт толькі для чытання і zdb Тэхагляд).
• Synology Inc.: Цэнтр ведаў Synology: Як я магу выкарыстоўваць ПК для аднаўлення даных, калі мой Synology NAS не працуе (mdadm + LVM2 Мантаж).
• Нацыянальны інстытут стандартаў і тэхналогій (NIST) (Злучаныя Штаты): Спецыяльная публікацыя 800-209: Кіраўніцтва па бяспецы інфраструктуры захоўвання.