Сбой RAID-массива, повреждение пула устройств хранения данных NAS и безопасность восстановления¶

Когда домашнее сетевое устройство хранения данных (NAS) для дома или малого бизнеса (например, Synology DiskStation, QNAP Turbo NAS, TrueNAS или сервер Unraid) начинает издавать звуковой сигнал с желтым индикатором и сообщать "Пул хранения данных поврежден" или "Сбой тома", уже следующий щелчок владельца обычно определяет, будут ли 20 терабайт незаменимых семейных фотографий и деловых записей сохранены или навсегда уничтожены. На протяжении десятилетий пользователей учили, что, когда диск в массиве RAID 5 или RAID 1 становится красным, вы просто вытаскиваете неисправный диск, вставляете совершенно новый пустой диск и нажимаете ** «Восстановить/Восстановить».**

В современных пулах хранения данных высокой емкости, состоящих из дисков емкостью от 8 до 24 ТБ, приобретенных из одной производственной партии, слепой запуск восстановления RAID на месте является причиной №1 полной и невосстановимой гибели многодискового массива. Восстановление массива RAID 5 из 4 дисков емкостью 16 ТБ заставляет каждый оставшийся устаревший диск читать 100 процентов своих секторов без остановок в течение 24-72 часов при максимальной тепловой и механической нагрузке. Когда на одном из уцелевших однородных дисков возникает неисправимая ошибка чтения (URE) или происходит деградация головки в середине процесса восстановления, RAID-контроллер выбрасывает второй диск из пула и приводит к сбою всего массива. Чтобы выжить в аварийной ситуации RAID, ZFS или Btrfs, необходимо немедленно приостановить все записи и провести аудит S.M.A.R.T. телеметрия на всех сохранившихся дисках, резервное копирование важных папок прежде изменения топологии массива и создание образов поврежденных дисков-членов с помощью GNU. ddrescue прежде чем пытаться восстановить четность или сборку метаданных только для чтения.

Сделай это сейчас¶

1. НИКОГДА не вытаскивайте несколько дисков, чтобы «переустановить» их, пока NAS или сервер включен, и НИКОГДА не меняйте местами диски, не пометив их точные номера слотов. Прежде чем прикасаться к одному лотку для дисков, возьмите маркер или приспособление для этикеток и отметьте физическую верхнюю часть каждого диска его точным номером отсека (Bay 1 / sda, Bay 2 / sdb, Bay 3 / sdc). Хотя современный Linux mdadmМассивы LVM и ZFS хранят суперблоки UUID на каждом диске, аппаратные RAID-контроллеры (Dell PERC, HP Smart Array, Broadcom/LSI MegaRAID) часто привязывают метаданные конфигурации к физическим номерам слотов объединительной платы SAS/SATA.
2. НЕ НАЖМАЙТЕ сразу «Восстановить» или «Восстановить» на устаревшем массиве RAID 5/SHR-1, если у вас нет актуальной внешней резервной копии. Пока массив с одинарной четностью (RAID 5, Synology SHR-1 или ZFS RAIDZ1) находится в режиме пониженной производительности (1 диск не работает, остальные диски подключены), все ваши файлы по-прежнему на 100 процентов доступны для чтения. Подключите внешний жесткий диск USB 3.0 непосредственно к NAS и скопируйте самые важные и незаменимые папки из поврежденного пула прежде подвергнуть уцелевшие диски жестокому 48-часовому стресс-тесту восстановления четности.
3. НИКОГДА не нажимайте «Инициализировать диск», «Создать новый пул», «Очистить конфигурацию» и не запускайте fsck -y / btrfs check --repair в сбойном массиве. Когда два диска одновременно выпадают из массива RAID 5 (часто из-за кратковременного сбоя питания или тайм-аута SATA, а не из-за фактической физической смерти), графический интерфейс NAS помечает пул носителей как "Сбой" и предлагает инициализировать или воссоздать том. Инициализация записывает новые суперблоки и нули в полосы четности, уничтожая восстанавливаемые данные. Аналогично, бег btrfs check --repair на поврежденном томе Btrfs печально известен в сообществе ядра Linux тем, что уничтожает дерево экстентов без возможности восстановления.
4. Немедленно остановите все контейнеры Docker, виртуальные машины, медиасерверы Plex, записи с камер наблюдения и запланированные операции RAID Scrubs. Каждая операция записи в поврежденный массив увеличивает риск возникновения дыры для записи четности или выхода второго диска за границу. Войдите в веб-интерфейс NAS или терминал SSH и остановите все фоновые службы и задачи с большим количеством операций ввода-вывода.
5. Если какой-либо диск в NAS издает ритмичные щелчки, стуки, скрежет или визг, немедленно выключите NAS. У щелкающего или скрежетающего диска произошел физический сбой головки чтения/записи (см. Сбой жесткого диска и восстановление данных). Если оставить его вращаться внутри корпуса NAS, магнитные пластины превратится в пыль за считанные минуты.
6. Проверьте, является ли «сбой NAS» на самом деле просто вышедшей из строя материнской платой NAS или внешним блоком питания. Если ваш Synology, QNAP или Asustor NAS внезапно вообще не включается или бесконечно мигает синим индикатором питания (как, например, знаменитая ошибка тактового сигнала Intel Atom C2000), ваши жесткие диски и данные почти наверняка в порядке на 100 процентов. Вы можете перенести эти диски в сменный NAS или смонтировать их только для чтения на любом настольном ПК с Ubuntu Linux, используя стандартные порты SATA.

