É possível desanexar e reconectar um disco ZFS sem exigir um resilver completo?

Question

Eu tenho um pool espelhado do ZFS com quatro unidades totais. Duas das unidades destinam-se a ser usadas para a rotação de backups externos. Minha expectativa era de que, após a recuperação inicial, eu conseguisse detach e mais tarde attach um disco e fizéssemos apenas um resilver incremental - no entanto, em testes, parece executar um resilver completo independentemente de o disco estar ou não conectado contém quase todo o conteúdo da piscina.

O uso de uma abordagem offline / online me dá o resultado desejado de apenas atualizar o disco - em vez de recriá-lo totalmente? Ou, para ter esse trabalho como esperado, precisarei fazer algo totalmente diferente - como usar cada disco de backup como um pool de 1 disco e send dos instantâneos mais recentes para ele sempre que precisar ser atualizado?

    

Answer 1

Depois de mais experimentos, encontrei uma solução justa, no entanto, ela apresenta um trade-off significativo. Os discos que foram offline 'd, mas não desanexados, poderão ser colocados online novamente apenas com uma operação de resilverização incremental (" Quando um dispositivo é colocado on-line, qualquer dado que tenha sido gravado no pool é ressincronizado com o dispositivo recém-disponível. "). Em meus testes, isso reduz o tempo de resilverização de um espelho de 3 discos de 28 horas para pouco mais de 30 minutos, com cerca de 40 GB de dados-delta.

A desvantagem é que qualquer pool com um disco off-line será sinalizado como degradado. Desde que ainda haja pelo menos dois discos on-line (em um pool espelhado), isso é efetivamente uma advertência - integridade e redundância permanecem intactas.

Como outros mencionaram, essa abordagem geral está longe do ideal - o envio de instantâneos para um pool remoto seria muito mais adequado, mas no meu caso não é viável.

Para resumir, se você precisar remover um disco de um pool e adicioná-lo novamente sem precisar de um resilvering completo, a abordagem que eu recomendaria é:

• off-line do disco no pool: zpool offline pool disk
• desacelere a unidade (se for para ser fisicamente puxada): hdparm -Y /dev/thedisk
• deixe o pool em um estado degradado com a unidade off-line
• para adicionar o disco de volta ao pool: zpool online pool disk

E, como isso ainda não foi testado, existe o risco de que a operação de redimensionamento de delta não seja precisa. O pool "ao vivo" e / ou os discos off-line podem ter problemas. Vou atualizar se isso acontecer comigo, mas por enquanto vou experimentar com essa abordagem.

    

Answer 2

Não percorra o caminho da quebra do array do ZFS para "girar" discos fora do local. Como você viu, o tempo de reconstrução é alto e o processo de resilvering lerá / verificará o tamanho usado do conjunto de dados.

Se você tiver a capacidade, os instantâneos e o envio de dados para um sistema remoto será uma abordagem limpa e não invasiva. Eu suponho que você poderia passar pelo processo de ter um único conjunto de discos dedicado, copiar para ele e exportar / importar zpool ... mas não é muito elegante.

    

Answer 3

Atualização em 15 de outubro de 2015: Hoje descobri o comando zpool split , que divide um novo pool (com um novo nome) de um pool existente. split é muito mais limpo que offline e detach , já que ambos os conjuntos podem existir (e serem removidos separadamente) no mesmo sistema. O novo pool também pode estar limpo (e corretamente) export[ed] antes de ser desconectado do sistema.

(Minha postagem original segue abaixo.)

Aviso! Vários comentários nesta página indicam que é (ou pode ser) possível para zpool detach uma unidade e, em seguida, reconecta a unidade e acessa os dados nela contidos.

No entanto, de acordo com este tópico (e minha própria experimentação) zpool detach remove as "informações do conjunto" da unidade desanexada. Em outras palavras, um detach é como uma reformatação rápida da unidade . Depois que um detach de lotes de dados ainda pode estar na unidade, mas será praticamente impossível para remontar a unidade e visualizar os dados como um sistema de arquivos utilizável.

Consequentemente, parece-me que detach é mais destrutivo que destroy , pois acredito que zpool import pode recuperar pools destruídos!

Um detach é não a umount , nem a zpool export , nem a zpool offline .

Na minha experiência, se eu primeiro zpool offline de um dispositivo e, em seguida, zpool detach o mesmo dispositivo, o resto do pool esquece que o dispositivo já existiu. No entanto, como o dispositivo em si era offline[d] antes de ser detach[ed] , o dispositivo em si nunca é notificado sobre o detach . Portanto, o dispositivo em si ainda tem suas informações de pool e pode ser movido para outro sistema e, em seguida, import[ed] (em um estado degradado).

Para proteção adicional contra detach , você pode até mesmo desconectar fisicamente o dispositivo após o comando offline , ainda que antes de emitir o comando detach .

Espero usar este processo offline , depois detach e import para fazer backup do meu pool. Como o cartaz original, planejo usar quatro unidades, duas em um espelho constante e duas para backups mensais, giratórios, externos (e off-line). Vou verificar cada backup importando e depurando-o em um sistema separado, antes de transportá-lo para fora do local. Ao contrário do cartaz original, não me importo de reescrever todo o disco de backup todos os meses. De fato, eu prefiro reescrever completamente para ter pedaços novos.

    

Answer 4

Na mesma máquina, você tentou criar um novo pool com as duas unidades em um espelho? Em seguida, crie um instantâneo em seu pool de trabalho, envie esse instantâneo para o novo pool, repita e o próximo envio de instantâneo será incremental. Isso não é o mesmo com o "envio de dados para um sistema remoto", já que este é um pool dentro do mesmo sistema / servidor / máquina. Com essa configuração, você ainda pode aplicar o zpool split / offline / detach / attach, mas só o faz no segundo pool (de cópia) e não no pool de origem.