Восстановление данных после сбоев: пошаговые сценарии для ZFS, RAID и NAS

Почему восстановление данных требует сценариев, а не импровизации

Восстановление после сбоя хранилища требует последовательности проверенных шагов, а не одной команды. Для ZFS базовая цепочка выглядит так: диагностика через zpool status -v, замена отказавшего устройства командой zpool replace, ожидание resilver. Для Linux RAID: проверка через cat /proc/mdstat, добавление диска через mdadm --add, rebuild. Для NAS: восстановление файлов из снапшота, откат датасета или клонирование снимка. Если повреждены метаданные, добавляется осторожный импорт пула в режиме только для чтения.

Необратимая потеря данных редко наступает в момент отказа диска. Массив с избыточностью спокойно переживает один отказ, а вот второй шаг после него часто оказывается фатальным: администратор в спешке запускает zpool destroy, собирает новый массив поверх живого через mdadm --create или по привычке выполняет fsck на ZFS. Значительная часть необратимых потерь возникает именно так, когда причина не в железе, а в неверной команде. Сценарий ценен тем, что заранее фиксирует границы: что делать можно, что запрещено и где нужно остановиться.

Дальше разобраны четыре практических сценария: замена диска в ZFS-пуле, пересборка RAID, восстановление из снапшотов на NAS и работа с повреждёнными метаданными. Отдельно собраны опасные шаги, которые превращают деградацию в полную потерю, и описано, как тренировать восстановление до того, как придёт реальный инцидент.

Три типа сбоев: диск, массив, файловая система

Первое, что нужно сделать при инциденте, это классифицировать сбой. От типа зависит вся последовательность действий.

• Отказ диска. В dmesg появляются ошибки ввода-вывода, SMART показывает рост переназначенных секторов (атрибуты 5 и 197), а ZFS переводит устройство в состояние FAULTED или UNAVAIL в выводе zpool status. Пул при этом чаще всего остаётся DEGRADED и продолжает отдавать данные.
• Деградация массива. cat /proc/mdstat показывает строку вида md0 : active raid5 sdb1[1] sdc1[2] (2/3) [UU_], где [UU_] означает отсутствие третьего устройства, а состояние помечено как degraded. Данные доступны, избыточность уже не защищает.
• Повреждение файловой системы или метаданных. zpool status -v выводит список ошибок с именами файлов, пул может не импортироваться вовсе (pool unavailable), а zdb -C показывает расхождения в uberblock. RAID в этой ситуации не помогает, потому что проблема лежит выше уровня дисков.

Практическая разница между состояниями велика: выпавший из пула диск чинится командой zpool replace без остановки сервисов, а пул в состоянии SUSPENDED означает потерю связи с устройствами, и любая запись в него только ухудшит положение. Команда zpool destroy в этой ситуации уничтожит последние шансы на восстановление.

Что должно быть готово до инцидента

Минимальный набор, который превращает аварию в рутинную операцию:

• Актуальная схема пулов и массивов: имена vdev, тип избыточности, привязка устройств по /dev/disk/by-id, а не по коротким именам вида /dev/sdX.
• Свежие срезы вывода zpool status -v и mdadm --detail /dev/md0, сохранённые вне самого сервера.
• Резервная копия конфигурации NAS и разметки: экспорт конфигурации TrueNAS, дамп таблицы разделов (sfdisk -d), настройки HBA или RAID-контроллера.
• Доступ к IPMI, iDRAC, iLO или KVM, чтобы не ехать в дата-центр ради одного нажатия кнопки.
• Запасные диски того же класса и объёма, желательно холодный резерв, плюс два-три свободных SATA или SAS-кабеля.

Без этого списка восстановление превращается в импровизацию с высокой ценой ошибки. Проверка готовности раз в квартал занимает полчаса и напрямую связана с тренировками, о которых речь в предпоследнем разделе.

Замена диска в ZFS-пуле: пошаговый сценарий

Порядок действий для пула в состоянии DEGRADED. Все команды выполняются от root или через sudo.