flowchart TD
    A["Звуковой сигнал NAS/сообщения о RAID-массиве Состояние ухудшения качества или сбоя"] --> B{"Издают ли какие-либо приводы механические щелчки, скрежет или скрежет?"}
    B -->|"Да: Физическая травма головы"| C["Немедленно выключите NAS, пометьте каждый диск номером отсека и извлеките щелкающий диск."]
    B -->|"Нет: бесшумная работа"| D{"Каков статус пула носителей?"}
    D -->|"DEGRADED (1 диск вышел из строя, том все еще доступен для чтения)"| E["ОСТАНОВИТЕ все записи Docker/VM/Surveillance и НЕ нажимайте кнопку «Перестроить»."]
    E --> F["Проверьте S.M.A.R.T. Атрибуты (ID 5, 187, 197, 198) на всех ВЫЖИВШИХ дисках"]
    F --> G["Подключите внешний USB-накопитель и ПЕРВЫМ скопируйте важные файлы из поврежденного пула."]
    G --> H{"Есть ли на каких-либо уцелевших дисках поврежденные сектора (ID 5/197 > 0)?"}
    H -->|"Да: второй диск выходит из строя"| I["Выключите питание и клонируйте каждый диск с помощью GNU ddrescue перед попыткой восстановления."]
    H -->|"Нет: выживание означает 100% здоровье."| J["Вставьте сменный диск CMR (никогда не SMR) и запустите восстановление четности."]
    D -->|"АВАРИЯ / ОФЛАЙН (выпало несколько дисков)"| K["НЕ инициализируйте и не запускайте fsck/btrfs --repair; выключите питание и промаркируйте все отсеки для дисков"]
    C --> L["Клонируйте все поврежденные диски-члены на исправные диски с помощью GNU ddrescue + Mapfiles."]
    K --> L
    L --> M["Соберите клонированные диски в режиме «Только для чтения» с помощью Linux mdadm/LVM, zpool import -o readonly=on или UFS Explorer RAID."]

Понимание причин сбоя при восстановлении RAID: ловушки «Семейный пакет дисков» и «Диск SMR»¶

Чтобы принимать безопасные решения во время аварийной ситуации NAS, вы должны понимать две физические ловушки, которые уничтожают RAID-массивы во время восстановления:

Ловушка 1: коррелирующие сбои пакетов и неисправимые ошибки чтения (URE)¶

