Disclaimer: Como eu nunca usei o zvols, não posso dizer se eles são diferentes na replicação do que sistemas de arquivos normais ou snapshots. Eu suponho que eles são, mas não acredite em mim.
A sua pergunta é na verdade várias perguntas, tento respondê-las separadamente:
Como replicar / espelhar o conjunto completo para o local remoto
Você precisa dividir a tarefa em duas partes: primeiro, a replicação inicial deve ser concluída, depois a replicação incremental é possível, contanto que você não mexa com os instantâneos de replicação . Para habilitar a replicação incremental, você precisa preservar os últimos instantâneos de replicação, tudo antes que possa ser excluído. Se você excluir o instantâneo anterior, zfs recv irá reclamar e abortar a replicação. Neste caso você tem que começar tudo de novo, então tente não fazer isso.
Se você só precisa das opções corretas, elas são:
-
%código%:
-
zfs send : envia tudo sob o conjunto de dados ou conjunto de dados (a replicação recursiva, necessária o tempo todo, inclui -R ). Além disso, ao receber, todos os instantâneos de origem excluídos são excluídos no destino.
-
-p : inclui 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)
-
%código%:
-
-I : expanda o pool de destino, incluindo a exclusão de conjuntos de dados existentes que são excluídos na origem
-
zfs recv : 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 criado)
-
-F : 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 o SSH
Se você tiver uma conexão suficientemente segura, por exemplo, um túnel IPSec ou OpenVPN e uma VLAN separada que exista apenas entre remetente e destinatário, poderá alternar de SSH para alternativas não criptografadas, como mbuffer como é descrito aqui , ou você pode usar o SSH com criptografia fraca / sem criptografia e desativada, que é detalhado aqui . Também houve um site sobre a recombilação do SSH para ser muito mais rápido, mas infelizmente não me lembro da URL - vou editá-lo mais tarde se eu encontrá-lo.
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 disco criptografado para armazenar o zpool e transmiti-lo em um pacote lacrado via correio, correio ou pessoalmente). Como o método de transmissão não importa para send / recv, você pode canalizar tudo para o disco, exportar o pool, enviar o disco para seu destino, importar o pool e então 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 que você está em um estado inconsistente, no qual você 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 seja transferido com êxito. Como esses snapshots de replicação incluem o estado de todos os outros snapshots (antigos), o espaço vazio de arquivos excluídos e os snapshots só serão recuperados se a replicação for concluída. Isso pode levar a problemas de espaço temporários ou permanentes em seu pool, que só podem ser resolvidos reiniciando ou concluindo o procedimento de replicação completo.
- Você terá muitas capturas instantâneas adicionais, o que desacelera o comando list (exceto no Oracle Solaris 11, onde isso foi corrigido).
- Talvez seja 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 o -d , um novo recurso do OpenSolaris / illumos criado especificamente para essa tarefa. Isso livraria você do gerenciamento de instantâneos. A única desvantagem é que, no momento, ele só funciona para conjuntos de dados únicos, não recursivamente. Você teria que salvar uma lista de todos os seus conjuntos de dados antigos e novos e, em seguida, fazer um loop sobre eles, marcando, enviando e recebendo-os e atualizando a lista (ou banco de dados pequeno, se preferir).
Se você tentar a rota do favorito, eu estaria interessado em saber como isso funcionou para você!