SUNW. Иногда случается…

… что ZFS-пул собран без какой-либо redundancy… Ну что же делать в случае, если диск “осыпался”, fmdump -eV полон ошибок – а данные (как всегда – считанные килобайты) нужны позарез, как всегда после перезагрузки? Простое решение – ниже. Никаких fsck, никаких проверок диска – ничего не нужно делать, в первую очередь нужно дать поработать ZFS.

Для начала остановиться и дать команду:

 [ host ~ ] # zpool import -N -F -f -o readonly=on -R /SSC/a 4467832246593190342 rpoolSSC
Pool rpool returned to its state as of Thu Jul 18 13:49:16 2013.
Discarded approximately 5 minutes of transactions.
 [ host ~ ] #

Опция -F импортирует (попытается!) проблемный пул. Опция -N – не даст замонтировать доступные ФС (я предпочитаю дальше двигаться через zfs mount, просматривая нужные мне точки монтирования).

Больше никакого dd, никаких сложных поисков и пересчетов. Можно добавить опцию -n – на “осыпающемся” в процессе диске я бы это использовать не стал – проверка самой возможности восстановления.

Надо быть морально готовым к тому, что время импорта может быть весьма немаленьким (если импорт вообще случиться). Потом даем полезную команду zpool status -xv rpoolSSC – смотрим на перманентно поврежденные файлы. Не забываем мониторить fmdump -eV – контролируем накат ошибок.

Копируем нужные файлы, диск – направляем в р-н мусорного ведра или на магнитики. В следующий раз покупаем в два раза больше дисков (перевожу – 2 штуки как минимум, зеркало – это минимум, на котором стоит вообще запускаться). Для статических неспешных файлопомоек вполне съедобен RAIDZ, для длительного хранения – RAIDZ2, хоть и слабо оправдан. Много места теряется? Включаем компрессию или включаем дедупликацию – и не забываем при этом, что опции dedup+compression совместно ничего, кроме дополнительных тормозов – не дают. Как выбрать верную стратегию? В принципе, есть эстиматоры, оценщики, но они довольно ограничены в применении – по опыту все довольно прозаично – пробовать и оценивать.

Leave a Reply