Большинство владельцев NAS покупают все четыре или шесть жестких дисков в один и тот же день у одного и того же продавца. Эти накопители сходят с одной и той же заводской сборочной линии, имеют одинаковые версии прошивки, вращаются в одинаковой среде вибрации шасси и набирают одинаковое количество часов работы во включенном состоянии. * Когда Привод 1 выходит из строя после 38 000 часов работы, Приводы 2, 3 и 4 также изнашиваются через 38 000 часов. * Если вы вставите новый сменный диск в отсек 1 и нажмете Перестроить в массиве RAID 5, контроллер NAS должен прочитать каждый сектор на дисках 2, 3 и 4, чтобы вычислить с помощью XOR недостающие блоки четности для отсека 1. * Если на диске 3 скрыто 14 нечитаемых поврежденных секторов (Текущие ожидающие секторы, S.M.A.R.T. ID 197) в старой папке, которую вы не открывали в течение двух лет, процесс восстановления врезается в эти поврежденные сектора в 19-м часу. На многих аппаратных картах RAID и старых ядрах NAS без SCT Error Recovery Control (TLER) одно-многосекундное ожидание чтения приводит к тому, что контроллер помечает диск. 3 как «Failed/Faulted», что приводит к удалению второго диска из массива RAID 5 с одинарной четностью и сбою всего тома.

Ловушка 2: никогда не вставляйте диск SMR (с галькой магнитной записи) в массив RAID или ZFS.¶

При покупке жесткого диска для экстренной замены в местном магазине электроники для восстановления вашего NAS убедитесь, что новый диск использует CMR (обычную магнитную запись), НИКОГДА не SMR (послойную магнитную запись). * Бюджетные жесткие диски для настольных ПК (например, стандартные Western Digital Red не Plus) EFAX модели от 2 ТБ до 6 ТБ, настольные накопители Seagate Barracuda Compute и многие дешевые внешние USB-накопители, которые пользователи «вытаскивают» из пластиковых корпусов) используют Drive-Managed SMR, где магнитные дорожки перекрываются, как черепица на крыше. * Во время продолжительной многотерабайтной записи RAID или ZFS внутренний кэш носителя SMR полностью заполняется в течение 30 минут. После заполнения кэша диск SMR зависает на от 10 до 30+ секунд при внутреннем чтении и перезаписи целых сегментированных полос или возвращает ATA. IDNF (Sector ID Not Found) тайм-аут. * Линукс mdadm, Synology DSM и особенно ZFS (zed) интерпретируют эти 20-секундные остановки SMR как неисправный жесткий диск, выбрасывающий новый сменный диск обратно из массива в середине восстановления. Всегда покупайте диски CMR NAS/Enterprise (например, WD Red Plus / WD Red Pro, Seagate IronWolf / IronWolf Pro / Exos или Toshiba N300 / MG Enterprise).

Диагностическая матрица: уровни RAID, отказоустойчивость и правила выживания.¶

Пошаговая сортировка «деградированного» пула NAS (1 диск вышел из строя, данные все еще доступны)¶

Если ваш NAS подает звуковой сигнал из-за сбоя 1 диска в пуле RAID 1, RAID 5, SHR-1, RAID 6 или RAIDZ, перед заменой диска выполните следующую последовательность действий:

Шаг 1. Аудит S.M.A.R.T. сначала атрибуты на всех ВЫЖИВАЮЩИХ дисках¶

Откройте Диспетчер хранилища -> Жесткий диск/SSD -> Информация о состоянии -> S.M.A.R.T. Атрибут (на Synology/QNAP) или запустите smartctl -a /dev/sdX через SSH на каждом работоспособном/подключенном диске, оставшемся в пуле. Посмотрите на RAW_VALUE столбец для этих четырех критических атрибутов: * Идентификатор 5 (Reallocated_Sector_Ct): В идеале должно быть 0. Если уцелевший диск имеет десятки или сотни перераспределенных секторов, поверхность его диска или головки активно деградируют. * ID 187 (Reported_Uncorrect): Должно быть 0. * ID 197 (Current_Pending_Sector): КРИТИЧЕСКИЙ. Любое число, превышающее 0 означает, что уцелевший диск в настоящее время имеет нечитаемые сектора, ожидающие сбоя в тот момент, когда восстановление RAID пытается их прочитать. * ID 198 (Offline_Uncorrectable): Должно быть 0.