1. Определите отказавшее устройство: zpool status -v покажет строку вида sda ONLINE и sdb FAULTED, а также идентификатор из /dev/disk/by-id.
2. Проверьте состояние пула целиком. Действовать можно при DEGRADED. При UNAVAIL, SUSPENDED или большом числе ошибок на втором устройстве сначала разбирайтесь с причиной.
3. Зафиксируйте вывод zpool status -v и zpool get all для пула в файл на другом сервере.
4. Замените диск физически: в сервере с hot-swap достаточно вытащить салазки, в остальных случаях потребуется остановка.
5. Подключите новый диск и выполните zpool replace с указанием пула, старого и нового устройства. Если настроен hot spare, ZFS подхватит его сам, а после установки нового диска вернёт запасное устройство в резерв командой zpool replace или zpool detach.
6. Следите за ходом через zpool status: строка resilver in progress показывает проценты и время до завершения.
7. После окончания проверьте, что ошибок нет, и запустите zpool scrub для сверки контрольных сумм. При необходимости сбросьте счётчики командой zpool clear.

Если диск отвалился из-за кабеля или контроллера и вернулся в строй, подойдёт сценарий zpool online. Resilver при этом не запускается, а избыточность восстанавливается за счёт чтения с остальных устройств пула.

Как не убить пул при замене: типичные ошибки

Resilver: что происходит и как ускорить

Resilver перестраивает на новом диске только те блоки, которые реально заняты данными, поэтому время зависит от заполнения пула, а не от заявленной ёмкости. Для HDD на 4 ТБ с заполнением около 60 процентов процесс обычно занимает от нескольких часов до суток. Пулы из зеркал восстанавливаются быстрее, чем одиночный raidz2 из восьми дисков: чем больше устройств в группе, тем дольше идёт чтение с каждого из них.

Ускорить процесс помогают два подхода. Первый: sequential resilver в OpenZFS 2.1 и новее, когда zpool replace вызывается с флагом -s, и ZFS копирует данные последовательно по диску, а не в порядке случайных блоков. На вращающихся накопителях выигрыш заметен сразу. Второй: настройка параметров ядра, где zfs_resilver_min_time_ms задаёт минимальное время, которое ZFS отдаёт resilver в каждом цикле, а zfs_resilver_delay регулирует паузу после операций ввода-вывода. Увеличение первого параметра ускоряет восстановление за счёт отзывчивости пула для клиентов.

Во время resilver производительность пула падает, иногда в разы. Тяжёлые задачи вроде ночной выгрузки бэкапов или переиндексации базы лучше перенести: они удлиняют восстановление и повышают износ деградировавшего набора.

Пересборка RAID: от диагностики до rebuild

Сценарий для программного RAID на Linux. Логика та же, что у аппаратных контроллеров, но команды заменяются на веб-интерфейс или утилиту вендора.

1. Оцените состояние: cat /proc/mdstat и mdadm --detail /dev/md0. В детализации важны строки State (clean, degraded), Active Devices, Working Devices, Failed Devices и Removed Devices.
2. Сверьте суперблоки: mdadm --examine /dev/sdb1 для каждого диска. Ищите UUID массива, Array State и Event Count. У выпавшего диска Event Count меньше, чем у остальных, так он помечается как устаревший.
3. Проверьте объём нового диска. Для массивов с общим размером по слабейшему звену диск меньшей ёмкости не примет данные, а сборка может зависнуть или отказаться добавлять устройство.
4. Замените диск физически и убедитесь, что ядро его видит: lsblk и dmesg.
5. При необходимости перенесите разметку: sgdisk -R /dev/sdNew /dev/sdOld, затем sgdisk -G /dev/sdNew для генерации новых GUID. Для массивов без разделов шаг пропускается.
6. Добавьте диск в массив: mdadm --add /dev/md0 /dev/sdX. Для замены ещё отвечающего, но больного диска используйте mdadm --replace с последующим удалением старого устройства.
7. Следите за прогрессом: cat /proc/mdstat показывает recovery с процентами и текущую скорость. При аппаратном RAID статус виден в интерфейсе контроллера.
8. После завершения проверьте State: должно быть clean, без пометки degraded или resyncing, а все устройства в mdstat отмечаются как active.

Когда RAID не пересобирается: диагностика

Типичные причины отказа сборки: повреждён суперблок одного из дисков, устройства подключены в другом порядке, объёмы не совпадают, часть дисков помечена как faulty. Диагностика начинается с mdadm --examine: команда читает суперблок и данные не меняет. Если суперблок цел, массив собирается через mdadm --assemble --scan. Если у диска устаревший Event Count, добавление через mdadm --re-add вернёт его без полной пересборки при условии, что с момента выпадения изменений было мало.

Команда mdadm --assemble --force собирает массив из дисков с разными Event Count. Она полезна, когда порядок устройств известен и подтверждён, и опасна в остальных случаях: ядро примет устаревшие данные за актуальные и перезапишет корректные блоки на остальных дисках.

