Reduzindo o tamanho do fluxo do ZFS para backup externo

Question

OBSERVAÇÃO: Meu entendimento desta questão mudou significativamente desde a primeira vez que a perguntei (consulte a Edição 2 abaixo), mas deixei a versão original intacta.

Reunimos um sistema de backup externo (ainda testando internamente) que faz a transferência de dados via envio / recebimento do ZFS. Máquinas em ambas as extremidades são o FreeBSD 8.2. No geral, a configuração funciona bem.

No entanto, há claramente algo que não entendo sobre os tamanhos de fluxo de instantâneos do ZFS. Eu tive dificuldade em encontrar informações sobre isso, então espero que alguém com mais experiência possa me esclarecer.

Na máquina de origem, eu tenho um sistema de arquivos de cerca de 47 GB para o qual eu preciso transferir instantâneos:

# zfs list -t snapshot -r -s creation stg/serverx
NAME                   USED  AVAIL  REFER  MOUNTPOINT
(.......)
stg/serverx@20110620  2.88M      -  47.1G  -
stg/serverx@20110621  2.89M      -  47.1G  -
stg/serverx@20110622  2.88M      -  47.1G  -
stg/serverx@20110623  5.44M      -  46.6G  -

Eu tenho o instantâneo de 6/22 já no servidor remoto, então eu envio o fluxo gerado por

zfs send -i stg/serverx@20110622 stg/serverx@20110623

Isso é recebido do outro lado sem problemas; no entanto, o fluxo gerado tem mais de 80 gigabytes - quase duas vezes o tamanho de todo o sistema de arquivos de origem.

Estou interpretando mal o significado da coluna "USED" gerada por zfs list ? Eu esperava que esse fluxo de snapshots fosse de 5,44 milhões, mais uma certa sobrecarga. Parece que não entendo bem o que constitui a sobrecarga.

Informações possivelmente úteis: Nós fazemos backup (via rsync) de cada servidor para o seu próprio sistema de arquivos. Este em particular parece gerar os maiores fluxos (em relação ao tamanho do sistema de arquivos e do snapshot). Eu suspeito que isso pode estar relacionado ao fato de que é um servidor de e-mail, então alguns de seus conteúdos são bem dinâmicos. No entanto, eu esperaria que isso também aparecesse no tamanho "usado" do instantâneo.

Obviamente, podemos economizar um pouco comprimindo o fluxo (provavelmente ele pode ser reduzido para 12-20% do tamanho original). Mesmo assim, a largura de banda será nosso fator limitante, então gostaríamos de entender o que torna esses fluxos tão grandes e se podemos fazer alguma coisa para mitigá-lo.

EDIT: Eu tinha esquecido que temos a compactação zfs ativada no sistema de arquivos de origem. Portanto, os gigabytes de 47 bits realmente se traduzem em quase 80 gigabytes de dados de sistema de arquivos "reais". Suponho que essa seja uma explicação parcial, mas ainda não vejo por que o fluxo incremental de zfs send seria tão grande.

EDIT 2:

Uma investigação mais aprofundada deste backup e alguns outros levou à conclusão de que as grandes transferências eram de fato esperadas (devido a algumas atualizações ocorridas). No entanto, não vejo qualquer indicação dessa grande quantidade de dados na saída de zfs list .

Eu já passei por documentação e entendo que há muitas complexidades na computação do espaço usado por um instantâneo. A página zfs man diz o seguinte na descrição da propriedade used :

When snapshots . . . are created, their space is initially shared between the snapshot and the file system, and possibly with previous snapshots. As the file system changes, space that was previously shared becomes unique to the snapshot, and counted in the snapshot's space used.

Isso faz sentido para mim. No entanto, eu esperaria ver um instantâneo muito maior criado no final do dia em que o servidor foi atualizado. Na verdade, são apenas alguns megabytes. Não há desduplicação aqui (zpool versão 15). No entanto, o fluxo incremental gerado por zfs send -i é muito grande e contém todas as informações de atualização.

Alguém pode explicar essa aparente inconsistência? A questão relacionada, então, é: Como posso obter uma estimativa razoável do tamanho de um fluxo incremental (de, por exemplo, zfs list output)?

    

Answer 1

Eu sei que esta é uma pergunta muito antiga, mas eu já vi alguns lugares diferentes. Sempre houve alguma confusão sobre o valor expresso em zfs list no que se refere ao uso de zfs send | recv. O problema é que o valor expresso na coluna USED é, na verdade, uma estimativa da quantidade de espaço que será liberado se esse snapshot único for excluído, tendo em mente que pode haver snapshots anteriores e posteriores referenciando os mesmos blocos de dados.

Exemplo:

