ZFS: перевод диска в оперативный режим в недоступном пуле

ZFS: перевод диска в оперативный режим в недоступном пуле

У меня есть домашний сервер, использующий FreeBSD и ZFS, который отлично работал последние 5 лет, и несколько раз мне удавалось успешно заменять неисправные диски.

Однако сегодня произошла небольшая катастрофа, и я надеюсь найти решение.

У меня есть пул верхнего уровня, состоящий из 3 виртуальных устройств, каждое из которых представляет собой пул raidz1, поэтому до 3 дисков могут выйти из строя (при условии, что все они принадлежат разным виртуальным устройствам), и целостность данных останется нетронутой.

Вчера я заметил довольно много ошибок, сообщаемых 1 диском в 1 vdev. Из прошлого опыта это обычно означает, что диск скоро выйдет из строя, поэтому я делаю то, что делаю обычно:

  1. Оффлайн диск: zpool offline tank gpt/ta4
  2. Физически замените диск
  3. Настройте новый диск с помощью gpart, а затем zpool replace tank gpt/ta4

Однако на этот раз между шагами 2 и 3 случилась беда: когда я включил сервер после установки нового диска, я почувствовал запах горелого, и мой HBA показал, что4приводов не было в наличии! По невероятной случайности, должно быть, произошел скачок напряжения, потому что другой привод в том же vdev (gpt/ta2) теперь полностью мертв, а визуальный осмотр показывает, что один из MOSFET на печатной плате перегорел.

Итак, теперь gpt/ta2 НЕДОСТУПЕН, а gpt/ta4 НЕ В СЕТИ, поэтому, очевидно, vdev, которым является raidz1, также НЕДОСТУПЕН.

У меня такие вопросы: 1) Есть ли способ вернуть gpt/ta4 в онлайн? Когда я пытаюсь выполнить команду "zpool online tank gpt/ta4", он сообщает мне, что пул недоступен, поэтому я не могу этого сделать. Я могу понять, почему это может быть так, но я думал, что gpt/ta4, хотя и испытывал некоторые ошибки чтения, в основном был "хорошим" членом пула raidz1 до того, как перевести его в офлайн (статус zpool сообщил, что известных ошибок данных не было). Можно ли как-то этого добиться?

2) Если это не удастся, есть ли способ хотя бы вывести в онлайн оставшуюся часть моего пула верхнего уровня (состоящего из 3 vdev raidz1)? Остальные 2 vdev в полном порядке.

Пожалуйста, помогите, у меня много ценных данных по этому поводу :-)

Заранее спасибо.

решение1

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

/Маловероятно в высшей степени/, что любое действие, которое вы можете предпринять, вернет танк в строй. Я должен начать с этого, чтобы не усиливать ваши надежды.

1: Убедитесь, что диски в безопасности — даже если для этого придется отключить их все.

2: Обновитесь до последней версии FreeBSD — вам нужны последние версии ZFS, которые вы можете получить.

3: Поместите оригинальный gpt/ta4 (который предположительно «в порядке» и просто испытывает ошибки чтения) обратно в систему или в новую систему с более новыми битами ZFS (а также все остальные, если вы их удалили), загрузите его и запускайте по порядку, пока один из них не заработает (будьте осторожны — они небезопасны, особенно последний, поскольку при попытках восстановить систему они, скорее всего, откатятся назад и, таким образом, потеряют недавно записанные данные):

  • zpool импорт -f танк
  • zpool импорт -fF танк
  • zpool импорт -fFX танк

Если все 3 варианта не сработают, вы окажетесь за пределами области «простого» восстановления. Поиск в Google по запросам «импорт плохих пулов», «zdb», «zpool import -F», «zpool import -X», «zpool import -T» (опасность!) и т. п. может предоставить вам дополнительные блоги и информацию о попытках восстановления, предпринятых другими, но на этом этапе вы уже находитесь на очень опасной и потенциально еще более разрушительной для данных территории, и вы быстро вступаете на территорию платных услуг по восстановлению (и не от традиционных компаний по восстановлению данных, у них нулевой опыт работы с ZFS, и они не будут вам полезны).

Примечание: более точным и «безопасным» методом было бы «zpool import -o readonly=on -f -T [txg_id] tank». Однако, чтобы это сработало, вам нужно будет использовать zdb самостоятельно, для того чтобы найти, казалось бы, здоровый недавний txg_id, и я не готов пытаться объяснить все это здесь. Google будет вашим другом в этом — не предпринимайте никаких действий, пока не прочтете достаточно информации, чтобы чувствовать себя более-менее комфортно с тем, что вы делаете. Не доверяйте ни одному источнику.

Примечание 2: самым «безопасным» решением будет немедленно обратиться к человеку, способному оказать услуги по восстановлению ZFS.

Примечание 3: следующим «самым безопасным» способом будет поместить диски в безопасную систему и также dd каждого сырого диска на новый диск, что теоретически даст вам идентичные копии ваших дисков, но это будет означать, что вам понадобится такое же количество новых дисков, желательно похожего или идентичного размера/типа, как у старых, но не строго обязательно. И только затем попробуйте выполнить любое из вышеперечисленного на одном наборе дисков, отложив остальные в сторону для сохранности.

Связанный контент