Tenho duas máquinas Linux (NixOS) que gostaria de compartilhar um disco rígido USB portátil criptografado e formatado em ZFS. Consegui que isso funcionasse bem para uma única máquina, mas posso ter destruído o sistema de arquivos ZFS na unidade quando tentei montá-lo na minha segunda máquina.
Antes de mover o drive USB de uma máquina para outra, exportei o zpool para desmontá-lo. Eu esperava poder importar o zpool da unidade na segunda máquina, mas posso ter entendido mal o conceito de zpool do ZFS. Não consegui fazer com que minha segunda máquina visse a unidade ZFS com várias combinações de zpool list, zpool import -a, zpool import -D, etc. A unidade definitivamente estava aparecendo como /dev/sdb, mas a detecção automática do ZFS nesta segunda máquina estava simplesmente ignorando-a por razões misteriosas.
Eventualmente eu fiz um simples sudo zpool create z /dev/sdb, pensando que o zpool era algo totalmente virtual que eu precisava espelhar nesta máquina, mas acho que esse comando substituiu os sistemas de arquivos ZFS originais nesta unidade sem nenhum aviso. A unidade agora é um sistema de arquivos vazio e não criptografado e não tenho certeza se é possível recuperar meus dados dele. Felizmente, tive backups, então não é uma perda total.
Duas questões:
A criação de um novo zpool sobre um vdev existente destrói irreversivelmente qualquer sistema de arquivos ZFS anterior nesse dispositivo?
Como importar um zpool de unidade ZFS criptografado existente de uma máquina para outra, importando todas as opções de configuração originais do zpool, como compactação, criptografia, conjuntos de dados, etc.? Se não for
zpool import, o que é?
Responder1
Presumo que você tenha respondido à sua primeira pergunta por meio de seu experimento: sim, destruir zpool createqualquer pool existente nos vdevs afetados.
Dado que você está trabalhando para garantir a compatibilidade entre os sistemas que deseja compartilhar neste pool, sugiro que você renuncie à criptografia até ter certeza de que a mecânica da estrutura do zpool está correta e que não há bloqueios subjacentes que possam evitar que seus testes sejam bem-sucedidos.
Dito isso, uma das condições necessárias para que os pools ZFS sejam portáveis entre sistemas é que os dispositivos de bloco que compõem o pool (e que são codificados nos metadados do pool) sejam inequívocos em todos os sistemas para os quais o pool será importado. Isso torna imprudente o uso de dispositivos físicos simples, como /dev/sdb, etc. Melhor é criar uma partição em cada unidade a ser usada e atribuir um rótulo exclusivo a cada partição usada. O número de série da unidade costuma ser uma sequência conveniente de usar, pois será eletronicamente visível não apenas nos metadados do pool, mas também na blkidsaída, e humanamente visível após a inspeção do chassi físico da unidade.
Portanto, se o número de série do disco rígido for 6SL0CTD, você deverá criar uma partição nessa unidade e rotulá-la como zfs-data-6SL0CTD. Em seguida, crie o pool referenciando esse dispositivo lógico (em vez do dispositivo físico possivelmente variável):
# zpool create tank /dev/disk/by-partlabel/zfs-data-6SL0CTCD
Além disso, leia a página de manual do zpool import, e observe que há muitas ferramentas não destrutivas que você pode usar quando não tiver certeza do que está importando (ou por que não será importado):
Sem parâmetros:
# zpool import
mostra todos os pools que podem estar disponíveis para importação. Não tenho um caso de teste em mãos, mas acredito que também mostrará pools quenão podeser importados, normalmente devido a dispositivos ausentes ou com falha. Uma causa de um dispositivo "ausente" pode ser porque os metadados do pool dizem que /dev/sdb deve ser usado, mas o host já possui um /dev/sdb e esse dispositivo não contém metadados correspondentes ao pool. Novamente, é por isso que é importante atribuir rótulos de partição e criar pools baseados apenas em rótulos de partição. Se esse rótulo de partição estiver presente, o pool será encontrado e não importará o quefísicodispositivo em que a partição aparece.
# zpool import -N tank
Importa o pool tank, mas não monta nenhum sistema de arquivos a partir dele. Isso pode ser usado como uma verificação de segundo nível do pool. Embora nada esteja montado, as estatísticas do pool podem ser inspecionadas, o pool pode ser scrubcama, etc.
Depois de criar seu pool corretamente para usar nomes de dispositivos inequívocos, você poderá ver retrospectivamente por que isso pode ser importante.
zpool status -Pmostrará o caminho lógico completo de todos os dispositivos no pool:
# 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 outro lado, zpool status -Lmostrará ofísiconome do dispositivo de todos os dispositivos no pool:
# 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
O resultado final do uso de rótulos de partição em vez de nós de dispositivos físicos é que a saída de zpool status -Pserá idêntica em todas as máquinas que importam o pool, enquanto a saída zpool status -Lpode ser diferente. É por isso que o zpool createcomando precisa ser escrito em termos de dispositivos lógicos não variantes, que são garantidos como inequívocos em todas as máquinas que possam precisar importar o pool.
Depois de estruturar o pool em termos de nomes de dispositivos inequívocos, a aplicação da criptografia ao zpool deve ser simples, supondo que você tenha pilhas ZFS razoavelmente semelhantes nos hosts que precisam ser capazes de importar o pool.