У меня есть две машины Linux (NixOS), которые я хотел бы использовать совместно с зашифрованным портативным жестким диском USB, отформатированным в ZFS. Я добился того, чтобы это работало нормально для одной машины, но я мог уничтожить файловую систему ZFS на диске, когда пытался смонтировать его на своей второй машине.
Перед тем, как переместить USB-накопитель с одной машины на другую, я экспортировал zpool, чтобы размонтировать его. Я надеялся, что смогу импортировать zpool с накопителя на второй машине, но, возможно, я неправильно понял концепцию zpool в ZFS. Я вообще не смог заставить свою вторую машину увидеть накопитель ZFS с помощью различных комбинаций , zpool list, zpool import -a, zpool import -Dи т. д. Накопитель определенно отображался как /dev/sdb, но автоматическое обнаружение ZFS на этой второй машине просто игнорировало его по загадочным причинам.
В конце концов я сделал простое sudo zpool create z /dev/sdb, думая, что zpool — это полностью виртуальная вещь, которую мне нужно отзеркалировать на этой машине, но я думаю, что эта команда перезаписала исходные файловые системы ZFS на этом диске без предупреждения. Теперь диск представляет собой пустую незашифрованную файловую систему, и я не уверен, возможно ли вообще восстановить с него мои данные. К счастью, у меня были резервные копии, так что это не полная потеря.
Два вопроса:
Приведет ли создание нового zpool поверх существующего vdev к необратимому уничтожению любых предыдущих файловых систем ZFS на этом устройстве?
Как можно импортировать существующий зашифрованный диск ZFS zpool с одной машины на другую, импортируя все исходные параметры конфигурации zpool, такие как сжатие, шифрование, наборы данных и т. д. Если это не так
zpool import, то что это?
решение1
Полагаю, вы ответили на свой первый вопрос с помощью своего эксперимента: да, выполнение операции zpool createпо уничтожению любого существующего пула на затронутых виртуальных устройствах.
Учитывая, что вы работаете над обеспечением совместимости между системами, с которыми вы хотите совместно использовать этот пул, я бы рекомендовал вам отказаться от шифрования до тех пор, пока вы не будете уверены в правильности механики структуры zpool и отсутствии скрытых блокировок, которые могли бы помешать успешному выполнению ваших тестов.
С учетом сказанного, одним из необходимых условий для переносимости пулов ZFS между системами является то, что блочные устройства, составляющие пул (и которые закодированы в метаданных пула), должны быть однозначными во всех системах, куда импортируется пул. Это делает неразумным использование голых физических устройств, таких как /dev/sdbи т. д. Лучше создать раздел на каждом используемом диске и назначить каждому используемому разделу уникальную метку. Серийный номер диска часто является удобной строкой для использования, поскольку он будет виден в электронном виде не только в метаданных пула, но и в выходных данных blkid, и виден человеку при осмотре шасси физического диска.
Итак, если серийный номер жесткого диска 6SL0CTD, вам следует создать раздел на этом диске и обозначить его zfs-data-6SL0CTD. Затем создайте пул, ссылающийся на это логическое устройство (вместо возможного переменного физического устройства):
# zpool create tank /dev/disk/by-partlabel/zfs-data-6SL0CTCD
Также прочитайте страницу руководства по zpool import, и обратите внимание, что существует множество неразрушающих инструментов, которые вы можете использовать, когда не уверены в том, что импортируете (или почему это не импортируется):
Без параметров:
# zpool import
показывает вам любой пул(ы), которые могут быть доступны для импорта. У меня нет тестового случая под рукой, но я думаю, что он также покажет пулы, которыене могуимпортироваться, как правило, из-за отсутствующих или неисправных устройств. Одной из причин "отсутствующего" устройства может быть то, что метаданные пула говорят, что /dev/sdb должен использоваться, но хост уже имеет /dev/sdb, и это устройство не содержит метаданных, соответствующих пулу. Опять же, вот почему важно назначать метки разделов и создавать пулы, основанные исключительно на метках разделов. Если эта метка раздела присутствует, пул будет найден, и неважно, чтофизическийустройство, на котором отображается раздел.
# zpool import -N tank
Импортирует пул tank, но не монтирует из него файловые системы. Это можно использовать как проверку пула второго уровня. Хотя ничего не монтируется, можно просмотреть статистику пула, пул может быть scrubbed и т. д.
После того, как вы правильно создали пул, в котором используются однозначные имена устройств, вы сможете понять, почему это может быть важно.
zpool status -Pпокажет полный логический путь всех устройств в пуле:
# zpool status -P
pool: tank
state: ONLINE
scan: scrub repaired 0B in 21h34m with 0 errors on Sun Oct 10 21:58:23 2021
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
/dev/disk/by-partlabel/zfs-data-6SL0CTCD ONLINE 0 0 0
errors: No known data errors
И наоборот, zpool status -LпокажетфизическийИмя устройства всех устройств в пуле:
# zpool status -L
pool: tank
state: ONLINE
scan: scrub repaired 0B in 21h34m with 0 errors on Sun Oct 10 21:58:23 2021
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
sdb1 ONLINE 0 0 0
errors: No known data errors
Конечный результат использования меток разделов вместо физических узлов устройств заключается в том, что вывод zpool status -Pбудет идентичен на всех машинах, которые импортируют пул, тогда как вывод zpool status -Lможет сильно отличаться. Что, в свою очередь, является причиной того, что zpool createкоманда должна быть написана в терминах невариантных логических устройств, которые гарантированно будут однозначными на всех машинах, которым может потребоваться импортировать пул.
После того как вы структурируете пул с точки зрения однозначных имен устройств, применение шифрования к zpool не должно вызвать затруднений, при условии, что у вас есть достаточно похожие стеки ZFS на хостах, которым необходимо импортировать пул.