Опасные шаги при работе с RAID

• mdadm --create поверх существующего массива затирает метаданные и делает данные недоступными для обычного чтения. Такую ошибку допускают, когда после сбоя загрузки массив просто не видно.
• Инициализация (initialize) на аппаратном контроллере затирает данные по всей ёмкости. Если массив уже содержит информацию, инициализацию не запускают, даже когда интерфейс предлагает её как обязательный шаг.
• Rebuild на диске с растущими ошибками SMART почти гарантированно приводит ко второму отказу и уже к потере массива целиком.
• Команда mdadm --zero-superblock и любая запись на диск, данные которого ещё могут понадобиться, снижают шансы восстановления.
• Копирование через dd с перепутанными источником и целью уничтожает данные мгновенно. Перед запуском трижды проверьте параметры if и of, а для снятия образа используйте ddrescue, который умеет обходить сбойные секторы.

Если есть сомнения в состоянии дисков, сначала снимите побайтовые образы на накопители не меньшей ёмкости и работайте с ними. Любые эксперименты по сборке массива выполняйте на копиях.

Восстановление данных из снапшотов на NAS

Снапшоты ZFS и btrfs дают самый быстрый путь вернуть данные на TrueNAS, Synology или QNAP. Логика одинакова, отличается интерфейс.

1. Посмотрите список снимков: zfs list -t snapshot или zfs list -t snapshot -r с указанием датасета для рекурсивного вывода по вложенным наборам данных.
2. Для восстановления отдельных файлов откройте скрытую директорию /mnt/пул/датасет/.zfs/snapshot/имя_снапшота/ и скопируйте нужное в рабочую директорию. Снимок смонтирован только для чтения, испортить его нельзя.
3. Для отката всего датасета выполните zfs rollback. Команда, при необходимости с флагом -r, уничтожает все изменения после снапшота, а вместе с ними и более новые снимки этого датасета.
4. Безопасная альтернатива: zfs clone с указанием снапшота и имени нового датасета. Клон занимает место только под изменённые блоки, а исходные данные остаются нетронутыми. После проверки клон можно сделать основным командой zfs promote.
5. В TrueNAS те же операции доступны через веб-интерфейс: раздел Datasets, меню снапшотов, пункты Rollback и Clone.

Rollback или clone: что выбрать

Для одного файла или папки оба метода избыточны: хватит копирования из скрытой директории .zfs. Настройка снимков по расписанию и восстановление отдельных файлов разобраны в руководстве по резервному копированию на ZFS снапшотах в TrueNAS, а полный разбор трёх сценариев возврата данных есть в гайде по восстановлению данных в TrueNAS.

Снапшоты не заменяют бэкап

Снимок лежит в том же пуле, что и данные. Потеря пула, ошибка уровня метаданных, шифрование шифровальщиком, выход из строя контроллера вместе с массивом забирают и живые данные, и снапшоты. При атаке вредоносных программ процессы нередко получают доступ к тому же пулу через скомпрометированную учётную запись NAS, и снимки становятся доступны для удаления.

Рабочая схема это правило 3-2-1-1-0: три копии, два носителя, одна копия вне офиса, один носитель офлайн, ноль ошибок верификации. Для ZFS это означает репликацию через zfs send на второй пул или в облако плюс периодическую проверку восстановления. Действия при шифровании стоит держать отдельным документом: пошаговый план при ransomware-атаке описывает изоляцию, анализ и возврат данных.

Повреждённые метаданные: диагностика и осторожное восстановление

Сценарий для случаев, когда пул не импортируется или zpool status показывает неустранимые ошибки.

1. Соберите картину: zpool status -v покажет ошибки по файлам и устройствам, а zpool import без имени пула выведет список импортируемых пулов и их состояние.
2. Оцените метаданные в режиме чтения: zdb -C показывает конфигурацию и uberblock, zdb -d выводит структуру наборов данных. Записи эти команды не выполняют.
3. Переведите работу в режим только для чтения: zpool import -o readonly=on. Это безопасный способ вытащить данные, пока вы решаете, что делать дальше.
4. Если импорт не проходит, попробуйте откат транзакций: zpool import -F. Флаг -F заставляет ZFS вернуться к более раннему uberblock и потерять последние транзакции.
5. Крайний вариант: zpool import -X, который сканирует все доступные uberblock и собирает пул из наиболее согласованной группы, теряя последние записи.
6. После любого успешного импорта сразу скопируйте важные данные наружу, не дожидаясь следующего сбоя: состояние пула остаётся нестабильным.