Правило принятия решения: * Если на всех сохранившихся дисках отображается 0 с идентификаторами 5, 187, 197 и 198 вы можете безопасно создать резервную копию важных папок на внешнем USB-накопителе, а затем приступить к обычному графическому интерфейсу NAS Восстановление/восстановление с использованием исправного сменного диска CMR. * Если на любом сохранившемся диске в пуле RAID 5/SHR-1/RAIDZ1 с одинарной четностью отображается Current_Pending_Sector > 0 или эскалация Reallocated_Sector_Ct, НЕ ЗАПУСКАЙТЕ ПЕРЕСТРОЙКУ. Немедленно скопируйте все данные с поврежденного NAS на внешние USB-накопители, пока том еще смонтирован; если том уже неисправен, выключите NAS и клонируйте неисправные диски-члены на ПК с Linux с помощью GNU. ddrescue сначала.

Пошаговое спасение при «сбое» тома RAID/NAS (выпадание нескольких дисков)¶

Что, если вы проснетесь и обнаружите, что ваше сетевое хранилище RAID 5 с 4 отсеками сообщает "Пул хранения данных 1: сбой", потому что диск 2 вышел из строя во вторник вечером, а диск 4 вышел из строя в среду утром?

Почему большинство «сбоев двух дисков» на самом деле можно устранить: Если в ваш дом не ударила молния или NAS не упал с лестницы, два механических жестких диска почти никогда не страдают от катастрофических поломок головок в одну и ту же секунду. Вместо этого то, что на самом деле произошло, является последовательным: 1. Диск 2 обнаружил несколько поврежденных секторов и был исключен из массива несколькими днями или часами ранее (массив остался работать в деградированном режиме на дисках 1, 3 и 4). 2. Позже Диск 4 обнаружил один нечитаемый сектор (или короткий тайм-аут SATA), когда NAS выполнял фоновую очистку. Поскольку массив больше не имел избыточности для исправления единственного поврежденного сектора на диске 4, драйвер RAID исключил и диск 4 и пометил весь пул как Сбой.

В этом сценарии Диск 4 имеет самый свежий и актуальный счетчик событий рейдов (Events count) и исправен на 99,9999%, тогда как Диск 2 немного устарел («устаревший»).

Как восстановить поврежденный Synology, QNAP или Linux mdadm безопасный массив на ПК с Linux¶

Шаг 1. Выключите NAS, промаркируйте каждый отсек для дисков и подключите диски к настольному ПК под управлением Ubuntu Linux Live USB.¶

1. Выключите NAS. Пометьте каждый диск (Bay 1, Bay 2, Bay 3, Bay 4).
2. Подключите диски к портам SATA материнской платы (или к карте HBA, такой как LSI 9211-8i/9300-8i в режиме IT; избегайте дешевых USB-концентраторов, которые отключаются под нагрузкой) на настольном ПК, загруженном в Ubuntu Linux Live USB.
3. Откройте терминал и проверьте структуру разделов и mdadm суперблоки строго в диагностическом режиме только для чтения:

# 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

Шаг 2: Прочтите Events счетчик и Array State вывод из mdadm --examine¶

Посмотрите внимательно на вывод sudo mdadm --examine /dev/sd[a-d]3 для каждого диска: * Вы увидите такие строки: * /dev/sda3: Events : 48210, Array State : A.AA (A = Активный, . = Отсутствует) * /dev/sdb3 (Диск 2, выпал первым): Events : 47950, Array State : AAAA * /dev/sdc3: Events : 48210, Array State : A.AA * /dev/sdd3 (Диск 4, выпал последним): Events : 48209, Array State : A.AA * Обратите внимание, что Events счетчик сообщит вам: Диски 1, 3 и 4 (sda3, sdc3, sdd3) находятся в пределах 1 события друг от друга (48210 против 48209), а Диск 2 (sdb3) выпал намного раньше на мероприятии 47950. * Важное правило: В массиве RAID 5 с 4 дисками вам понадобится всего 3 диска для восстановления 100 процентов данных. Вы ДОЛЖНЫ собрать массив, используя 3 самых свежих диска (sda3, sdc3и sdd3) и ** оставьте устаревший диск (sdb3)**. Если вы случайно выполните принудительную сборку с использованием старого устаревшего диска (sdb3), метаданные файловой системы двухдневной давности не будут соответствовать текущим полосам данных на других дисках и повредят ваши папки.