zfs list -t snapshot -r montreve/cev-prod | grep 02-21
NAME                                      USED  AVAIL  REFER  MOUNTPOINT
montreve/cev-prod@2018-02-21_00-00-01     878K      -   514G  -
montreve/cev-prod@2018-02-21_sc-daily     907K      -   514G  -
montreve/cev-prod@2018-02-21_01-00-01    96.3M      -   514G  -
montreve/cev-prod@2018-02-21_02-00-01    78.5M      -   514G  -
montreve/cev-prod@2018-02-21_03-00-01    80.3M      -   514G  -
montreve/cev-prod@2018-02-21_04-00-01    84.0M      -   514G  -
montreve/cev-prod@2018-02-21_05-00-01    84.2M      -   514G  -
montreve/cev-prod@2018-02-21_06-00-01    86.7M      -   514G  -
montreve/cev-prod@2018-02-21_07-00-01    94.3M      -   514G  -
montreve/cev-prod@2018-02-21_08-00-01     101M      -   514G  -
montreve/cev-prod@2018-02-21_09-00-01     124M      -   514G  -

Para descobrir quantos dados precisarão ser transferidos para reconstituir um instantâneo via zfs send | recv, você precisará usar o recurso dry-run (-n) para esses valores. Tomando os instantâneos listados acima, tente:

zfs send -nv -I montreve/cev-prod@2018-02-21_00-00-01 montreve/cev-prod@2018-02-21_09-00-01
send from @2018-02-21_00-00-01 to montreve/cev-prod@2018-02-21_sc-daily estimated size is 1.99M
send from @2018-02-21_sc-daily to montreve/cev-prod@2018-02-21_01-00-01 estimated size is 624M
send from @2018-02-21_01-00-01 to montreve/cev-prod@2018-02-21_02-00-01 estimated size is 662M
send from @2018-02-21_02-00-01 to montreve/cev-prod@2018-02-21_03-00-01 estimated size is 860M
send from @2018-02-21_03-00-01 to montreve/cev-prod@2018-02-21_04-00-01 estimated size is 615M
send from @2018-02-21_04-00-01 to montreve/cev-prod@2018-02-21_05-00-01 estimated size is 821M
send from @2018-02-21_05-00-01 to montreve/cev-prod@2018-02-21_06-00-01 estimated size is 515M
send from @2018-02-21_06-00-01 to montreve/cev-prod@2018-02-21_07-00-01 estimated size is 755M
send from @2018-02-21_07-00-01 to montreve/cev-prod@2018-02-21_08-00-01 estimated size is 567M
send from @2018-02-21_08-00-01 to montreve/cev-prod@2018-02-21_09-00-01 estimated size is 687M
total estimated size is 5.96G

Gosta! Isso é muito mais do que os valores USADOS. No entanto, se você não precisar de todos os instantâneos intermediários no destino, poderá usar a opção consolidar (-i em vez de -I), que calculará o diferencial necessário entre dois instantâneos, mesmo que haja outros entre eles. / p>

zfs send -nv -i montreve/cev-prod@2018-02-21_00-00-01 montreve/cev-prod@2018-02-21_09-00-01
send from @2018-02-21_00-00-01 to montreve/cev-prod@2018-02-21_09-00-01 estimated size is 3.29G
total estimated size is 3.29G

Então, isso está isolando os vários blocos que foram reescritos entre os instantâneos, de modo que só tiramos o estado final deles.

Mas essa não é toda a história! O zfs send é baseado na extração dos dados lógicos da fonte, para que, se você tiver a compactação ativada no sistema de arquivos de origem, as estimativas sejam baseadas nos dados não compactados que precisarão ser enviados. Por exemplo, pegando um snapshot incremental e escrevendo no disco você obtém algo próximo ao valor estimado do comando dry-run:

zfs send -i montreve/cev-prod@2018-02-21_08-00-01 montreve/cev-prod@2018-02-21_09-00-01 > /montreve/temp/cp08-09.snap
-rw-r--r--  1 root root    682M Feb 22 10:07 cp08-09.snap

Mas se você passar pelo gzip, veremos que os dados estão significativamente compactados:

zfs send -i montreve/cev-prod@2018-02-21_08-00-01 montreve/cev-prod@2018-02-21_09-00-01 | gzip > /montreve/temp/cp08-09.gz
-rw-r--r--  1 root root    201M Feb 22 10:08 cp08-09.gz

Nota lateral - é baseada no OpenZFS no Linux, versão: - ZFS: módulo carregado v0.6.5.6-0ubuntu16

Você encontrará algumas referências às otimizações que podem ser aplicadas ao fluxo de envio (fluxo D-deduplicado, -e mais compacto), mas com essa versão eu não observei nenhum impacto no tamanho dos fluxos gerados com o meu conjuntos de dados.

    

Answer 2

Que tipo de sistema de email e que tipo de tecnologia "store"? Se o armazenamento de mensagens já estiver compactado de alguma forma, cada incremento pode, na verdade, estar cheio, pois seu fluxo de dados compactado pode estar mudando dinamicamente devido à sua compactação.

A desduplicação também está em jogo em qualquer sistema? Parece que pode haver uma chance remota de estar no sistema de origem. Isso pode explicar a diferença de tamanho.