Восстановление ZFS из состояния сбоя пула

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

Мне удалось получить другую машину от друга, чтобы восстановить систему, но в процессе переноса дисков мне пришлось несколько раз менять местами их кабели, пока я не получил правильную конфигурацию, в которой оставшиеся 5 исправных дисков были видны как онлайн. Этот процесс, похоже, вызвал некоторые ошибки контрольной суммы для пула/raidz.

Сейчас у меня установлены оставшиеся 5 дисков и установлен хороший диск, готовый занять место вышедшего из строя. Однако, поскольку состояние моего пула FAULTED (ошибочное), я не могу выполнить замену.

root@zfs:~# zpool replace tank 1298243857915644462 /dev/sdb
cannot open 'tank': pool is unavailable

Есть ли способ исправить эту ошибку? Я бы подумал, что наличие 5 из 6 дисков в сети было бы достаточно, чтобы восстановить правильные данные, но сейчас этого, похоже, недостаточно.

Вот журнал состояния моего пула:

root@zfs:~# zpool status tank
  pool: tank
 state: FAULTED
status: One or more devices could not be used because the label is missing or invalid.
        There are insufficient replicas for the pool to continue functioning.
action: Destroy and re-create the pool from a backup source.
   see: http://zfsonlinux.org/msg/ZFS-8000-5E
  scan: none requested
config:

    NAME                     STATE     READ WRITE CKSUM
    tank                     FAULTED      0     0     1  corrupted data
      raidz1-0               ONLINE       0     0     8
        sdd                  ONLINE       0     0     0
        sdf                  ONLINE       0     0     0
        sdh                  ONLINE       0     0     0
        1298243857915644462  UNAVAIL      0     0     0  was /dev/sdb1
        sde                  ONLINE       0     0     0
        sdg                  ONLINE       0     0     0

Обновление (10/31): Я пытался экспортировать и повторно импортировать массив несколько раз за последнюю неделю, но неудачно. Сначала я попробовал:

zpool import -f -R /tank -N -o readonly=on -F tank

Это сразу вызвало такую ошибку:

cannot import 'tank': I/O error
       Destroy and re-create the pool from a backup source.

Я добавил опцию ‘-X’ к выше указанной команде, чтобы попытаться проверить журнал транзакций. Я дал этому работать около 48 часов, прежде чем сдаться, потому что это полностью заблокировало мой компьютер (я не мог войти в систему ни локально, ни через сеть).

Теперь я пробую простую команду zpool import tank, и она, похоже, работает какое-то время без вывода. Я оставлю ее работать на ночь, чтобы увидеть, появится ли что-то в выводе.

Обновление (11/1): zpool import tank выполняется уже около 12 часов без какого-либо вывода на командной строке. Однако мой компьютер все еще откликается, и это хорошо.

В основном нет официального способа восстановления, кроме восстановления из резервной копии.
Но есть функция ZFS под названием rewind, которая может удалить транзакции
из пула до момента, когда пул снова станет функциональным.
Следующий текст взят из блога ZFS Internals часть #11

НЕ ИСПОЛЬЗУЙТЕ ЭТО В ПРОИЗВОДСТВЕ. ИСПОЛЬЗУЙТЕ НА СВОЙ СТРАХ И РИСК!

zpool import -FX mypool где опции означают:
* -F Попытка отката, если необходимо.
* -X Включить экстремальный откат.
* -T Указание начального txg для импорта. Эта опция намеренно не документирована и предназначена для тестирования.

Сначала я попытался восстановиться с помощью этой процедуры отката. Она не сработала для меня, возможно, это не реализовано в zfs-fuse для Linux.
Согласно ZFSOnDiskFormat.pdf, существует массив с 128 возможными значениями для txg.
В моей версии zfs-fuse 0.7.0 опция -T не существует. Поэтому я изменил zfs-fuse, чтобы он перечислял доступные txg в массиве uberblock и позволял начинать с txg с определенным идентификатором. Используя измененный zfs-fuse, я смог получить доступ к файловым системам в ZFS.

Я восстановил свой пул, используя этот метод. Поэтому восстановление возможно, но это неподдерживаемый метод, и его следует выполнять очень осторожно, так как можно еще больше ухудшить ситуацию.
Мое мнение, Sun/Oracle должны предоставить fsck для ZFS для таких ситуаций.

Кстати, в надежде помочь кому-то в будущем:

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

Я бы порекомендовал использовать другую схему наименования, как это гораздо лучше описано в FAQ по ZFS на Linux. Для моего небольшого пула я перешел на /dev/disk/by-id/. Это очень просто изменить схему на существующем пуле, если это необходимо.