RAID 5, RAID 6 или ZFS с несколькими дисками: восстановление после сбоя массива Synology, QNAP или TrueNAS без нарушения четности¶

Прослушивание Synology DiskStation, серии QNAP TS, сервера TrueNAS или Linux mdadm Сервер хранения непрерывно издает звуковой сигнал, сообщая о Сбое тома, Пул деградирован/неисправен или Отключено несколько дисков , это чрезвычайная ситуация с высоким уровнем риска для хранилища. Когда один диск выпадает из RAID 5, Synology Hybrid RAID (SHR-1), или ZFS RAIDZ1 пуле массив работает с нулевой избыточностью (degraded состояние), восстанавливая недостающие блоки на лету путем параллельного чтения каждого оставшегося диска. Если через несколько часов второй диск отключается от сети или выдает неисправимую ошибку чтения (URE) на полпути восстановления на заменяющий диск математические вычисления четности нарушаются, и пул носителей полностью отключается. В панике администраторы часто уничтожают терабайты восстанавливаемых данных в течение следующих шестидесяти секунд, нажав кнопку Инициализировать, заново создавая массив с помощью mdadm --createили принудительное немедленное онлайн-восстановление на неисправном оборудовании. Если у вас вышла из строя сама карта аппаратного RAID-контроллера, а не диски, переключитесь на Смерть карты RAID-контроллера, импорт сторонней конфигурации и почему никогда нельзя инициализировать диски; если отдельный жесткий диск щелкает или отказывается раскручиваться, обратитесь к сбой жесткого диска и восстановление данных или Деградация RAID-массива NAS, сбой нескольких дисков и восстановление 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 вышел из строя после отключения более двух дисков"] --> StopIO["ОСТАНОВИТЕ все перестройки и немедленно выключите NAS"]
    StopIO --> Label["Маркируйте каждый лоток для дисков по номеру отсека (от отсека 1 до отсека N)"]
    Label --> ConnectLinux["Подключите диски-участники к хосту восстановления Ubuntu Linux через Direct SATA/HBA"]

    ConnectLinux --> CheckSmart["Проверка SMART и метаданных только для чтения: smartctl -a / mdadm --examine / zdb -l"]
    CheckSmart --> PhysicalHealth{"Какие-либо диски щелкают, отказываются вращаться или отключаются в dmesg?"}

    PhysicalHealth -->|"Да: Механический сбой/неисправность головки на 2+ дисках в RAID 5"| Cleanroom["ОСТАНОВИТЕ включение дисков -> Отправить в лабораторию восстановления данных в чистых помещениях"]
    PhysicalHealth -->|"Нет: все диски раскручиваются (могут иметься ожидающие сбойные сектора или тайм-ауты)"| CloneAll["Клонируйте каждый диск-участник с помощью GNU ddrescue (проход вперед -> обратная очистка)"]

    CloneAll --> DisconnectOrig["Отключите оригинальные диски и работайте строго с клонированными дисками/образами"]
    DisconnectOrig --> ArrayType{"Какая архитектура хранения используется?"}

    ArrayType -->|"Synology DSM (SHR/Классический RAID)"| SynologyFlow["Проверять события через mdadm --examine -> Принудительная сборка только для чтения -> Активировать LVM2/Btrfs только для чтения"]
    ArrayType -->|"QNAP QTS (HAL LVM тонкий/толстый 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 быть полностью выкинут из-за одного плохого сектора¶

Вот ловушка, которая приводит к катастрофическим падениям нескольких дисков в 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 диск 3 исключен из массива из-за 30-секундного тайм-аута команды, весь том отображается как Сбой. Если вы клонируете Диск 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 (даже загружаемого с Live USB-накопителя).

Шаг 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 команда клонирования¶

Всегда указывайте файл карты (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 будут безопасно отключены, следуйте точной последовательности неразрушающей сборки для вашей платформы.

Сценарий А: Стандартный 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
   

Сценарий Б: 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 каждого диска) и помещает 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) файловую систему в единую транзакционную архитектуру, построенную на основе уберблоков и последовательных групп транзакций (TXGs).

Шаг 1. Проверьте 4 метки vdev ZFS (L0, L1, L2, L3) на каждом клонированном диске¶