Шаг 3. Клонируйте любой диск с поврежденными секторами с помощью GNU. ddrescue первый¶

Перед сборкой клонируйте недавно выпавший диск (/dev/sdd) (и в идеале все входящие в него диски) на исправный сменный диск, используя ddrescue (см. Сбой жесткого диска и восстановление данных для полного ddrescue синтаксис):

# 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

Теперь отключите оригинал, который не работает. /dev/sdd и положите его на полку, чтобы работать со здоровым клоном (/dev/sde).

Шаг 4. Соберите RAID-массив, группу томов LVM и файловую систему в строгом режиме ТОЛЬКО ДЛЯ ЧТЕНИЯ.¶

В системах Synology (SHR/RAID) и QNAP стек хранения данных имеет до трех уровней: mdadm (РЕЙД) -> LVM2 (Диспетчер логических томов) -> ext4 или Btrfs (Файловая система). Вот точная последовательность команд для их безопасного монтирования в режиме только для чтения в 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

Однажды /mnt/nas_rescue монтируется, все ваши общие папки NAS (photo, homes, video, documents) появится внутри /mnt/nas_rescue/ поэтому вы можете скопировать их прямо на внешний USB-накопитель для резервного копирования.

• Что, если на вашем Synology NAS имеется «Synology Hybrid RAID (SHR)» с дисками разных размеров? Synology SHR просто разбивает диски большего размера на несколько разделов (sda5, sda6) и создает отдельный mdadm массив на каждом уровне разделов, а затем объединяет их md массивы вместе внутри одной группы томов LVM (vg1000). Бег sudo mdadm --assemble --scan --readonly и sudo vgchange -ay автоматически объединяет многоуровневые тома SHR в Ubuntu.
• Альтернативный коммерческий графический интерфейс пользователя (Windows/macOS/Linux): Если вам неудобно использовать команды терминала Linux или у вас сложный пул LVM с тонким выделением QNAP, UFS Explorer RAID Recovery или ReclaiMe Free RAID Recovery могут проверить все подключенные NAS-диски на ПК с Windows или Linux в программном режиме 100% только для чтения, автоматически определить размер полосы, поворот четности и смещения LVM, а также скопировать ваши папки. без изменения ни одного сектора на дисках NAS.

ЗФС (zpool) и команды аварийного спасения Btrfs¶

Современные платформы NAS (тома TrueNAS SCALE/CORE, Proxmox, Ubuntu Server, Unraid и Synology Btrfs) все чаще используют файловые системы копирования при записи (CoW) вместо устаревших. ext4. Если ZFS zpool или Пул Btrfs отказывается монтироваться или вызывает панику ядра при загрузке после отключения питания или сбоя диска. обычное монтирование не удастся, поскольку ОС пытается воспроизвести поврежденные транзакции записи. Вы должны использовать параметры отката транзакции, доступные только для чтения.

1. ЗФС (zpool) Аварийное восстановление (TrueNAS/Proxmox/Linux ZFS)¶

Если в пуле ZFS указано FAULTED, UNAVAIL, или происходит сбой сервера (паника ядра) в тот момент, когда вы пытаетесь его импортировать после нечистого отключения питания:

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

После установки под /mnt/zfs_rescueскопируйте свои наборы данных, используя rsync или zfs send прежде чем пытаться импортировать пул для чтения и записи.

2. Аварийное восстановление Btrfs (Synology Btrfs/Unraid Cache Pool/Linux Btrfs)¶

Вместо этого попробуйте смонтировать или извлечь том Btrfs в строгом прогрессивном порядке, от наименее инвазивного к самому глубокому сканированию:

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

Аварийные ситуации с аппаратным RAID-контроллером: «чужая конфигурация» и неработающие RAID-карты¶

