Tengo dos máquinas Linux (NixOS) y me gustaría compartir un disco duro USB portátil cifrado con formato ZFS. Logré que esto funcione bien para una sola máquina, pero es posible que haya destruido el sistema de archivos ZFS en la unidad cuando intenté montarlo en mi segunda máquina.
Antes de mover la unidad USB de una máquina a otra, exporté el zpool para desmontarla. Esperaba poder importar zpool desde la unidad de la segunda máquina, pero es posible que haya entendido mal el concepto de zpool de ZFS. No pude lograr que mi segunda máquina viera la unidad ZFS con varias combinaciones de zpool list, zpool import -a, zpool import -D, etc. La unidad definitivamente aparecía como /dev/sdb, pero la detección automática de ZFS en esta segunda máquina simplemente la ignoraba por razones misteriosas.
Finalmente hice un simple sudo zpool create z /dev/sdb, pensando que zpool era algo completamente virtual que necesitaba reflejar en esta máquina, pero creo que este comando sobrescribió los sistemas de archivos ZFS originales en esta unidad sin previo aviso. La unidad ahora es un sistema de archivos vacío y no cifrado y no estoy seguro de si es posible recuperar mis datos. Afortunadamente tenía copias de seguridad, por lo que no es una pérdida total.
Dos preguntas:
¿La creación de un nuevo zpool encima de un vdev existente destruye irreversiblemente cualquier sistema de archivos ZFS anterior en ese dispositivo?
¿Cómo se puede importar una unidad ZFS cifrada existente zpool de una máquina a otra, importando todas las opciones de configuración originales de zpool, como compresión, cifrado, conjuntos de datos, etc.? Si no lo es
zpool import, ¿qué es?
Respuesta1
Supongo que ha respondido a su primera pregunta a través de su experimento: sí, golpeando zpool createcualquier grupo existente en los vdevs afectados.
Dado que está trabajando para garantizar la compatibilidad entre los sistemas con los que desea compartir este grupo, le sugiero que renuncie al cifrado hasta que esté seguro de que tiene la mecánica de la estructura de zpool correcta y que no hay bloqueos subyacentes que puedan evitar que sus pruebas tengan éxito.
Dicho esto, una de las condiciones necesarias para que los grupos ZFS sean portátiles entre sistemas es que los dispositivos de bloque que componen el grupo (y que están codificados en los metadatos del grupo) deben ser inequívocos en cualquier sistema donde se importe el grupo. Esto hace que no sea aconsejable utilizar dispositivos físicos básicos como /dev/sdb, etc. Es mejor crear una partición en cada unidad que se utilizará y asignar una etiqueta única a cada partición que se utilice. El número de serie de la unidad suele ser una cadena cómoda de usar, ya que será visible electrónicamente no sólo en los metadatos del grupo, sino también en la blkidsalida, y visible humanamente al inspeccionar el chasis físico de la unidad.
Entonces, si el número de serie del disco duro es 6SL0CTD, debes crear una partición en ese disco y etiquetarla zfs-data-6SL0CTD. Luego cree el grupo que haga referencia a ese dispositivo lógico (en lugar del dispositivo físico posiblemente variable):
# zpool create tank /dev/disk/by-partlabel/zfs-data-6SL0CTCD
Además, lea la página de manual de zpool importy tenga en cuenta que hay muchas herramientas no destructivas que puede utilizar cuando no esté seguro de lo que está importando (o por qué no se importa):
Sin parámetros:
# zpool import
le muestra los grupos que pueden estar disponibles para importar. No tengo un caso de prueba a mano, pero creo que también mostrará grupos queno puedoimportarse, normalmente debido a dispositivos faltantes o defectuosos. Una causa de un dispositivo "faltante" puede ser porque los metadatos del grupo dicen que se debe usar /dev/sdb, pero el host ya tiene un /dev/sdb y ese dispositivo no contiene metadatos que coincidan con el grupo. Nuevamente, esta es la razón por la que es importante asignar etiquetas de partición y crear grupos basados únicamente en etiquetas de partición. Si esa etiqueta de partición está presente, se encontrará el grupo y no importará quéfísicodispositivo en el que aparece esa partición.
# zpool import -N tank
Importa el grupo tankpero no monta ningún sistema de archivos desde él. Esto se puede utilizar como verificación de segundo nivel del grupo. Aunque no se monta nada, se pueden inspeccionar las estadísticas de la piscina, se puede hacer scrubcama a la piscina, etc.
Una vez que haya creado su grupo correctamente para que utilice nombres de dispositivos inequívocos, podrá ver en retrospectiva por qué esto puede ser importante.
zpool status -Pmostrará la ruta lógica completa de todos los dispositivos en el grupo:
# 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
Por el contrario, zpool status -Lmostrará elfísiconombre de dispositivo de todos los dispositivos en el grupo:
# 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
El resultado final de usar etiquetas de partición en lugar de nodos de dispositivos físicos es que la salida zpool status -Pserá idéntica en todas las máquinas que importan el grupo, mientras que la salida zpool status -Lpuede diferir. Esta es, a su vez, la razón por la que el zpool createcomando debe escribirse en términos de dispositivos lógicos no variantes que se garantiza que no serán ambiguos en todas las máquinas que puedan necesitar importar el grupo.
Una vez que haya estructurado el grupo en términos de nombres de dispositivos inequívocos, aplicar el cifrado al zpool debería ser sencillo, suponiendo que tenga pilas ZFS razonablemente similares en los hosts que necesitan poder importar el grupo.