В каждом разделе-члене ZFS хранятся четыре идентичные копии конфигурации пула и массив из последних 128 уберблоков (две метки в начале раздела, 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 в режиме чтения и записи. При импорте с -o readonly=on, ZFS не пытается инициировать ресильвер, не записывает новые 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 (-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, используйте 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 для чрезвычайных ситуаций, затрагивающих безопасность жизни или неотложную помощь Национальной службы здравоохранения. В соответствии с GDPR Великобритании оцените, требует ли безвозвратная потеря нерезервных личных данных уведомления ICO (0303 123 1113) в течение 72 часов.
• Европейский Союз: Наберите 112 по всему ЕС. Организации, в соответствии с Директивой NIS2, должны сообщать о крупных операционных сбоях в свою национальную CSIRT в течение 24 часов, а постоянная потеря доступности персональных данных приводит к срабатыванию Статьи 33 GDPR в течение 72 часов.
• Австралия и Новая Зеландия: наберите 000 в Австралии или 111 в Новой Зеландии; сообщать об инцидентах, связанных с инфраструктурой или программами-вымогателями NAS, в ACSC (1300 CYBER1) или CERT Новой Зеландии (0800 237 869).
• Индия и Азиатско-Тихоокеанский регион: наберите 112 в Индии для экстренного реагирования; сообщать об инцидентах с хранилищем инфраструктуры в CERT-In (incident@cert-in.org.in) в пределах обязательного 6-часового окна.

Часто задаваемые вопросы¶

Почему mdadm --assemble --force отказаться запускать мой массив RAID 5 с помощью not enough to start the array?¶

В 4-х приводе Рейд 5 массив, по крайней мере 3 из 4 дисков должен быть передан в mdadm --assemble --force. Беги sudo mdadm --examine /dev/sd[a-z]3 чтобы проверить, почему был отклонен третий диск: либо вы передали весь диск вместо раздела (/Дев/СДД вместо /dev/sdd3), его суперблок был помечен как Запасной из-за прерванной перестройки или автоассемблер Ubuntu заблокировал один диск в неактивном состоянии. /dev/md127 устройство (запустить sudo mdadm --stop --scan сначала, потом снова запусти mdadm --assemble --force --readonly).

Что делать, если диск начал восстанавливаться (Recovery = 12%) до того, как выпал второй диск?¶

Если диск 2 умер, вы вставили новый диск 2, и в 12% прогресс восстановления. Диск 3 отключился от сети из-за плохого сектора, не используйте 12% восстановленную замену Диска 2. Вместо этого клонируйте оригинал Драйв 3 с ddrescue. Поскольку диск 3 был полностью актуальным вплоть до остановки восстановления на уровне 12 %, принудительная сборка массива, доступного только для чтения, с использованием диска 1, ddrescue клон Диска 3 и Диска 4 (без Диска 2) дает вам согласованный массив.

Могу ли я установить диски Synology или QNAP в новый корпус NAS, если блок питания или плата NAS вышел из строя?¶

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

Как узнать, можно ли клонировать упавший диск? ddrescue вместо необходимости иметь чистую лабораторию?¶

Подключите диск к SATA, включите его и слушайте 10 секунд во время просмотра. судо dmesg -w. Если диск издает ритмичные щелчки, скрип или жужжание, раскручивается вверх и вниз или сообщает о емкости как 0 Б / 4,1 ГБ в лсблк, головки чтения/записи физически вышли из строя: немедленно отключите питание и обратитесь в лабораторию с чистым помещением. Если диск вращается плавно, показывает свою полную мощность в лсблки только логи Текущий_ожидающий_сектор или ошибки тайм-аута, клонируйте его с помощью ddrescue.

Что такое «дыра записи RAID 5» и как она ZFS или Btrfs избежать этого во время отключения электроэнергии?¶

В традиционном Рейд 5 / Рейд 6 без журнала обновление полосы требует одновременной записи блока данных и блока четности на два диска. Если во время записи происходит сбой питания, данные и четность больше не совпадают ( Написать дыру). ZFS (`RAIDZ`) и Бтрфс устраните дыру записи с помощью копирования при записи (`CoW`), записывая каждый новый страйп в неиспользуемые блоки и обновляя уберблок/корневой указатель только после того, как полный страйп окажется на диске.

Могу ли я использовать dmsetup наложения для проверки параметров RAID без изменения клонированных дисков?¶

Да, вы можете создать копирование при записи (`CoW`) накладывается поверх устройств контура только для чтения (`losetup --read-only`) с использованием Linux dmsetup (`snapshot` target), поддерживаемый редкими файлами в /tmp. Любая запись от mdadm --assemble --force или фск -у иди в одноразовый /tmp файл наложения, позволяющий при необходимости выполнить сброс за 1 секунду.

Связанные руководства¶

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

Источники и официальное руководство¶

• Linux Рейд Вики (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: Рекомендации по безопасности для инфраструктуры хранения данных.