Alguns antecedentes.
estou a usarZREPpara replicar dois servidores entre si e cada servidor contém um pool ZFS contendo dois conjuntos de dados como mestre de replicação e dois conjuntos como destino de replicação. Os master sets contêm o sistema e VirtualBox-VMs do servidor local, a replicação tem como alvo o mesmo do outro.
Além disso, estou fazendo backup de todos os conjuntos mestres por servidor para alguns NAS usando arquivos rsync. O NAS é bastante lento e o backup leva horas para ser bem-sucedido; portanto, a abordagem implementada é suspender as VMs, criar um instantâneo, restaurar as VMs e deixar rsynca execução a partir do instantâneo criado. O importante é que o instantâneo criado manualmente não seguiu a convenção de nomenclatura ZREP e foi destruído logo após rsyncser concluído novamente. No início, o ZREP continuou a operar simultaneamente, iniciado por cron.
O problema.
Mas de vez em quando acontecia que o ZREP entrava em algum estadonão consigo mais sincronizar. Para resolver esse problema, um colega de trabalho me disse que precisava excluir os instantâneos e seguir o processo para inicializar o ZREP novamente. Esse problema foi resolvido ao não permitir rsyncmais que o ZREP fosse executado em paralelo com nosso próprio snapshot no final.
Infelizmente, não tenho os detalhes concretos desse erro e o colega de trabalho não está mais disponível, mas pela descrição dele parecia que havia um problema ao encontrar ancestrais comuns de instantâneos entre o mestre de replicação e o destino para sincronizar de forma incremental. Acho que as mensagens de erro foram mais ou menos assim:
cannot receive incremental stream: most recent snapshot of zfs-pool/vbox/tori does not match incremental source
cannot open 'zfs-pool/vbox/tori@zrep_0001b7': dataset does not exist
Minha compreensão de como funciona o envio/recebimento incremental.
Do meu entendimentoos documentoseoutro questões, para enviar instantâneos de forma incremental com êxito, o mestre de envio e o destino de recebimento precisam compartilhar aquele instantâneo que é usado como argumento 1 zfs sende esses instantâneos precisam ser adicionalmente o atual no destino de recebimento.
O segundo argumento é um instantâneo arbitrário mais recente, usado pelo ZFS para calcular diferenças entre o mestre e o destino do instantâneo que têm em comum e enviar essas diferenças para o destino de replicação. Como ambos compartilham o mesmo instantâneo especificado como argumento 1, as diferenças fazem sentido para o destino e podem simplesmente ser aplicadas como estão.
Os argumentos -ivs. -Ido meu entendimento levam ao envio de um instantâneo lógico contendo todos os dados incrementais calculados do lado mestre OU ao envio de todos os instantâneos intermediários contendo suas alterações incrementais. Portanto, por exemplo, -isempre leva a UM novo instantâneo no destino versus -Ipode levar a N outros instantâneos.
Criar e destruir instantâneos intermediários entre o que é fornecido como argumentos 1 e 2 zfs send -inão deve ser nenhum problema, porque o ZFS sempre calcula as diferenças apenas entre esses dois argumentos fornecidos e não se importa com nenhum outro instantâneo intermediário. No caso do ZREP, isso significa, em teoria, que, desde que eu não esteja interferindo nos instantâneos gerenciados pelo ZREP, não deve fazer nenhuma diferença se instantâneos adicionais forem criados durante sua operação ou não. Simplesmente porque instantâneos ZREP especiais estão sempre disponíveis, gerenciados pelo ZREP e usados para calcular diferenças para replicação. Portanto, em teoria, a criação adicional de snapshots rsynce backups não deveria ser um problema.
Essas suposições estão corretas?
Perguntas não relacionadas ao ZREP.
Em geral, é seguro enviar instantâneos ZFS ignorando incrementalmente alguns intermediários? Ou é necessário enviar TODOS os instantâneos intermediários criados para o destino de replicação para que a rede fique fora de sincronia ou algo assim? Como as coisas dependem de -ivs.-I
Responder1
Sim, você ainda obtém todos os dados intermediários, mas simplesmente não pode retroceder.
Se você tiver os instantâneos 1,2 e 3 e o pool remoto tiver apenas o instantâneo 1, você poderá fornecer o instantâneo 3 e pular 2. Ele simplesmente não será capaz de reverter para o estado '2'. Mas os dados ainda estarão lá.
Os instantâneos descrevem o que estava lá naquele momento. Portanto, faltando o instantâneo '2' no pool remoto, é como se você nunca tivesse tirado um naquele momento. Ele literalmente não sabe sobre o instantâneo '2' e como eram as coisas naquela época.
Se mudar de ideia, você precisará excluir o instantâneo '3' no pool remoto e só então poderá enviar '2' e depois '3' novamente.
https://www.reddit.com/r/zfs/comments/cfzdb3/is_it_safe_to_send_zfssnapshots_incrementally/euensuy/