Isenção de responsabilidade: como nunca usei zvols, não posso dizer se eles são diferentes na replicação do que os sistemas de arquivos ou instantâneos normais. Suponho que sim, mas não aceite minha palavra.
Sua pergunta é realmente várias perguntas, tento respondê-las separadamente:
Como replicar / espelhar o pool completo para um local remoto
Você precisa dividir a tarefa em duas partes: primeiro, a replicação inicial precisa estar completa; depois, a replicação incremental é possível, desde que você não mexa nos seus instantâneos de replicação . Para habilitar a replicação incremental, é necessário preservar os últimos instantâneos de replicação, tudo antes que possa ser excluído. Se você excluir o instantâneo anterior, zfs recvirá reclamar e abortar a replicação. Nesse caso, você precisa começar tudo de novo, portanto, tente não fazer isso.
Se você só precisa das opções corretas, elas são:
zfs send:
-R: envie tudo sob o conjunto ou conjunto de dados fornecido (a replicação recursiva, necessária o tempo todo, inclui -p). Além disso, ao receber, todos os instantâneos de origem excluídos são excluídos no destino.-I: inclua todos os instantâneos intermediários entre o último instantâneo de replicação e o instantâneo de replicação atual (necessário apenas com envios incrementais)
zfs recv:
-F: expanda o pool de destino, incluindo a exclusão de conjuntos de dados existentes que são excluídos na origem-d: descarte o nome do conjunto de origem e substitua-o pelo nome do conjunto de destino (o restante dos caminhos do sistema de arquivos será preservado e, se necessário, também será criado)-u: não monte o sistema de arquivos no destino
Se você preferir um exemplo completo, aqui está um pequeno script:
#!/bin/sh
# Setup/variables:
# Each snapshot name must be unique, timestamp is a good choice.
# You can also use Solaris date, but I don't know the correct syntax.
snapshot_string=DO_NOT_DELETE_remote_replication_
timestamp=$(/usr/gnu/bin/date '+%Y%m%d%H%M%S')
source_pool=tank
destination_pool=tank
new_snap="$source_pool"@"$snapshot_string""$timestamp"
destination_host=remotehostname
# Initial send:
# Create first recursive snapshot of the whole pool.
zfs snapshot -r "$new_snap"
# Initial replication via SSH.
zfs send -R "$new_snap" | ssh "$destination_host" zfs recv -Fdu "$destination_pool"
# Incremental sends:
# Get old snapshot name.
old_snap=$(zfs list -H -o name -t snapshot -r "$source_pool" | grep "$source_pool"@"$snapshot_string" | tail --lines=1)
# Create new recursive snapshot of the whole pool.
zfs snapshot -r "$new_snap"
# Incremental replication via SSH.
zfs send -R -I "$old_snap" "$new_snap" | ssh "$destination_host" zfs recv -Fdu "$destination_pool"
# Delete older snaps on the local source (grep -v inverts the selection)
delete_from=$(zfs list -H -o name -t snapshot -r "$source_pool" | grep "$snapshot_string" | grep -v "$timestamp")
for snap in $delete_from; do
zfs destroy "$snap"
done
Use algo mais rápido que SSH
Se você possui uma conexão suficientemente segura, por exemplo, túnel IPSec ou OpenVPN e uma VLAN separada que existe apenas entre remetente e receptor, você pode alternar do SSH para alternativas não criptografadas como mbuffer, conforme descrito aqui , ou usar o SSH com criptografia fraca / sem criptografia e compactação desativada, que é detalhada aqui . Havia também um site sobre a recompilação do SSH para ser muito mais rápido, mas infelizmente não lembro a URL - editarei mais tarde, se a encontrar.
Para conjuntos de dados muito grandes e conexões lentas, também pode ser útil para a primeira transmissão via disco rígido (use o disco criptografado para armazenar o zpool e transmiti-lo em um pacote selado por correio, correio ou pessoalmente). Como o método de transmissão não importa para envio / recv, você pode canalizar tudo para o disco, exportar o pool, enviar o disco para seu destino, importar o pool e transmitir todos os envios incrementais via SSH.
O problema com instantâneos confusos
Como afirmado anteriormente, se você excluir / modificar seus instantâneos de replicação, receberá a mensagem de erro
cannot send 'pool/fs@name': not an earlier snapshot from the same fs
o que significa que seu comando estava errado ou você está em um estado inconsistente no qual deve remover os instantâneos e começar tudo de novo.
Isso tem várias implicações negativas:
- Você não pode excluir um instantâneo de replicação até que o novo instantâneo de replicação tenha sido transferido com êxito. Como esses instantâneos de replicação incluem o estado de todos os outros instantâneos (mais antigos), o espaço vazio dos arquivos e instantâneos excluídos será recuperado apenas se a replicação terminar. Isso pode levar a problemas de espaço temporário ou permanente no pool, que você só pode corrigir reiniciando ou concluindo o procedimento de replicação completo.
- Você terá muitos instantâneos adicionais, o que atrasa o comando list (exceto no Oracle Solaris 11, onde isso foi corrigido).
- Pode ser necessário proteger os instantâneos contra a remoção (acidental), exceto pelo próprio script.
Existe uma solução possível para esses problemas, mas eu mesmo não tentei. Você pode usar zfs bookmarkum novo recurso do OpenSolaris / illumos criado especificamente para esta tarefa. Isso liberaria você do gerenciamento de instantâneos. A única desvantagem é que, atualmente, ele funciona apenas para conjuntos de dados únicos, não recursivamente. Você precisaria salvar uma lista de todos os seus conjuntos de dados antigos e novos e, em seguida, fazer um loop sobre eles, marcar, enviar e receber e, em seguida, atualizar a lista (ou banco de dados pequeno, se preferir).
Se você tentar a rota dos favoritos, gostaria de saber como funcionou para você!
zfs send -R ...? Se você canalizou a saída viassh, desabilitou os caracteres de escapezfs send -R ... | ssh -e none ...?