Корпоративные серверы (Dell PowerEdge с картами PERC, HPE ProLiant с Smart Array, Lenovo ThinkSystem или рабочие станции с контроллерами Broadcom/LSI MegaRAID) используют аппаратные карты RAID со встроенным NVRAM и кэшем батареи/суперконденсатора (BBU / CacheVault).

1. Импорт внешней конфигурации вместо чистой конфигурации (КРИТИЧНО)¶

Когда диск на мгновение отключается или вы перемещаете диски в сменный серверный корпус, экран загрузки Dell PERC или LSI MegaRAID BIOS приостанавливается и сообщает: "На адаптере обнаружены внешние конфигурации". * ВСЕГДА выбирайте Import Foreign Configuration (или Preview Foreign Configuration -> Import). Тег «Внешний» просто означает, что RAID-контроллер видит действующие существующие метаданные RAID, записанные на самих жестких дисках (сектора конфигурации Disk Data Format / DDF или LSI в конце дисков), которые отличаются от текущего состояния NVRAM карты. При импорте макет массива считывается прямо с дисков и возвращает ваш виртуальный диск в режим онлайн без потери ни одного байта. * НИКОГДА не выбирайте Clear Foreign Configuration или Initialize Virtual Disk. Очистка или инициализация стирает метаданные массива или обнуляет диски. * Предупреждение об исключении: Если один диск вышел из строя три недели назад, вы продолжали записывать новые данные в поврежденный массив в течение трех недель, а затем снова подключаете этот старый одиночный диск, устаревший 3 недели назад, НЕ импортируйте внешнюю конфигурацию с этого единственного устаревшего диска поверх исправных активных дисков; вместо этого замените или клонируйте устаревший диск.

2. Что делать, если сама аппаратная RAID-карта выйдет из строя?¶

Если на материнской плате вашего сервера или аппаратной плате RAID-контроллера PCIe произошел электронный сбой, и она не загружается: * Вам НЕ нужно покупать точно такую же версию материнской платы, и ваши данные на дисках останутся нетронутыми. * Приобретите сменный RAID-контроллер из того же семейства чипсетов контроллеров (например, любая карта LSI/Broadcom MegaRAID SAS 2108/2208/3108 или Dell PERC H710/H730/H740 может считывать метаданные DDF со старой карты PERC). * Установите сменную карту RAID в работающий компьютер, подключите промаркированные диски в исходном порядке отсеков, загрузитесь в BIOS контроллера (Ctrl+R или Ctrl+H или меню UEFI HII) и выберите Импортировать внешнюю конфигурацию. Контроллер прочитает структуру RAID с дисков и немедленно смонтирует ваш том.

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

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

• Сбой жесткого диска и восстановление данных
• Случайное удаление файлов, форматирование диска и восстановление фотографий
• Резервное копирование компьютеров: стратегия 3-2-1 и аварийное восстановление
• Ошибка загрузки системы Linux и восстановление GRUB
• Чрезвычайное реагирование на программы-вымогатели и вредоносное ПО
• Глобальные номера экстренных служб

Источники проверены¶

• Организация ядра Linux (международная): Linux RAID (mdadm) Вики (raid.wiki.kernel.org), Восстановление неисправного программного RAID и документация по ядру Btrfs (btrfs.readthedocs.io на btrfs rescue и btrfs restore).
• Проект документации OpenZFS (международный): zpool import Только чтение и откат группы транзакций (-F -o readonly=on) Справка администрации.
• Synology Inc. (Тайвань/Международное): официальная статья базы знаний Synology KB-1079 (Как я могу использовать компьютер для восстановления данных, если мой Synology NAS работает со сбоями при использовании Ubuntu mdadm и lvm2).
• Проект GNU / Фонд свободного программного обеспечения (международный): GNU ddrescue Руководство по неразрушающему созданию изображений на уровне блоков поврежденных дисков-членов RAID.
• Национальный институт стандартов и технологий (NIST) (США): специальная публикация 800-86 и руководство по надежности хранения данных по окнам воздействия восстановления RAID и вероятности неисправимых ошибок чтения (URE).