ZFS: enviar / receber com instantâneos contínuos

Question

Meu pequeno servidor doméstico é executado em uma distribuição com o ZFS. Nesse sistema, eu implementei um esquema de instantâneo:

• a cada hora, é criado um instantâneo
• uma vez por dia, a cadeia é desbastada para que eu tenha um conjunto de instantâneos por hora / diários / semanais / mensais

Eu gostaria de armazenar um backup externo de alguns dos sistemas de arquivos em uma unidade USB no meu escritório. O plano é atualizar a unidade a cada duas semanas. No entanto, devido ao esquema de captura instantânea, tenho problemas ao implementar instantâneos incrementais.

Para dar uma ilustração, esse é o procedimento desejado:

1. Instantâneo inicial: zfs snap tank/fs@snap0
2. Transferir instantâneo inicial: zfs send tank/fs@snap0 | zfs recv -Fduv backup_tank
3. loja backup_tank offsite
4. Faça alguns instantâneos: %código%, %código%
5. Fina a corrente: %código%
6. Retorna zfs snap tank/fs@snap1 e faz uma atualização incremental do sistema de arquivos
7. Obviamente, zfs snap tank/fs@snap2 falha, pois zfs destroy tank/fs@snap0 não existe mais em backup_tank .

Longa história curta:

Existe uma solução inteligente para combinar o desbaste de cadeias de instantâneos e% incremental dezfs send -I snap0 tank/fs@snap2 | zfs recv -Fduv backup_tank / snap0 ? Toda vez que eu conecto o drive e executo alguns comandos, eu gostaria de ter uma cópia do sistema de arquivos naquele momento. Neste exemplo, tank deve conter os instantâneos send e recv .

    

Answer 1

Você não pode fazer exatamente o que deseja.

Sempre que você criar um fluxo zfs send , esse fluxo será criado como o delta entre dois instantâneos. (Essa é a única maneira de fazer isso, pois o ZFS está atualmente implementado.) Para aplicar esse fluxo a um conjunto de dados diferente, o conjunto de dados de destino deve conter o instantâneo inicial do fluxo; se isso não acontecer, não há ponto de referência comum para os dois. Quando você destrói a captura instantânea @ snap0 no conjunto de dados de origem, cria uma situação que é impossível para o ZFS reconciliar.

A maneira de fazer o que você está pedindo é manter um instantâneo em comum entre os dois conjuntos de dados o tempo todo e usar esse instantâneo comum como ponto de partida para o próximo fluxo de envio.

Assim, você pode na etapa 1 criar um snapshot @ backup0 e, em algum momento, criar um snapshot @ backup1 para a atualização do backup off-site. Você então transfere o fluxo que é o delta entre @ backup0 e @ backup1 (que incluirá todos os instantâneos intermediários), então delete @ backup0 mas mantém @ backup1 (que se torna o novo denominador comum). Na próxima vez que atualizar o backup, você poderá criar @ backup2 (em vez de @ backup1) e transferir o delta entre @ backup1 e @ backup2 (em vez de @ backup0 e @ backup1) seguido pela exclusão @ backup1 (em vez de @ backup0) e assim por diante.

    

Answer 2

Os instantâneos têm nomes arbitrários. E zfs send -i [snapshot1] [snapshot2] pode enviar a diferença entre dois instantâneos. Você pode usar isso para ter dois (ou mais) conjuntos de instantâneos com políticas de retenção diferentes.

por exemplo. tenha um conjunto de snapshots com nomes como @snap.$timestamp (onde $timestamp é qualquer formato de data / hora para você (time_t é mais fácil de fazer cálculos, mas não é exatamente fácil de ler para humanos. @snap.%s.%Y%M%D%H%M%S fornece ambos). Seu código de exclusão de snapshots por hora / dia / semana / mês deve ignorar todos os snapshots que não começam com @snap .

O segundo conjunto, você pode chamar @offsite.$timestamp . Ele deve ter qualquer política de retenção / exclusão de snapshot que faça sentido para essa tarefa, e o código usado para gerenciá-la deve ignorar todos os snapshots que não começam com @offsite .

BTW, isso pode estar explicando o óbvio, mas você pode usar isso para seus instantâneos mensais por hora, diários e semanais, para que cada um possa ter políticas de retenção diferentes. por exemplo. @hourly.$timestamp , @daily.$timestamp etc em vez de apenas @snap.$timestamp .

Além disso, obviamente, isso usará mais espaço em disco, pois os blocos usados pelos conjuntos de dados não serão liberados até que existam instantâneos NO que os referenciem.

    

Answer 3

Você pode usar meu zfs-auto-snapshot , que é o bifurcação original zfs-auto-snapshot atualizado com o script send2remote

send2remote scans source e destination for difference são snapshots e enviam para backup zpool incremental snapshots via ssh (se backup zpool no host remoto)

zpool de backup - pode estar no host local ou remoto