Перед шагами 4 и 5 снимите побайтовые образы всех дисков. Откат транзакций необратим, а попытки импорта на живых дисках записывают в метаданные пула.

zdb: что можно и что нельзя

zdb читает структуры ZFS напрямую и обходит обычные проверки, поэтому часть ключей меняет состояние пула. Безопасные операции это zdb -C и zdb -d: они дают конфигурацию и список наборов данных. Ключи, которые работают с uberblock в режиме записи или запускают проверку с исправлением, применяйте только к копии образа и только при полном понимании структуры пула.

Когда остановиться и обратиться в лабораторию

Признаки, при которых самостоятельные попытки снижают шансы на успех: пул не импортируется даже с флагом readonly, повреждено несколько дисков, zdb -C показывает ошибки в uberblock, ранее уже выполнялись zpool destroy или пересоздание пула. Если после zpool import -F и -X пул не собирается, дальнейшие эксперименты бессмысленны: каждая попытка перезаписывает метаданные. В этой точке разбор ситуации и оценка шансов на возврат данных через восстановление пересозданного пула ZFS помогут решить, есть ли смысл работать самостоятельно.

Опасные шаги, которые усугубляют потерю данных

Сводный список запрещённых и рискованных действий. Каждое из них встречалось в реальных разборах инцидентов.

Почему fsck опасен для ZFS

fsck создавался для традиционных файловых систем и ничего не знает о пулах, vdev, uberblock и контрольных суммах ZFS. Запуск на устройстве или разделе внутри пула в лучшем случае ничего не сделает, в худшем повредит метки vdev, после чего пул перестанет импортироваться. Вместо этого используют zpool status, zpool scrub и zdb.

Сторонние утилиты: когда они помогают, а когда вредят

EASEUS Data Recovery Wizard и подобные программы заявляют поддержку восстановления с NAS, RAID, HDD, SSD, USB-накопителей и карт памяти. Работают они на уровне файловых систем, разбирают ext4, NTFS, exFAT и RAW-разделы, но RAID-массив не пересобирают: если метаданные массива разрушены, утилита увидит отдельные диски, а не целостный набор данных. Полезны такие программы при ошибочном удалении или форматировании на исправном носителе.

Три ограничения, которые легко обходят вниманием. Утилиту ставят на диск, откуда уже удалены данные, и это уменьшает шансы на восстановление. В непроверенных сборках предлагают отключить антивирус перед установкой, что создаёт отдельный риск заражения. Запись на живой массив после нескольких неудачных попыток занимает блоки, в которых лежали нужные файлы. Правильный порядок: снять образ через ddrescue, открыть его в утилите и сохранить найденное на другой носитель. Из открытых инструментов держите в наборе testdisk для разбора разделов, photorec для вытаскивания файлов и ddrescue для образов.

Как встроить восстановление в систему качества хранения

Три метрики задают требования к инструментам. RPO определяет частоту снапшотов и репликации: при RPO в 15 минут расписание снимков должно быть соответствующим. RTO задаёт, сколько времени есть на восстановление, от этого зависит необходимость hot spare, второго контроллера и резервного сервера. SLA связывает оба показателя с бизнесом и снимает вопрос о допустимом простое в момент аварии.

Runbook для ZFS, RAID и NAS: что включить

• Контакты дежурных и порядок эскалации с таймаутами.
• Доступы: адреса IPMI, пароль к хранилищу, расположение ключей шифрования.
• Диагностические команды для каждого типа сбоя: zpool status -v, zdb -C, cat /proc/mdstat, mdadm --examine, проверка SMART.
• Список запрещённых команд с пояснением причины: zpool destroy, mdadm --create, fsck, dd без проверки параметров.
• Критерии остановки и передачи диска в лабораторию.
• Ссылка на схему пулов и последние снимки конфигурации.

Отдельное требование к runbook это доступность вне повреждённой системы. Электронная копия на том же NAS бесполезна, если NAS недоступен: держите печатный экземпляр, копию в корпоративной wiki и файл на отдельном сервере.

Метрики и мониторинг отказов

Что собирать и на что ставить алерты:

• SMART-атрибуты: переназначенные сектора (5), ошибки чтения (187, 197), количество секторов, ожидающих переназначения (198). Алерт на рост любого из них за 24 часа.
• Состояние пулов ZFS: переход в DEGRADED, рост ошибок cksum и write, завершение resilver, появление pool unavailable. Демон ZED отправляет события в почту и внешние системы.
• Состояние RAID: строка degraded в mdstat, счётчик Failed Devices, отсутствие запланированной проверки в журнале.
• Время resilver и rebuild как отдельная метрика: рост значения относительно прошлых запусков говорит о деградации дисковой подсистемы.
• Свободное место: пул, заполненный более чем на 80 процентов, замедляет запись и растягивает восстановление.

Для сбора подойдут Zabbix с шаблонами для ZFS и md, Prometheus с node_exporter и текстовым коллектором для вывода zpool status, smartd для локальных предупреждений. После каждого инцидента разбор отвечает на один вопрос: какая команда из runbook не сработала или отсутствовала, и документ обновляется в тот же день.

Тренировка сценариев восстановления на практике

Первый запуск процедуры в момент аварии почти всегда сопровождается ошибками. Отработка на стенде делает команды привычными и выявляет расхождения между документацией и реальностью.

1. Соберите тестовый стенд: виртуальная машина с двумя-тремя дисками под ZFS-пул, отдельная VM с mdadm и RAID5 на виртуальных или loop-устройствах.
2. Сымитируйте отказ: отключите виртуальный диск в гипервизоре (VirtualBox, VMware, Proxmox умеют это без перезагрузки) или пометьте устройство как failed командой mdadm --fail.
3. Пройдите сценарий до конца: диагностика, замена диска, zpool replace или mdadm --add, наблюдение за resilver и rebuild.
4. Сымитируйте повреждение метаданных: выведите пул через zpool export, испортите копию образа, попробуйте импорт с readonly, затем с -F и оцените результат.
5. Зафиксируйте время каждого шага, места, где пришлось лезть в документацию, и команды, которых в runbook не оказалось.
6. Восстановите стенд из снапшота или с нуля, чтобы следующий запуск начинался с чистого состояния.

Для стенда подходит и облачный сервер: аренда виртуальной машины на пару часов дешевле, чем простой продакшена. Timeweb Cloud даёт виртуальные серверы и хранилище, которые можно поднимать и удалять под каждое учение.

Как имитировать сбои без риска для продакшена

Виртуальные машины удобны тем, что отказ диска обратим: устройство отключается и подключается обратно парой кликов. Для RAID на loop-устройствах достаточно создать несколько файлов, собрать из них массив через mdadm --create и имитировать отказ через mdadm --fail с последующим --remove. Основное правило: тренировки не проводят на продакшене, даже при наличии свежих бэкапов. Имитация потери данных на живом массиве многократно увеличивает риск реальной потери. Держите стенд изолированным, без доступа к продуктивной сети.

Чек-лист для тренировки

• Цель учения и проверяемый сценарий.
• Исходное состояние стенда и его соответствие продакшену по версиям ПО.
• Ожидаемое время восстановления и фактическое.
• Критерии успеха: данные доступны, избыточность восстановлена, ошибок нет.
• Список отклонений от runbook и правки, которые нужно внести.
• Дата следующей тренировки, минимум раз в квартал.

Итог: действовать по сценарию, а не по интуиции

Ключевые действия по типам сбоев: для ZFS это zpool replace с последующим resilver и scrub, для Linux RAID это mdadm --add и rebuild с контролем через mdstat, для NAS это восстановление файлов из .zfs/snapshot или клонирование снапшота, для повреждённых метаданных это импорт в режиме readonly, затем -F и -X только после снятия образов. Опасные шаги известны: zpool destroy, mdadm --create, fsck на ZFS, dd с перепутанными параметрами, запись на живой повреждённый массив.

Краткий чек-лист при инциденте:

1. Остановитесь и не запускайте команды до диагностики.
2. Определите тип сбоя: диск, массив, файловая система.
3. Снимите вывод zpool status -v, cat /proc/mdstat и данные SMART на внешний носитель.
4. Переведите систему в режим без записи или остановите сервисы, работающие с данными.
5. Снимите побайтовые образы, если есть сомнения в состоянии дисков.
6. Действуйте по runbook и фиксируйте каждый шаг.
7. После восстановления запустите scrub, обновите документацию и назначьте тренировку.

Аварийный возврат системы после сбоя загрузчика или проблемного обновления разобран отдельно в руководстве по критическому восстановлению TrueNAS.